Just Build the Thing

I keep seeing the same pattern with founders who come to us after working with agencies.

They spent two months in “discovery.” Workshops. User interviews. Competitor analysis. Stakeholder alignment sessions. A beautifully formatted research deck. Wireframes for every possible flow.

Then they ran out of budget before building anything.

Discovery is Expensive Guesswork

Here’s the thing no one wants to admit: most discovery work is prediction dressed up as insight.

You can interview users, but they’ll tell you what they think they want, not what they’ll actually use. You can analyze competitors, but that tells you what worked for someone else, not what will work for you. You can workshop until the whiteboard runs dry, but you’re still guessing.

I’m not saying research is worthless. I’m saying the ROI is terrible compared to the alternative: building something real and learning from actual usage.

A two-month discovery phase and a two-week prototype will teach you different things. The prototype teaches you faster, costs less, and gives you something tangible to show investors, users, and your team.

Discovery Protects the Wrong People

Traditional discovery exists to de-risk the agency, not the client.

Think about it. If an agency spends two months on research and wireframes, they’ve billed hours before committing to any real outcome. If the product fails later, they can point to the research deck. “We followed the process. The insights were solid. Execution must have gone wrong somewhere.”

It’s CYA disguised as methodology.

Meanwhile, the founder has burned through runway on assumptions. They paid for certainty they were never going to get. No amount of sticky notes on a wall will tell you if users will pay for your product.

Real Feedback Beats Hypothetical Feedback

Users can’t give you useful feedback on wireframes. They’ll nod along, say it makes sense, maybe suggest moving a button. But they’re imagining using something, not actually using it.

Put a working prototype in their hands and everything changes. They tap where they expect things to be. They get confused at the parts you thought were obvious. They ignore the feature you were sure was the main draw.

This is the feedback that matters. And you can only get it from something real.

The math is simple: the ROI on shipping something functional is 10x higher than another round of research. You’re not spending resources on guessing. You’re spending them on learning.

And with AI-assisted development, building is now faster than speccing anyway. The excuse that “we need to plan thoroughly because building is expensive” doesn’t hold up anymore. Building is cheap. Guessing is expensive.

What We Do Instead

When we start a project, there’s no discovery phase. No elaborate research process. Here’s what happens instead:

A conversation. Not a brief or a requirements doc. A real conversation about what you’re trying to build, who it’s for, and what success looks like. Usually takes an hour.

Competitor research. This is the one research activity that actually matters. We look at what’s already in the market, what’s working, what’s not. Other people have shipped products and gotten real feedback. We learn from their experiments, not our hypotheticals.

Sketches and code. We sketch rough flows when we need to think through something complex. Then we build. Not wireframes, not prototypes, the actual thing. Working software in days, not months.

Iteration from real usage. Once something exists, we put it in front of users and watch what happens. Then we iterate. Resources go toward learning from reality, not predicting it.

The goal is to collapse the time between idea and feedback. Every week you spend planning is a week you’re not learning.

When This Doesn’t Work

I’ll be honest: this approach isn’t universal.

If you’re building for healthcare or finance, there are regulatory constraints that require more upfront planning. If you’re integrating with legacy systems, you need to understand those systems before you touch them. If you’re building something genuinely novel with no market comparisons, some exploration is necessary.

But most early-stage products aren’t that. Most founders I talk to are building something that has clear comparisons, serves a known audience, and could ship a first version in weeks if they stopped planning and started building.

The Real Question

If you’ve been stuck in planning mode, ask yourself: what would happen if you just started building?

Not a perfect build. Not a complete build. Just something real that you can put in front of users and learn from.

Maybe the answer isn’t more research. Maybe it’s just building the thing.

If that sounds like a better way to spend your time and money, let’s talk.