I Built the Whole Product Before I Fixed the Front Door

It's the same pattern I caught earlier, cutting features I didn't need in I Built the Wrong Thing First, just showing up in a different part of the product. There's a type of problem that only reveals itself late, and not because it's hidden. It's because you're looking somewhere else the entire time. The hard problems get your attention: the architecture, the AI pipeline, the billing integration, the edge cases that would embarrass you if a real user hit them. You solve those first because they're interesting, because they're the reason you started building, and because the alternative is sitting with uncertainty, which is harder than writing code.

The front door gets done last. Because it feels simple.

It isn't.

I caught it during a pre-launch review, sitting with the product as a visitor would: cold, no context, no six months of decisions behind me. Within thirty seconds I could see it. The navigation said "Try Pro free for 7 days." The pricing section said "Free to start. Upgrade when you're ready." A visitor can't tell what they're signing up for. Two different promises on the same page, neither of them wrong exactly, both of them undermining each other.

That was the surface problem. The deeper one was the empty state.

Why do founders always build the wrong thing last?

Difficulty and visibility don't correlate. The technically hard problems feel important, and they are, while the front door feels simple by comparison. An onboarding flow, a pricing page, an empty state: these look like design decisions, not engineering challenges. So they get deprioritised in favour of things that feel harder and more foundational.

The trap is that the front door isn't a design problem. It's a conversion problem, a communication problem, and a trust problem all at once. It's the only part of the product a new user sees before they decide whether to stay. Getting it wrong costs you every user who might have become a customer. Getting it right is worth more than almost any feature you built before it.

A new user lands, signs up, opens the product for the first time. Nothing is there yet. And the empty state, the thing that should be doing the hardest job in the product, guiding that person to the moment that makes everything click, wasn't designed for that. It just existed. A placeholder where a sales pitch should have been.

With a 7-day trial, session one is everything.

The "oh" moment has to happen before day three or the user churns without ever knowing what they missed. For ka-do that moment is specific: you create a task, it lands in your list, you drag it to the day you plan to do it, set the effort, schedule it with one click around your real calendar. You upload a transcript from a meeting, it generates tasks, those tasks feed back into the same loop. The circle closes. Task to schedule to meeting to transcript to tasks again: not a feature, but a system that holds your work in one place.

That loop is the product. But it was never what greeted a new user at the door.

I'd built nearly everything before I noticed the front door was broken. Auth, billing, AI pipeline, calendar integration, board view, schedule view, Smart Capture, Threads: close to two thousand commits, the full surface area of a commercial SaaS. And the thing that converts a visitor into someone who stays, the thirty seconds that determines whether any of that work ever gets seen, got done last.

Classic heads-down builder problem. You solve the hard problems first because they're interesting. The front door feels simple by comparison.

It isn't simple. It's the hardest thing you'll build. You can only see it clearly when you stop being the builder and start being the visitor, and by then you've already built everything else. Catching it is one thing; knowing whether the product's actually ready afterward is another, which is where When Is a Product Ready to Launch? picks up.

Steve Drew is the founder of ka-do, a calm task and planning tool for busy professionals.