MVP Isn't a Minimal Product. It's the Cost of Entry.

START SMALL

You Don't Have to Start With Development

Why big digital products don't always need to be built in full, and how the first working stage shows you where it's actually worth investing.

Big digital products almost always look convincing before they ever start working.

There's an idea. A pitch deck. A business model. A spec that runs dozens of pages. A list of features that “absolutely have to be” in version one. There's a budget.

And sometimes there's $100,000.

That's the moment a very simple question comes up, one that, for some reason, usually gets asked last:

Do we actually need to build all of this right now?

I'm not against big products. Quite the opposite. I like working with complex systems, architecture, a large number of features, integrations, business processes. But I stopped believing a long time ago that a complex product has to start with complex development.

To me, an MVP isn't a minimal product. It's the cost of entry.

It's a chance to build a first working version, put it in front of the real world, and get an answer to the question that actually matters: is it worth building further, and if so, what exactly?

And sometimes that cost of entry is far lower than a founder assumes.

Today the whole landscape has changed.

There's now a huge number of tools that let you launch a landing page, a prototype, a form, a test funnel, an automation, or even a fairly complex first version of a product on your own. Many of them are cheap. Some let you start for close to nothing.

AI tools are a separate part of this, they've all but removed the barrier to building something. But AI answers the question of “how fast can we put this together,” not “what should we actually build”, and those are completely different questions. We wrote about this in more depth here: AI Made Building Easier. Building a Successful Product, Not So Much.

And I think that's good news.

If a founder can test part of their hypothesis on their own in a few hours and get real first data, I don't see the point in selling them development just because we know how to build things.

Sometimes we show a client directly how to test an idea themselves.

Because our job isn't to do as much development as possible.

Our job is to help a business understand what's actually worth building.

That's a fundamental difference.

There's another, perfectly normal-for-the-industry model out there: the client shows up with a spec, the agency builds it, the project gets handed over. If the product doesn't work after that, you can always say:

“But that was your spec.”

Technically, that's correct.

I think that kind of work is wrong.

If, during development, we see that the business hypothesis itself is questionable, our job isn't to quietly keep building. Our job is to point out the risk and offer a cheaper way to test it.

Because you can build a bad product perfectly.

That won't make it good business.

PERETZ FIRST MVP

PERETZ's First MVP Was Small Too

One of the clearest examples for me is our own design studio.

When we launched Dezzign, we didn't start with a big multi-page site with dozens of sections, hundreds of projects, and a mountain of content.

We simply didn't have hundreds of projects yet.

We had a small set of work we could actually show.

We built a landing page, ran ads, hooked up analytics, and started watching what happened.

Who was showing up.

What they reacted to.

Which offers worked.

What led to inquiries.

What didn't work at all.

Only after that did we start building the system out.

The first landing page grew into a site on a CMS. Then came the next site, this time on a custom framework.

In other words, we never tried to guess the final product in advance.

We started with what we could test.

And the product grew alongside the data.

For me, that's one of the most important things about MVP development: the first stage doesn't have to be the final architecture. It just has to give you enough information to decide what comes next.

MEDPRESSO

Medpresso: When a Product Is Too Big for One Launch

Another example is Medpresso.

That's a completely different scale. A large medical portal, with that much content, that many features and business processes, can't reasonably be treated as a small product.

But that doesn't mean you build the whole thing first and only then show it to the market.

We launched it in stages.

A new part of the product would go live, we'd watch how it performed. We'd ship the next piece of functionality, get feedback again. We analyzed user behavior, refined things, tested, and kept moving.

At some point, the launch process itself became part of building the product.

We told our audience what was coming next, which features we were working on, which pages were about to go live. That created interest before the next stage even existed. You can read the fuller story of that build in the Medpresso case study.

And in my view, that turned out to be far more effective than spending a year and a half building the entire product with no way to test it in the real world.

Because big products have one unpleasant trait:

it's very easy to build them for longer than the business can afford.

EAT THE BUSINESS

A Big Project Can Eat a Business Alive

When a team jumps straight into building a big platform, it ends up making an enormous number of decisions based on assumptions.

Which feature is needed?

What's the right architecture?

Which integrations will we need?

What user behavior model will turn out to be correct?

Which processes need automating?

Every one of those decisions costs design time, development time, project management, and money.

And then it can turn out the business never needed half of what got built.

That's not an exaggeration. According to Pendo's research, based on real usage telemetry across hundreds of digital products, about 80% of features in the average product go almost completely unused.

And here's where a problem shows up that I think is far more serious than just going over budget.

Development can eat the money the business actually needed to launch.

A company spent $100,000 building a product.

The product is done.

But now there's no money left for marketing.

No budget to acquire the first users.

No resources for sales.

No money for experiments.

The company ends up with a finished product and no way to test whether the market wants it.

That's one of the most expensive mistakes in digital product development.

According to CB Insights, which analyzed 385 failed startups, the leading cause of failure in 43% of cases was a mismatch between the product and the market. Running out of capital, usually cited as the cause of death, is really just a symptom that shows up later.

Which is why I often say: not launching an MVP can end up being far more expensive than launching one.

NOT A DEV PLAN

$100,000 Isn't a Development Plan

Picture a founder coming to me and saying:

“I have an idea for a platform. Budget: $100,000.”

The first thing I ask isn't how many features they want.

I ask:

What is this platform actually for?

What's the business idea behind it? What business process is it supposed to solve? Who's the customer? Who's the investor? And why was the budget set at exactly $100,000 in the first place?

Because we can burn through that money very fast. And come out the other side without the one answer that actually matters: does the market need this product?

Sometimes, after some research, it turns out $100,000 really is necessary.

Sometimes it turns out $20,000 is enough to start.

Sometimes it's $5,000.

And sometimes you don't need to start with development at all.

There's a huge number of tools today that let a founder test part of their idea on their own: a landing page, a prototype, a form, a test funnel, an automation, or even a first working scenario of the product.

If that can be done independently and produce real data within a few days, I'd rather show a client how to do that than sell them development right away.

Because we shouldn't be making money off a client not yet knowing whether their idea works.

TOO BIG AN IDEA

A Good Idea Can Also Be Too Big

There's another problem that's often invisible at the start.

A founder can genuinely believe their idea is simple enough.

That's normal.

They see the business from the outside: a few features, a personal account, a catalog, an integration, payments.

We start taking it apart from the inside.

We look at the market. User scenarios. Business processes. Integrations. Data. Constraints. Future support. And suddenly it turns out that behind the simple phrase “build a platform” sits a genuinely complex system.

And that's when a good idea can hit not a technical limit, but a budget breakwater.

That, I'd say, is one of the most unpleasant scenarios out there.

Research shows the market exists. People need the product. The business model can potentially work.

But building it properly costs so much that the company can't afford to make the trip.

At that point there are only two bad options: drop the idea, or try to build everything at once and put the whole business at risk.

There's a third option.

Break the product into stages.

Cut what isn't needed for the first test. Push features that can wait to a later stage. Use a simpler piece of technology. Test part of the hypothesis with no development at all.

Not because the idea is bad.

But because the business has to survive long enough for a good idea to prove itself.

NOT TEMPORARY

An MVP Doesn't Have to Be Temporary

This is where the eternal technology argument comes in.

Someone says:

“We built the MVP on a CMS, and we'll definitely move everything to Laravel later.”

I always ask:

Why?

If the answer is “because Laravel is faster,” I ask: faster in what sense?

If the answer is “because Symfony is better for team development,” the next question is: what's your business model, and does that constraint actually exist right now?

Technology is a tool.

I can buy the most expensive, most powerful tool in the shop. But if a plain screwdriver does the job just as well, the user won't feel the difference.

A CMS can be a great solution.

Custom development can be a great solution.

A hybrid can be a great solution.

The problem starts when the technology gets picked not for the business need, but for the feeling that we're building something serious.

It's the same question that exists at the level of the whole product , build it yourself or use something that already exists. The build vs. buy equation has changed a lot over the past few years, and most companies still haven't recalculated it: The Build vs. Buy Equation Has Changed. Most Companies Haven't Recalculated It.

And this isn't only about development.

DOESN'T LOOK SMALL

A Small Product Shouldn't Look Small

There's one more thing I consider essential.

MVPs often get treated as something you can hand a user with the words:

“Well, you understand, this is still just an MVP.”

No.

If a product is small in terms of functionality, that doesn't mean it has to be bad.

We can build an MVP with a full UX, solid UI, and pixel-perfect execution.

It can look like a finished product.

It just has exactly as many features as needed to test the first hypothesis.

What should be minimal is scope, not quality.

And in that sense, the ideal MVP looks very simple to me:

Launch it.

Get the data.

Learn what works.

Fix what doesn't.

Launch the next stage.

That's not a compromise.

That's just a normal way to build a product.

SHOWS NOT TO BUILD

Sometimes an MVP Shows You Shouldn't Build Any Further

I've also had a project where the MVP, essentially, confirmed our original doubts.

The idea was interesting: the client wanted to sell customized video content and build a full e-commerce product around it.

(I'm not naming the client or the product, it's a confidential project. But the mechanics matter more than the details.)

We built the product. It was well-designed, technically interesting, and fully functional.

But the question came up before development even started:

does enough demand actually exist?

And that's exactly where full development wasn't the right first step. The client wanted a complete e-commerce build right away, when the smarter move would have been testing the model first.

That's a good example of why an MVP isn't only about saving money.

Sometimes its main job is to let you fail cheaply.

Because if a hypothesis doesn't hold up after a small experiment, that's a useful outcome.

You didn't lose a year.

You didn't spend the whole budget.

You didn't build a massive system you now have to maintain.

You just got an answer.

And that answer might be:

“No, this model needs to change.”

That's also an MVP success.

COSTLIEST MISTAKE

Sometimes the Most Expensive Mistake Is Launching Nothing at All

But there's a flip side.

I know clients who had a genuinely good idea and just never worked up the nerve to launch it.

That's a risk too.

Because good open space in a market rarely stays open forever.

Sometimes I look at an old idea from a client and think: this is exactly the moment to test it. These days, that doesn't require a huge budget. You can put together a minimal version, launch it, watch how the market reacts, and decide from there whether it's worth investing further.

Sometimes I genuinely want to call and say:

“Take another look at that idea. This might be the moment to test it.”

But there's an important boundary here.

We can't want a business more than its owner does.

The push has to come from the person who's actually going to build it.

Because the strongest projects always share one trait: the owner has fire in their eyes.

There's a real desire to test the idea.

A willingness to accept a “no,” not just a “yes.”

A willingness to change what they thought was right, once the first result comes in.

When that's there, an MVP stops being just a development tool.

It becomes a way to give a good idea a chance to start.

HEAR IT FIRST

Sometimes You Need to Hear a Product Before It Comes Together Fully

There's a piece of music I sometimes come back to when I'm thinking about launching a product.

It opens with something strange. You're not sure yet what you're listening to. Someone walks onstage who looks almost like a character from a different story. The music starts out very simple.

Then, gradually, the instruments come in.

One.

Two.

Three.

And at some point you realize that what first seemed strange and unfinished was only the beginning the whole time.

I think a good MVP works about the same way.

It doesn't have to show the whole product right away.

It has to hit the first note.

If that note works, you can add the next one.

Then another.

And gradually, out of a small working solution, a product emerges that's already impossible to compare to where it started.

And here's the part I find most interesting:

The MVP stops being an MVP. It becomes the product.

CONVERSATION WITH REALITY

An MVP Is a Conversation Between a Business and Reality

At the end of the day, I don't treat an MVP as a mandatory stage of every project.

It's a tool.

Sometimes the right MVP is a landing page.

Sometimes it's a prototype.

Sometimes it's a small e-commerce build.

Sometimes it's the first piece of a large platform.

Sometimes it's a product a founder can put together entirely on their own, using the tools available today.

And sometimes the research shows you don't need to build an MVP yet.

That's a normal outcome too.

Before development starts, I'd want a business to have answers to at least three questions:

Which hypothesis are we testing first?

What's the minimum working product that will test it?

What metric will tell us the hypothesis is actually working?

That's exactly what we built a dedicated format for, Strategic Session: a conversation where we work through the business together instead of jumping straight to selling development.

If you have the answers, you can build.

At that point, it's also worth thinking not just about the product, but about the team that's going to build it: How to Hire a Remote Dev Team Without Getting Burned.

If you don't have the answers, you probably need to research first.

And if there's a way to test a hypothesis for $500 instead of $50,000, I think it's worth trying the $500 version first.

Not because we want to do less.

But because we want to understand more before the business puts in more.

Right now we're working through a new MVP project in healthcare. I can't talk about the product itself yet, that's confidential. But I can tell you how the client found us: they came to us after reading exactly this kind of material about how we think about business. Not a portfolio. Not case studies. Not a price list, how we actually think. And that, on its own, is decent proof that WHY works better than HOW. Working on that project is part of what pushed me to put these thoughts into words.

Every complex project brings me back to the same question:

What actually needs to get built first?

Because sometimes the best way to build a big system is to not build the whole thing at once.

And that's exactly why, to me, an MVP isn't a minimal product.

It's the cost of entry.

Author: Yevhen Borovoi, Founder at Peretz Agency.