Everything I've learned shipping app-store products solo
Four products from empty repo to live stores as the only engineer. The habits that made it survivable, and the ones I had to unlearn.
I've now taken four products from git init to live app stores as the only engineer: a food-delivery ecosystem in college, two client products, and my own reading platform. Solo shipping is a specific skill, distinct from being a good engineer on a team. These are the parts I'd tell my past self.
Async everything, because you sleep
On a team, a stuck queue pages someone. Solo, it waits for you to wake up. That constraint shaped every architecture decision in Penspace: the translation pipeline is an event queue with bounded concurrency, timeouts, failure marking and, critically, retry on boot. Deploying the fix is re-driving the queue. Any background work that can't self-heal after a restart is a pager you've wired to your own head.
Write the runbook before you need it
Every production system I run has a DEPLOYMENT.md with the exact commands, in order, tested. Not for a future teammate: for me at 1am when the EC2 box needs attention and my working memory is gone. The discipline of writing it also catches the step you do "automatically" that would sink anyone else (including future you).
Conventions are cheaper than willpower
Solo codebases rot through inconsistency, not size. My Flutter apps carry a conventions doc the code must follow: layering rules, a hard cap on UI file length, one state-management idiom, no exceptions. It sounds bureaucratic for a team of one. It's the opposite: every decision made once in the doc is a decision I never make again at midnight.
The last mile is a third of the work
Nobody warns you how much shipping isn't code: signing configs, store listings, review rejections, privacy-policy pages, delete-account flows Apple demands, deep-link verification files, subscription edge cases. Budget for it. The difference between "app is done" and "app is live" was consistently 3–4 weeks on everything I've shipped.
Know what you're bad at
Solo doesn't mean self-sufficient. My test coverage is thinner than I'd accept from a team; I compensate with typed layers, crash reporting and canary releases, and I say so plainly rather than pretending. Knowing which corners you're cutting, and cutting them on purpose, is most of what "senior" means when there's no one to review your PR.
The compounding benefit of all this: the fifth product is dramatically faster than the first. Not because the code is reusable. Because the judgment is.