The 8-week MVP: how to launch a product idea without burning the budget

How to launch an MVP in eight weeks: problem before product, the essential scope, prototype, lean architecture, core flow, user testing and validation without burning the budget.

The most expensive mistake in software product development is not writing bad code. It is building something the market does not need.

Many projects start with enthusiasm, approved budgets and long feature lists. Teams discuss a mobile app, dashboards, artificial intelligence, automations, ERP integration, notifications, reports and dozens of use cases.

After six or nine months, however, the question the team should have asked in week one appears:

Do people actually want this product?

That is why the MVP — Minimum Viable Product — remains one of the most useful concepts in modern software development.

An MVP is not a poor or incomplete version of the final product.

It is the smallest version of the product that can demonstrate whether the idea has value for real users.

And if it is designed correctly, an MVP can be launched in about eight weeks without consuming a disproportionate budget.

The key is not to work faster. The key is to build less, but more relevant.

Week 1: the problem before the product

Week one should not start with the framework, the database or the cloud.

It should start with the problem.

• What problem is the product trying to solve?
• For whom?
• How often does it appear?
• How painful is it?
• How do people solve it today?
• And, perhaps most importantly, would someone pay for a better solution?

These questions sound simple, but many startups and corporate projects do not have clear answers.

For example, “we want a DMS with AI” is not a problem. It is a solution idea.

The real problem may sound like this:

• “Companies waste time because documents are scattered across folders, emails and different systems, and users struggle to find information.”
• “Operators manually enter data from hundreds of documents a day, which creates delays and errors.”
• “Managers do not know when contracts expire because the information is buried in PDFs.”

This is where the product begins.

In week one you need to talk to potential users. You do not necessarily need expensive market studies. Ten good conversations with people who have the problem can be more valuable than fifty slides about market size.

The question should not be “Would you like an app that does X?”. Most people will say yes.

More useful questions are:

• “How do you solve this problem now?”
• “How much time do you lose?”
• “What happens if you do not solve it?”
• “What solution are you already paying for?”
• “What frustrates you the most?”

A good MVP starts with observing current behaviour, not with enthusiasm for a new technology.

Week 2: cut features until only the essential remains

Week two is probably the hardest.

The team must decide what it will not build.

Almost every product idea comes with a long feature list. A DMS may have registry, OCR, workflow, versioning, e-signature, AI chat, semantic search, a mobile app, audit, dashboards and Microsoft 365 integration. A marketplace may have profiles, payments, ratings, chat, recommendations, subscriptions, notifications and a mobile app. A CRM may have lead management, pipeline, marketing automation, reports, email and AI.

The problem is that all of these can be useful. But not all are necessary to validate the idea.

A simple exercise is to split features into three categories:

• Must have — without them the product does not solve the main problem.
• Should have — important, but they can come in the next version.
• Nice to have — sound good in a presentation, but do not influence validation.

For an MVP, the first category must be very small.

If the MVP has twenty “mandatory” features, it is probably no longer an MVP. It is already the first full commercial version. And that is where budget consumption begins.

An MVP should demonstrate one thing very well. For example: “Users will upload documents into a system that classifies them automatically and lets them find information faster.” That is enough.

You do not need a mobile app, complex integrations and twenty reports from day one.

Week 3: prototype before code

Week three can save tens of thousands of euros.

Before developers build the product, a prototype can be created. It can be made in Figma or a similar tool.

It does not need to work fully. It needs to simulate the user experience.

The user clicks “Add document”. A form appears. The document is analysed. The system shows the result. The user searches for the document. They find it.

Such a prototype can be built in a few days and tested with real users.

If users do not understand the product in a prototype, they probably will not understand it after three months of development either.

Here problems can be discovered very cheaply. Maybe the button is in the wrong place. Maybe the flow has too many steps. Maybe the user does not understand the technical terms. Maybe the feature the team thought was primary is completely ignored.

It is much cheaper to change a screen in a prototype than to rebuild a feature after the backend, API and database are already built.

Week 4: architecture good enough, not perfect

One of the most common sources of cost is over-engineering the architecture.

Teams start preparing the product for a million users before they have ten. They discuss microservices, Kubernetes, multi-region replication, event streaming and distributed infrastructures.

All of these can make sense in a mature product. But not necessarily in an MVP.

In the first eight weeks, architecture must meet three criteria:

• stable enough for initial users;
• able to be extended;
• not consuming disproportionate time and money.

Often a well-organised monolith is a better starting choice than ten microservices. A single repository can be more efficient than a highly fragmented architecture. A managed cloud service can be better than a complex infrastructure built by hand.

What matters is not confusing simplicity with a lack of professionalism. A simple, well-thought-out architecture is often better than a sophisticated one built too early.

Do not build what you can integrate

Another fundamental principle for an MVP is: do not reinvent standard components.

• Need authentication? Mature solutions already exist.
• Need payments? Use an established processor.
• Need file storage? Specialised services exist.
• Need OCR? You can integrate an existing engine.
• Need a DMS? It may be more efficient to build on a mature open-source platform than to write upload, versioning, permissions and indexing from scratch.

This is one of the greatest advantages of the current software ecosystem. You can build a valuable product by combining existing components and adding your differentiator.

The client does not care whether your team wrote its own authentication system. They care whether the product solves their problem.

Weeks 5 and 6: build the main flow

This is when the MVP actually starts becoming a product.

The goal is not for every corner of the application to be perfect. The goal is for the main flow to work end to end.

If the product is an intelligent DMS, the flow may be:

• the user signs in;
• uploads a document;
• the document is processed;
• the system classifies it;
• the user verifies the result;
• the document is saved;
• it can later be found through search.

This flow must work well.

A frequent mistake is spreading effort across too many features. The team builds a bit of the dashboard, a bit of notifications, a bit of reports and a bit of the mobile app. In the end, nothing is complete.

Better one flow that works very well than ten features finished to 60%.

Good UI, not spectacular UI

Design matters a great deal. But there is a difference between a product that is easy to use and a product that burns budget trying to win design awards.

In an MVP, the interface must be: clear, fast, consistent, responsive and easy to understand.

You do not need sophisticated animations, elaborate transitions and dozens of custom components. An existing design system and a component library can save weeks.

This is especially true for B2B products. An accountant does not buy a DMS because the button has the most spectacular animation. They buy it because they find documents quickly and lose less time.

Week 7: testing with real users

At this stage the truth appears. Not the truth from internal meetings. Not the truth from the PowerPoint presentation. The truth from usage.

A small group of real users must be selected. It can be five. It can be ten. What matters is that they actually use the product.

Concrete behaviours must be observed:

• Where do they get stuck?
• What do they not understand?
• Which feature do they use the most?
• Which feature do they ignore?
• What question do they keep asking?
• Where do they abandon the flow?

Data is more important than opinions.

A user may say “I like the product.” But if they do not come back the next day, the problem remains.

Another user may criticise the design, but uses the app daily because it saves them two hours of work. That is a much stronger signal.

Week 8: launch, do not delay

There is a moment in almost every project when the team says: “We just need a few more things before launch.”

That sentence can delay the product for months. One more report. One more integration. A bit more design. More optimisation. One more dashboard.

The problem is that the product cannot be validated correctly before it reaches users.

In week eight, the objective must be launch. It can be beta. It can be a pilot. It can be invite-only access. But there must be real users.

From that moment, true product development begins.

What to measure after launch

An MVP is not only a product. It is an experiment. That is why there must be indicators. Not hundreds of KPIs. A few.

• How many users start the main flow?
• How many finish it?
• How long does it take?
• How many return?
• How often do they use the product?
• Would they pay for it?
• Do they recommend the product?

For a B2B product there is an even more important indicator: does the product save money or time?

If a DMS reduces document processing time from five minutes to one minute, the value can be calculated very clearly. If a system automates 1,000 documents a month, the savings can become the main sales argument.

Where budget burns most often

A few patterns appear constantly in projects that become too expensive:

• Building web, iOS and Android at the same time. Often the MVP can start with responsive web only.
• All integrations in the first version. Integrating five ERPs can consume more time than the core product.
• Disproportionately complex infrastructure.
• AI introduced only for marketing. If AI does not solve a concrete problem, it becomes a cost, not an advantage.
• No one deciding priorities. If every department can add features, the list will never end.

How much should an MVP cost?

There is no universal figure. An MVP can cost a few thousand euros or a few hundred thousand, depending on the domain.

A medical system is different from a simple appointment app. A fintech product is different from an internal dashboard.

But there is a healthy rule: the MVP budget must be proportional to the level of uncertainty.

If we do not yet know whether anyone wants the product, it does not make sense to invest as if we already knew we would have 100,000 users.

The first investment must buy information. We want to learn: does the problem exist? does the product solve it? do users use it? do they pay?

If the answers are positive, the investment can grow.

MVP does not mean a cheap product

This is an important distinction.

An MVP does not mean “the cheapest thing we can build”. It means the most efficient version for validation.

Security must not be ignored. Backup must not be ignored. Data protection must not be ignored. The code must not be impossible to maintain.

There is a difference between removing unnecessary features and removing fundamentals.

A good MVP is simple. Not negligent.

When is the MVP a success?

Many people think success means the product works. That is not enough.

A product can work perfectly from a technical perspective and still be a commercial failure.

An MVP is a success if it provides a clear answer.

• “Yes, there is a market.”
• “People have the problem, but they do not want the solution in this form.”
• “The feature we thought they wanted is useless, but they intensively use another one.”

Even a negative result can be very valuable.

If after eight weeks and a controlled budget you discover the idea does not work, you may have saved a year of development and hundreds of thousands of euros. That is one of the main purposes of an MVP.

From MVP to a real product

After validation, the next stage begins. Here the features cut initially can appear: mobile app, advanced dashboards, integrations, automations, more sophisticated AI, scaling, reporting.

But now decisions are based on data. We no longer build what we think people want. We build what we see them use.

That is the difference between product-oriented development and feature-list-oriented development.

Eight weeks to buy certainty

An MVP delivered in eight weeks should not be seen as the final product. It should be seen as a risk-reduction method.

• In week one you understand the problem.
• In week two you reduce the product to the essential.
• In week three you validate the experience through a prototype.
• In week four you choose the right architecture.
• In weeks five and six you build the main flow.
• In week seven you test with users.
• In week eight you launch.

It sounds simple. In practice, the hardest thing is not development. It is the discipline to say no.

Not yet to a feature. Not yet to an integration. Not to an architecture built for a scale the product does not have. Not to the idea that the first version must be perfect.

The best MVPs do not impress through the number of features. They impress through how quickly they demonstrate whether the product is worth building.

In the end, that is the goal. Not to save money at any cost. But to spend money only when you have better and better reasons to do so.