Founder stories · 3 min read · 14 October 2026
Running four products as the only developer
XavierStack, LocalUncle, BookMeDrive and mydockspace, with one developer. The rules that keep it from falling apart.
I'm the only developer across most of what I run. XavierStack takes client work, LocalUncle and BookMeDrive are live marketplaces, and mydockspace is being rebuilt. People ask how that works. The honest answer is that it only works because of a few rules I don't break.
Rule 1: say no to features, yes to boring work
Every product has a list of features someone wants. If I said yes to all of them, I'd have four half-finished products. So the default answer to a new feature is no, or at least not yet.
The work that gets a yes is the boring stuff. Database upgrades. Payment flows that don't break. Fixing the onboarding step where people drop off. Nobody tweets about a cleaner payment flow, but it's the thing that decides whether a marketplace survives.
Rule 2: one product gets the deep work each day
Switching between four codebases in one afternoon is how bugs get shipped. I give each day's main block to one product, and everything else waits for a short admin slot. A message from a LocalUncle provider can wait two hours. A half-written migration can't be left open while I jump into BookMeDrive.
Rule 3: someone else owns the business side where possible
On LocalUncle, I build the tech and my partner runs the business. That split is the only reason it works. I'm not good at being the developer, the salesperson and the support desk at the same time, and I've stopped pretending I can be.
If you're a solo technical founder, the most useful thing you can find isn't a co-developer. It's someone who'll talk to customers while you build.
Rule 4: reuse everything
Every product shares the same patterns: Django REST on the backend, Next.js on the front, the same deploy setup, the same way of handling auth. When I solve something once, it gets reused. That's also why these notes exist: writing a fix down is how I make sure I only solve it once.
Rule 5: be honest about what's live and what isn't
On my own site I mark things as Live, Building or Early. It sounds small, but it stops me from spreading myself across things that only exist in my head. If something has been "Early" for months, that's a signal to either commit to it or drop it.
What I'd tell another solo founder
- Pick the one metric that matters for each product, and ignore the rest for now.
- Write down every fix. Future you is a different developer who's forgotten everything.
- Keep the stack boring and the same across products.
- Protect your deep work block like a client meeting.
Fewer features, more fixes. That's the whole strategy.
