The honest conversation we have with every first-time founder about MVPs, timelines, and the one feature you probably don't need in v1.
The most common thing we hear from first-time founders is "I just need a simple app." Simple is never simple. Simple is a colour of horse that does not exist in the wild. Every app is a chain of decisions — authentication, data storage, offline behaviour, push notifications, app store submissions — and each decision creates downstream consequences you won't think about until they surface at 11 p.m. on a Friday.
The second most common thing we hear is "we need to build everything before we can launch." This is the most expensive mistake in software. The goal of v1 is to learn, not to ship a finished product. The feature that feels non-negotiable in March will feel different when you see how real users actually behave in May.
We tell every founder to write down their three most important user stories — the three actions a user must be able to complete for the app to be useful. Everything else is a nice-to-have. If it's not in those three stories, it doesn't go in v1. Not because we're lazy but because scope is the enemy of speed, and speed is the most important thing in the early stage.
Budget conversations are uncomfortable but we have them early. A decent app built by a competent team costs real money. If the budget is small, we scope ruthlessly. We'd rather build something lean and solid than something feature-rich and fragile. A leaky foundation is infinitely more expensive to fix later than to prevent now.
The app store approval process takes longer than most people expect. iOS review alone can take seven to fourteen days for a new app. Build that into the timeline. If you're planning a launch-day announcement, plan it for two weeks after your submission date, not the day you press submit.
Once you launch, the work begins. Apps have to be maintained — dependencies update, operating systems change, users find creative ways to break things. We always include a maintenance conversation before we start building, because the best apps are the ones that keep getting better after launch.
Back to the journal