How to scope the first useful version of your app

“Where do I even start, and how small is too small?” It's the question I hear most from founders. You've got the idea, maybe a stack of features in your head, and you want to build “the product.” My advice is almost always the same: don't. Not yet. Find the first useful version instead — the smallest thing a real user would actually use, and the smallest thing you'd be willing to put your name on.

After 22 years in startups — across healthcare, security and privacy, the gig economy, and commercial contracts — I've learned that each industry's needs have very little to do with the tools and everything to do with the products you choose to build. The hard part was never the code. The hard part is knowing what's worth building.

Everyone talks about the minimum viable product, and that's where the trouble starts. The problem with “minimum viable product” is that you can decide what's minimal, but it's the user who decides what's viable. Those are two different people making two different calls, and founders forget it constantly.

So I don't think of an MVP as a minimal feature set. I think of it as a minimal waste of resources. The question isn't “what's the least I can build?” It's “how do we know someone will actually find this useful before I spend months building it?”

And I'll be honest: I wouldn't figure out the minimal viable version alone, and neither should you. It has to be done with people who understand the audience.

Minimal is yours to decide. Viable is the user's.

Before we talk about screens or buttons or anything technical, we talk about behaviors, goals, incentives, and outcomes. We don't lead with tech or tools. Every app has to deliver real-world value, and without understanding that value, the technical conversations simply don't matter.

So I start with core value: what does someone actually get out of your application? What are their drivers, their motivations? What's the outcome you're hoping to provide? Code is merely an expression of that idea — but the idea still has to be had first. If you can't say plainly what someone gets and why they'd come back, no amount of building will save you.

Once you know the outcome, the next question is the cheapest one you can ask: how do we provide that outcome without writing a single line of code, or with the smallest amount of code possible?

That's the first assumption you have to test — not “can we build it” but “will anyone find it useful.” If it passes, you've earned the right to build a product around something you actually know is needed. If it fails, you've saved yourself the most expensive mistake in startups: building the wrong thing beautifully.

AI is real leverage here. It lets you stand up a rough test faster and cheaper than ever before. But it's leverage, never the hero. It can help you deliver the outcome sooner. It can't tell you which outcome is worth delivering.

Someone came to me wanting to take audio and turn it into marketing content. We spoke about the product a lot — the interface, the experience, the flow they imagined people moving through. But I kept asking why. Why this? Why now? And underneath it all, the answer was simple: they were just trying to save time.

So instead of the complex experience they'd described, I suggested we start by saving them that time right now. A simple pipeline: take their audio, split it into multiple formats, and auto-publish it. No elaborate interface. No product, really. Just the outcome, delivered.

The end result was nothing like what they originally described. And that's the whole point — because what they described was an experience they wanted the user to have, not the problem they wanted to solve. Those are not the same thing.

Founders almost always describe the experience they want the user to have, rather than the problem they're solving. Learning to see the difference is a journey.

Learning to build is one of those things you can learn but can't really be taught. You usually have to build something nobody asked for and realize you were asking the wrong questions all along. It's a progression: from a mindset of building, to wanting immediate feedback, to finally talking about outcomes and values instead of features. That comes naturally with experience over time — but you can shortcut a lot of the pain by working with people who've already made the journey.

If you've got an idea and you're staring at that “where do I even start” question, that's exactly the conversation we're good at. We'll help you cut through the feature list, find the outcome that matters, and scope the first useful version — the smallest thing real users will use and you'll be proud to put your name on. Deliver your value. The rest are details.