Last month, a founder came to us with a 14-page feature list for a fitness app. Detailed screens, user flows, even colour codes. They'd spent three weeks on it. They were ready to build.
I read the whole thing. Then I asked one question: "How many people have told you they'd pay for this?"
Silence.
Not awkward silence — the kind of silence that happens when someone realizes they've been solving the wrong problem. They'd spent three weeks designing features. They hadn't spent three hours talking to users.
That conversation saved them $8,000 and three months of development time. Not because we wrote better code — because we didn't write code at all. Not yet.
This is the part of my job nobody talks about. The unsexy part. The part before the first commit, before the first wireframe, before anyone opens VS Code. The part where we figure out whether what you want to build is actually what you need to build.
Why "Just Build It" Is the Most Expensive Advice in Tech
I hear it all the time. From Twitter threads, from startup advice columns, from well-meaning friends: stop overthinking and just ship something.
And I get the appeal. Planning feels like procrastination. Building feels productive. You can see progress — screens, buttons, animations. It feels like you're moving forward.
But here's what I've learned from quoting and building dozens of projects: the expensive mistakes never happen during development. They happen before development, when nobody asks the hard questions.
A developer who starts building from a feature list without questioning it isn't doing their job. They're a typist. You're not paying for someone to type — you're paying for someone to think.
Every project we take at LSD goes through what we call a discovery phase before we write a line of code. It's not long. It's not bureaucratic. It's five questions and a few hard conversations. But it's the reason our projects ship on time and our clients don't come back three months later saying "this isn't what I meant."
The 5 Questions I Ask Before Writing a Line of Code
These aren't theoretical. These are the actual questions I ask on every single project. Most founders haven't thought about at least two of them — and that's exactly the point.
1. "Who is this for, and what are they doing right now without it?"
This is the question that kills bad ideas — kindly.
If your target user is "everyone," you don't have a product. If your target user has no current solution (not even a spreadsheet or a group chat), you might be solving a problem that doesn't exist.
The fitness app founder? Their target audience was "people who want to get fit." That's 4 billion people. When I pushed harder — who specifically, what's their current routine, what tool are they using today — we narrowed it down to busy parents who use Instagram saved posts to track workouts and hate it.
That's a real user with a real problem. And it meant we could cut 80% of the feature list. They didn't need social features, gamification, or a marketplace. They needed a better way to save and follow workout routines. That's it.
What this catches: Feature bloat, unclear market, building for a user who doesn't exist.
2. "What does this need to do on day one — and nothing else?"
Founders love talking about the vision. The full product. The thing it'll be in two years when they have funding and a team of 20.
I don't care about that. Not because the vision doesn't matter — but because the vision doesn't ship. The MVP ships. And the MVP needs to do one thing well enough that a real person would use it, pay for it, or come back to it.
I force this conversation by asking: if you could only launch with three features, which three? Not three categories. Three specific things a user can do.
Most founders resist this question. "But they're all important." No, they're not. If everything is important, nothing is. Pick three.
The three features you pick become the entire scope of version one. Everything else goes on a list called "after we prove this works." That list is where 60% of startup budgets go to die — building features nobody asked for before proving the core works.
What this catches: Scope creep before development even starts, premature scaling, building features nobody will use.
3. "How will you know this is working?"
This is the question founders hate. Because the honest answer is usually "I don't know."
If you can't define what success looks like before building, you won't recognize it after. And more importantly, you won't know when to pivot.
I need a number. Not a vague goal — a number. "50 users in the first month." "3 paying customers." "A 10% conversion rate from landing page to signup." "$1,000 in monthly revenue within 90 days."
The number doesn't have to be big. It just has to exist. Because without it, you'll keep building and adding features and tweaking the design indefinitely, telling yourself progress is just around the corner, burning money on a product that has no defined threshold for "this is working" or "this isn't."
What this catches: Endless iteration with no validation, building without a feedback loop, spending $10K before learning anything.
4. "What happens if we're wrong about the core assumption?"
Every product has a core assumption. A belief about the market that, if wrong, means the whole thing collapses.
For the fitness app: "Busy parents want a dedicated app for workout routines instead of using Instagram." That might be wrong. Maybe they like Instagram because it's where they already spend time. Maybe the friction of downloading another app is worse than the friction of scrolling saved posts.
I don't need to know the answer. I need to know what we'd do if the answer is no.
If the core assumption is wrong and your response is "go back to the drawing board and spend another $5K," that's a bad plan. If the response is "we can test this with a landing page and a waitlist in two weeks for $300," that's a good plan.
We design projects so that core assumptions get tested first. Not last. The most important question your product needs to answer should be the first thing we build — not the last feature we add after the dashboard, the settings page, and the onboarding flow.
What this catches: Building the riskiest part last, spending months on infrastructure before testing demand, committing to an architecture that can't pivot.
5. "Who has tried this before, and what happened?"
Founders hate this question too. Either because they think the answer is "nobody" (unlikely) or because they don't want to hear that someone tried and failed.
Both reactions tell me something important.
If nobody has tried it, that's not a green flag — it's a yellow one. Markets with zero competition usually have zero competition for a reason. Maybe the problem isn't painful enough. Maybe the market is too small. Maybe the regulatory environment makes it impossible. We need to understand why the space is empty before celebrating that it is.
If someone tried and failed, I want to know why. Not to copy them — to avoid their mistakes. Did they fail because the market didn't exist (bad sign)? Because their execution was poor (opportunity for us)? Because the timing was wrong and now it's right?
I spend 30 minutes on competitor research before every project. Not deep analysis — just enough to know what's out there, what it costs, and what users say about it. The App Store reviews, the Reddit complaints, the "I wish this app did X" tweets. That's where product ideas live.
What this catches: Entering a dead market, repeating known mistakes, missing an obvious competitor who's already won.
What This Process Actually Looks Like in Practice
It's not a formal workshop. We don't fly to your office and stick Post-its on a whiteboard for two days. It's a 60-to-90-minute conversation, usually on a call, with a follow-up document.
Here's the typical timeline:
Before the call (15 minutes): You fill out our project brief template. This gives us your idea, budget, timeline, and what success looks like. We read it before the call so we're not wasting time on basics.
The call (60–90 minutes): We go through the five questions. We push back. We challenge assumptions. We cut scope. By the end, we both know exactly what version one looks like — and what it doesn't include.
After the call (24–48 hours): We send a scope document. Not a quote — a scope. It says: here's what we're building, here's what we're not building, here's the core assumption we're testing, here's how we'll know it works. The quote comes after you approve the scope.
This process adds two to three days to the start of a project. It saves two to three months during the project.
The Patterns I See Over and Over
After doing this across dozens of conversations, the same mistakes come up so often I could set a timer:
Building the admin panel first. You don't need an admin dashboard before you have users. You need users before you need a dashboard. Build the user-facing thing first. Manage the backend with a spreadsheet until you have enough users to justify the investment.
Adding authentication before validation. Login, signup, forgot password, email verification, OAuth — that's 2–3 weeks of development. For an MVP that might not work. Use a simple magic link or skip auth entirely for the pilot. You can always add it later when you know the product has legs.
Designing for scale before proving demand. Microservices, Kubernetes, multi-region deployment — for an app with zero users. Build the monolith. Put it on one server. If you get so many users that your server falls over, that's called a good problem.
Copycat features. "Uber has ratings, so we need ratings." "Slack has threads, so we need threads." You are not Uber. You are not Slack. Those features exist because they solved specific problems at specific scale. What problem does your rating system solve for your 50 beta users? If you can't answer that, don't build it.
The Real Cost of Skipping Discovery
I've seen what happens when projects skip this process. Not from our clients — from the clients who come to us after working with someone else.
The typical story: they hired a developer or agency, described what they wanted, got a quote, started building. Two months in, they realized the thing they described wasn't the thing they needed. By then, $5K–$10K was spent. The developer built exactly what was asked for — the problem is that what was asked for was wrong.
This isn't the developer's fault. It's a process failure. Nobody stopped to ask whether the feature list was the right feature list. Nobody challenged the assumptions. Nobody said "before we build this, how do we know anyone wants it?"
The cheapest code you'll ever write is the code you don't write. The most valuable thing a developer can tell you is "don't build that."
When You Don't Need Discovery
To be fair — not every project needs this. If you're adding a feature to an existing product with active users and clear data showing what they want, just build it. If you're redesigning a website with known conversion metrics and specific goals, the brief is probably enough.
Discovery matters most when:
- You're building something new from scratch
- You're spending more than $2,000
- You're not sure if users want this
- The scope feels large and unclear
- You've been "planning" for more than a month without clarity
If any of those are true, spending 90 minutes on hard questions before spending months on code is the best investment you'll make.
Before You Hire Anyone, Ask Yourself These 5 Questions
You don't need us to do this. You can do it yourself, right now, before you talk to any developer or agency:
- Who specifically is this for, and what are they using today? (Not "everyone" — name the person)
- If you could only build 3 features, which 3? (These are your MVP)
- What number tells you this is working? (Users, revenue, conversion rate — pick one)
- What if your core assumption is wrong? (What's the cheapest way to test it?)
- Who else has tried this? (Go read their App Store reviews right now)
If you can answer all five clearly, you're ready to hire a developer. If you can't, you need a discovery conversation first — and that conversation will save you more money than any line of code ever will.
We'd Rather Talk You Out of a Bad Idea Than Build You One
Most agencies want you to build the biggest thing possible. More features, more screens, more months of billing.
We don't work that way. Our best client relationships started with us cutting their scope in half. Because a client who launches a focused product that works will come back for phase two. A client who spends their entire budget on a bloated version one that flops won't come back at all.
If you've got an idea and you're not sure whether it's ready to build — or you've got a feature list and a nagging feeling that something's off — let's have the conversation. Sixty minutes. Five questions. No commitment. We'll either confirm you're on the right track or save you from an expensive mistake.
Either way, you'll leave the call knowing exactly what to build — and what not to.
LSD Dev Studio — Launch Support Develop. We build web apps, mobile apps, animated videos, and digital products for founders who want to build the right thing the first time. See how we work or explore our services.