Test Before You Build

"We don't have time to test. We need to ship."

I hear this constantly. Founders convinced that every day spent not coding is a day wasted. That validation is a luxury for companies with runway to burn.

They've got it backwards.

The fastest founders I've worked with aren't the ones who write code quickest. They're the ones who learn quickest. And learning doesn't require a single line of code.

The Speed Paradox

Most founders equate speed with output. Lines of code. Features shipped. Commits pushed.

But code is expensive. It takes time to write, time to test, time to maintain. And wrong code? That's the most expensive thing you can build. You don't just lose the time building it. You lose the time ripping it out. You lose the momentum. Sometimes you lose the company.

Real speed isn't shipping velocity. It's learning velocity.

How fast can you figure out if you're building the right thing? How quickly can you kill a bad idea before it kills your runway?

That's the speed that matters.

How We Test

The pattern is clear.

Before we write code, we ask three questions:

What's the riskiest assumption? Every product has one. The belief that, if wrong, makes everything else irrelevant. Find it.

Can we test it without building? Usually yes. A Figma prototype. A landing page. A conversation. Something that gets real signal without real code.

What would make us abandon this direction? Define failure before you start. Otherwise you'll rationalise your way past every red flag.

This isn't about being slow. It's about being deliberate.

We can prototype a core flow in days. Test it with five users in a week. Know whether we're on the right track before we've written a line of production code.

Same timeline as "just building it." Wildly different outcomes.

The Founders Who Resist

I've seen the same pattern dozens of times.

Founder comes in hot. They know exactly what users want. Testing would slow them down. Let's just build and see what happens.

Three months of development. Features polished. Edge cases handled. Launch day arrives.

Crickets.

The product works perfectly. It just solves a problem nobody has. Or solves it in a way nobody wants. Or targets users who don't exist.

Now they're pivoting. But they've burned three months of runway learning what a week of testing would have told them.

That's not fast. That's expensive.

The Founders Who Embrace It

Different pattern.

Week one: Prototype the core flow. Not the whole product. The one thing that has to work.

Week two: Put it in front of five real users. Watch them use it. Listen to what they say. Watch what they do. These often differ.

Week three: Iterate. Kill what doesn't work. Double down on what does. Prototype again if needed.

Week four: Build with confidence. Not certainty — you never get certainty. But confidence that you're solving a real problem in a way real users want.

Same month. One founder has validated direction. The other has validated code that might be worthless.

MVP Means Minimum Viable Learning

Most founders get MVP wrong.

They think it means "everything we want, but smaller." So they cut features but keep the scope. Ship something half-baked and call it minimum viable.

That's not MVP. That's just a worse product.

MVP is the smallest thing that tests your riskiest assumption. Nothing more.

Sometimes that's a landing page. Sometimes it's a prototype. Sometimes it's a conversation. Occasionally it's actual software.

Scope based on what you need to learn, not what you want to build.

Why We Push for This

We take equity in the ventures we build. That means our upside is tied to yours.

An agency can bill for building the wrong thing. Pivot required? New scope, new invoice. Their incentive is to build what's specified, not to question whether it should be built at all.

When you have skin in the game, that changes. Building the wrong thing costs us too. So we push for testing — not because it's a nice process, but because it's the only way to build things that actually work.

Aligned incentives make validation non-negotiable.

The Mantra

Slow is fast.

Not slow as in sluggish. Slow as in deliberate. Taking the time to validate before you build. To test before you scale. To learn before you commit.

The founders who move fastest are the ones who waste the least. They kill bad ideas early. They find good ideas quickly. They build with conviction instead of hope.

Speed isn't about how fast you can code. It's about how fast you can learn.

Test before you build. Every time.