Build the Version You Can Build Today
Your first version doesn’t need to prove the whole idea. It needs to make the idea real.
Ideas have a strange advantage over finished things.
They don’t have bugs.
They don’t have awkward pages, missing features, confusing decisions, or parts you wish you had done differently. In your head, everything works exactly as intended.
Then you try to build it.
Suddenly, the clean idea becomes a collection of decisions.
What does it actually do?
Who is it for?
What belongs in the first version?
What can wait?
What happens when someone uses it differently than you expected?
And the question that can quietly keep a project unfinished for months:
What does this eventually need to become?
I’ve started to think that’s usually the wrong question to ask at the beginning.
I’m much more interested in a smaller one.
What can I make real today
The imaginary version is always bigger
When I start thinking about a new project, my brain rarely stops at version one.
I can see the expanded product before the basic one exists.
More features.
More pages.
Better systems.
Different ways it could make money.
Things I could add six months from now.
Maybe an entirely different direction it could eventually take.
There’s nothing wrong with thinking ahead. Some amount of planning prevents obvious mistakes.
But there is a point where thinking about the future stops helping the present.
You start building infrastructure for users you don’t have.
Creating systems for problems you haven’t experienced.
Adding features because they make sense theoretically.
Designing around a scale the project hasn’t earned yet.
The project gets bigger.
The launch gets further away.
And the original idea remains exactly what it was.
An idea.
Scope is a business decision
It’s easy to treat scope as a development problem.
I think it’s just as much a business problem.
Every additional feature costs something.
Maybe not money directly, especially if you’re making it yourself, but it costs time, attention, complexity, maintenance, and another decision that has to be made before the thing can leave your computer.
That’s still a cost.
So I’ve started asking a different question when I think something belongs in the first version:
Does this need to exist for the idea to work?
Not:
Would this be useful?
Would this make it better?
Could someone eventually want this?
Those questions produce very different answers.
There are countless things that could make a product better.
Far fewer things are necessary to make it useful.
Finding that line is one of the most valuable parts of building something.
Make the smallest version that proves something
“Start small” can sound like advice to lower your ambitions.
I don’t see it that way.
The ambition can stay large.
The first test should be small.
If I think something can become a useful business, I don’t need to build the entire business to test the assumption underneath it.
I need enough of the product to answer something important.
Will anyone use this?
Does it solve the problem the way I thought it would?
Can someone understand it without me standing beside them?
Will anyone pay for it?
Will they come back?
What do they ask for after using it?
Those answers are much more valuable than another month of speculation.
The first version isn’t supposed to prove that your entire vision is correct.
It’s supposed to give you better information.
Framebrix is teaching me this in real time
I’ve been thinking about this a lot while working on Framebrix.
The larger idea is easy to imagine.
Once you start thinking about templates, components, systems, resources, and everything that could sit around them, the possibilities expand quickly.
That’s exciting.
It’s also exactly how a relatively simple idea can turn into something that takes forever to release.
So instead of trying to make Framebrix immediately represent everything I think it could eventually become, I’m trying to focus on what it needs to be useful now.
A strong starting point.
Something thoughtfully designed.
Something another person can actually use.
Something real enough to learn from.
There will always be more I could add.
But I don’t need to predict every version of Framebrix before the first one has had a chance to exist.
I’d rather let the real thing teach me what the next thing should be.
Real use changes the roadmap
Planning has one major weakness.
Nobody has used the thing yet.
Before release, your roadmap is mostly a collection of educated guesses.
Some will be right.
Others will feel embarrassingly obvious in hindsight.
You might spend days building something nobody mentions and discover that the feature you considered unimportant is the one people keep asking about.
You might learn that your explanation is confusing.
You might discover that people don’t use the product the way you imagined.
Or the project might attract a completely different kind of customer than the one you originally had in mind.
You can’t plan your way into that information.
You have to put something in front of people.
That’s when the project stops being a theory.
Version one should create version two
This is probably the biggest shift in how I think about early products.
Version one doesn’t need to contain the future.
It needs to create enough information to make version two smarter.
That changes what “good enough” means.
Good enough doesn’t mean careless.
It doesn’t mean ugly.
It doesn’t mean broken.
And it definitely doesn’t mean releasing something you don’t believe in.
It means the product accomplishes what you said it would accomplish, even if the scope is intentionally narrow.
That’s an important distinction.
You can care deeply about quality while still limiting what you’re trying to build.
In fact, smaller scope can make quality easier.
Instead of spreading your attention across twenty features, you can make five work extremely well.
Instead of designing fifteen pages, you can make the three that matter feel considered.
Instead of trying to serve everyone who might someday use the product, you can make something genuinely useful for the first group.
Small doesn’t have to feel unfinished.
It can feel focused.
Architecture can become another form of procrastination
There’s a particular kind of procrastination that feels extremely responsible.
Planning systems.
Choosing technology.
Researching platforms.
Thinking about scalability.
Rebuilding the structure before the existing structure has actually failed.
It feels productive because you’re making serious decisions.
Sometimes those decisions are necessary.
Sometimes you’re designing the headquarters for a company that doesn’t have a customer yet.
I’ve caught myself doing versions of this.
The temptation is understandable.
It’s satisfying to build something clean enough that you imagine never needing to rebuild it.
But that’s rarely how real projects work.
Requirements change.
Tools change.
Customers change.
Your own understanding changes.
You change.
Trying to create an architecture that perfectly anticipates all of that can consume more time than simply building something reasonable and adapting when reality demands it.
Future flexibility matters.
Future perfection doesn’t exist.
Constraints can make the product better
A limited first version forces clarity.
If you only have enough time to build three things, which three actually matter?
If the homepage can communicate one idea, what is it?
If the product solves one problem exceptionally well, which problem should that be?
Constraints remove the luxury of hiding behind features.
You have to understand the core of the thing.
That can make a smaller product more compelling than a larger one.
The customer doesn’t necessarily care how many things you built.
They care whether the thing they came for works.
That’s a useful standard.
You can build the rest later
The internet has made iteration incredibly cheap.
A website isn’t printed in stone.
Software isn’t finished when version 1.0 appears.
A digital product can change tomorrow.
A business can discover a better customer.
A brand can sharpen its positioning.
A feature can be removed.
A completely new one can appear.
That should give us permission to stop treating every early decision like a permanent commitment.
You don’t have to solve the next five years.
You have to make a reasonable decision with the information you have now.
Then earn better information.
Build.
Release.
Observe.
Adjust.
The loop is more important than getting every individual decision right.
Make the idea real
There will always be a more complete version you could build.
A more sophisticated system.
A better design.
A longer feature list.
A more impressive launch.
That’s not the version competing for your attention.
The real competition is between the version that exists and the version that doesn’t.
So build what you can build today.
Make it useful.
Make it intentional.
Give it enough substance that someone can experience the idea instead of hearing you explain it.
Then put it somewhere reality can reach it.
Your first version doesn’t need to prove everything the idea could become.
It only needs to prove that the idea can become something.
You can build the rest from there.