Shipping Solo: What to Polish and What to Skip

When you are building a product alongside a full-time job, time is not just scarce. It is the only resource that matters. I work on Tapglyph and NavEire with roughly 10 to 20 hours per week. That means every hour spent polishing a transition animation is an hour not spent talking to a potential customer or fixing a real usability issue.

The temptation for technical builders is to keep refining the product. It always feels productive because you can see the improvement. But the improvement only matters if someone is using the product. I have had to train myself to ask a different question: not 'is this good enough?' but 'is this good enough for the next conversation I need to have?'

The concept I keep coming back to is what I call the experience spine. The minimal sequence of interactions that delivers the core value. For Tapglyph, that spine is: visitor taps phone on NFC tag, content loads instantly in the browser, visitor reads or listens. If that sequence feels fast, smooth, and rewarding, the product works. Everything else can be rougher. The CMS dashboard, the analytics page, the onboarding flow.

For NavEire, the spine is: open the app, find your stop, see when the next bus or train is coming. The journey planner, the reliability grades, the favourites system are all valuable additions, but they are not the spine. Getting the spine right first and building outward from there is how I have avoided scope bloat while still shipping something that feels complete.

The most effective form of polish when you are building alone is consistency. Not elaborate animations or custom illustrations. Consistency in spacing, typography, colour, and interaction patterns. A product that uses the same visual language everywhere feels more polished than one with a beautiful landing page and an inconsistent dashboard.

Tailwind CSS has been valuable for this on both NavEire and my portfolio site. It enforces a constrained design system by default. You pick from a finite set of spacing, colour, and typography values, and that constraint produces visual coherence even when you are moving fast.

The hardest skill I am still learning is knowing when to stop. There is always one more feature that would make the product better, one more edge case to handle, one more screen to redesign. The question I ask myself now is: will this change affect whether someone says yes or no to using the product?

If the answer is no, if the decision will be made based on the core value and the experience spine, not the thing I am about to refine, then I ship what I have and move on. The next conversation with a museum curator or the next piece of user feedback will tell me more about what actually needs improving than another hour of solo iteration ever could.