Most projects start with someone writing down what they want. Then someone else tries to understand it. Then a third person tries to build it.
I skip the middle steps. When the idea, the design, and the code all live in the same head, something interesting happens: less gets lost in translation. Faster results. Tighter feedback loops.
One head, zero translation loss
What I envision, I build — without translation layers. The developer and the designer are the same person, so the gap between intent and execution shrinks to zero.
This doesn't work for everyone. It works for me because I spent 16 years collecting the skills it requires: business, design, development. I didn't learn them in parallel — I built them on top of each other.
When it doesn't work
Building alone doesn't mean doing everything alone.
There are things I outsource: illustrations, brand strategy, legal. Those aren't my domain, and I don't want them to be. What matters is keeping the product — from idea to finished code — in one head.
And sometimes a project is too big for one person. When the deadline is tight, the scope is complex, and the technology is something I don't know deeply enough. That's when I work with a team. But deliberately, not by default.
Right-sizing the team
Not every project needs a full squad. PM, designer, frontend, backend, QA — that structure exists for a reason, but it's not the only way. Some projects move faster with fewer handoffs.
What matters most: someone who understands the whole picture. Who doesn't just see their own slice, but how it fits together.
I often work solo because it keeps the feedback loop tight. But the goal was never to avoid people — it's to avoid losing signal between the idea and the result.
There's always a next level.
If you like what you see — whether you're building a product or a team — I'd love to hear about it.