Article
Shipping Solo: What to Polish and What to Skip
When you are building alone with 10 to 20 hours a week, every call about quality is really a call about what else does not get built.
The Real Constraint
Building Tapglyph and NavEire alongside a full-time job means roughly 10 to 20 hours a week. Some weeks less. Every hour has to do real work, which means deciding constantly what does not get built.
The temptation is to keep refining. Improving the product feels like progress because you can see the improvement. But the improvement only matters if someone is using the product. I have wasted entire evenings polishing interactions that nobody ever saw because I shipped them after the conversation that would have mattered had already happened.
The question I try to ask now is not 'is this good enough?' It is 'is this good enough for the next conversation I need to have?'
The Experience Spine
Every product has a minimal sequence of interactions that delivers the core value. I call it the experience spine. For Tapglyph: visitor taps phone on NFC tag, content loads in the browser, visitor reads or listens. That sequence has to be fast, smooth, and reliable. The CMS dashboard, the analytics page, the onboarding flow can be rough.
For NavEire: open the app, find your stop, see when the next bus is coming. The journey planner and reliability grades came later. Favourites came later. Getting the spine right first is how I shipped something that felt finished while still leaving half the features unbuilt.
There are specific things I knowingly skipped. The Tapglyph CMS is functional but not pretty. The NavEire settings screen has no animations. Neither of those decisions has ever come up in a real conversation about the product.
Polish as Consistency
When you are building alone, the most effective form of polish is not transition quality or illustration detail. It is consistency. The same spacing. The same colour use. The same interaction patterns repeated until they feel natural. A product that uses the same visual language throughout feels more considered than one with a beautiful landing page and an inconsistent interior.
Inconsistency is what makes things feel cheap. Not unfinished details.
When to Stop
There is always one more thing. There always will be. Before spending another session on something, I ask: will this change whether someone decides to use the product?
For most things the answer is no. The decision will be made based on the core value and the experience spine, not the thing I am about to refine. When that is true, I ship what I have and go get a conversation instead. A curator telling me the CMS is confusing teaches me more than another solo iteration would.
Related Articles
What I Learned Integrating a Messy Real-World API
The NTA's GTFS feeds are public, documented, and routinely inconsistent. Building NavEire taught me more about production API integration than any tutorial ever could.
Building a Real-Time Transit App Solo
What I learned designing and shipping NavEire, a live Irish public transport tracker, from architecture decisions to production deployment.