The way I build
I don’t stop at design.
I design and build, so the gap between designed and shipped is a choice, not a tax. I can carry a product from problem to shipped, or plug into your team and hand over clean. Either way, nothing gets lost in translation. Here’s how, step by step.
Follow the lineThree rules run through everything.
-
Adopt what exists.
Your design system, your stack, or I set one up. I don’t impose my tools on your codebase.
-
Prototype the feel before the expensive part.
A real coded prototype with no database yet. It feels like the product, so validation is honest, the backend waits until it’s proven.
-
One living document.
A feature passport travels every step, capturing decisions and open questions. Nothing leaks between phases.
Ten phases. One person, the whole way.
Design leads the front, engineering delivers the back, and they overlap in the middle, where the same brain carries the work across the seam. It’s how I’m rebuilding Nitra Academy 2.0 right now, from data model to deploy.
-
Design
Business input
Understand the real problem and what success looks like, before a pixel or a line of code.
- Frame the problem
- Agree goal & scope
-
Design
Research
Trade assumptions for evidence, some fast and desk-based, some from real people.
- Desk research (AI)
- Draft hypotheses
- Real user interviews
- How Might We’s
-
Design
Explore & concept
Open the solution space wide, then commit. Generating options is cheap now; the taste to kill nine of ten is the work.
- Generate concepts (AI)
- Choose a direction
- Map UX flows
-
Design + Engineering
Foundations
Stand the build on the right base: your design system and stack, or a new one, set up deliberately.
- Assess the design system
- Confirm stack & constraints
- Set up components & tokens
-
Design + Engineering
Prototype in code
A real coded prototype with no database behind it. It feels like the finished product, which is exactly what makes validation honest.
- Build the front-end (no DB)
- Stub data locally
- Polish interactions
-
Design + Engineering
Validate
Find out whether it works for real people, before spending on the expensive part.
- Test with real users
- Log findings & decisions
-
only once validated
The expensive work, spec, architecture, backend, starts only here. Nothing before it is proven guesswork.
-
Engineering
Spec & architecture
Design the technical solution before building it. Get the data model right and the rest falls into place.
- Write the PRD
- Design the data model
- Design the infrastructure
-
Engineering
Build for real
The prototype isn’t thrown away, it becomes the product. Only the data layer is new.
- Build the data model & infra
- Link front-end to backend
- Harden, QA & accessibility
-
Engineering
Ship
Get it in front of real users, cleanly.
- Deploy to production
- Release to users
-
Design + Engineering
Learn & follow-up
Measure reality, decide what’s next, then loop back to the top.
- Measure & analyse
- Plan the next iteration
The thread that ties it together.
Every phase writes to one living document, a feature passport: the decisions, the open questions, the context. Not written up afterwards, but kept in sync as the work happens.
It’s also what makes a hand-over clean. When I carry a feature end to end, nothing’s trapped in my head; and when I do hand over, to your team, a colleague, or future-me, the passport is the hand-over. So the hand-off isn’t something I avoid; it’s something I make lossless.
No seam to lose things in.
The gap between designed and shipped is really a gap between two people, a designer who hands off, and an engineer who rebuilds. I’m both, so that gap doesn’t have to exist: the person who decided how it should work can be the one who makes it real. Nothing gets translated, nothing gets lost.
Got something to build?
Let’s talk