You probably did what you were supposed to do: built the smallest useful product you could, kept the team small, made trade-offs, chose speed over elegance, chose managed services rather than building everything yourself, or left some rough spots because the bigger question isn’t: “Can we build the perfect system?”; it’s: “Does anyone actually want this?” That is what an MVP is for. You need to learn if customers can use the product, if they do care, if they would pay, your wrong assumptions, workflows that actually matter, features that should disappear, and ones that deserve investment.
Spending months building a beautiful system before knowing whether the market wants it can be a terrible use of money. So let's remove an important misconception first: Your MVP does not have to be beautifully engineered.
There is an equally important idea that often gets missed: Simple engineering is not the same as fragile engineering. And there is another one: A shortcut that is reasonable today may become expensive tomorrow. That is where the real problem starts. Not when your MVP is simple, code is imperfect, or even when technical debt exists. The problem starts when the business grows, and the engineering assumptions underneath it no longer fit the business.
Your MVP does not necessarily fail. The context changes.
Your MVP was optimized for learning
An early-stage company operates under a lot of uncertainty because you may not know how many customers you will have, which features will matter, how much data you will collect, which integrations customers will request, and which workflows will eventually become the heart of the business. That uncertainty makes simplicity valuable.
A small application may be easier for a small team to understand. A managed database may be better than operating your own database infrastructure. A single application may be easier to deploy than a collection of separately managed services. A manual workflow may be perfectly acceptable while only a few people use the product.
You may consciously decide that some engineering work can wait. Those can all be sensible decisions. The key is that they are trade-offs because you are exchanging something like giving up some automation to move faster, accepting some manual work to avoid building infrastructure too early, and accepting some internal mess. After all, the part of the product is still changing. That is not automatically bad engineering. It can be good business judgment. The mistake comes when the company stops revisiting the trade-off.
The forgotten shortcut is the problem.
If you have a manual deployment process with one or two engineers and a small customer base, that might be manageable since everyone knows what to do, everyone knows the system, a release takes a few minutes, and the risk is limited.
Now, when the business grows and more engineers come on board, the following happens: the application handles important customer transactions, feature releases happen several times a week, and customers depend on the product more.
The same shortcut now has a completely different cost. The business simply became more dependent on the deployment process. This is the pattern to look for. The decision stayed the same. The consequences changed.
Sometimes, the original decision really was bad.
“The context changed” should not become an excuse for everything. Some engineering choices are poor from the beginning. For example, a product that handles sensitive customer information should not ignore basic security just because it is “only an MVP”; a business-critical system should not treat backups as optional; a financial workflow should not rely on fragile processes simply because the company is small; and a team should not knowingly create a situation where losing one person means losing the ability to operate the product.
There is a minimum engineering floor. You can postpone elegance but not casually postpone basic protection of the business and its customers. That means founders need to distinguish between acceptable shortcuts and dangerous shortcuts. An acceptable shortcut may create future work. A dangerous shortcut can create immediate or unacceptable risk. That difference is far more useful than simply calling everything “technical debt.”
Simple is not the same as fragile.
A simple system has fewer moving parts. A fragile system depends on too many things going right. Those are not the same thing.
A single application can be simple and reliable. It can also be simple and impossible to change safely.
A small database can be perfectly adequate. It can also have design problems that cause important customer workflows to fail.
Simplicity should help the business, not become a source of risk and friction.
Your business can outgrow an MVP in more ways than traffic.
Founders often hear the word “scale” and think about more users, more requests, and more traffic. That matters, but it is only one kind of growth. Your business can become more demanding because you have more customers, transactions, data, integrations, engineers, product workflows, revenue flowing through the system, countries or markets, stronger customer expectations, and stricter operational requirements.
A system can handle a large number of users and still be a poor system for a growing company because software also needs to scale with change.
Can your team add features? Can new engineers understand the system? Can you recover from failures? Can you safely modify important workflows? Can you operate the product without relying on a single person to hold the whole system in their head? That is still scaling.
Software needs to scale with the business, not only with traffic.
When an MVP becomes a constraint.
This is where the conversation needs to move away from theory. You need to know whether your architecture is constraining the business, not if it’s fashionable. A constraint is something that limits what the business can do, and that might be how quickly you can ship, how safely you can change the product, how reliably customers can use it, how much it costs to operate, or how quickly you can recover from failure, or how much the team depends on certain people. The best evidence usually appears in patterns.
1. Every new feature creates another problem.
You add a feature, and something unrelated breaks. You fix it, and another workflow becomes slow. You change that, and now a different integration stops working. The founder starts thinking, “Why does every feature take longer than it used to?” This is one of the clearest signals that an old design may be becoming expensive.
Technical debt becomes especially expensive in parts of a system that the team changes often. Martin Fowler's explanation of technical debt makes this distinction useful: not every messy area has the same economic impact. The cost appears when the debt makes future change harder. The messy parts are making the business harder to change are where your engineering attention should go first.
2. Reliability problems are beginning to affect the business.
An outage is not just a technical event. Its impact depends on what the product means to the customer. A small internal tool going down for 20 minutes is one thing. A system handling payments, logistics, healthcare workflows, or business operations can create a very different consequence. As your software product grows, you need confidence around: what can fail, how quickly failure is detected, who is alerted, how service is restored, what data could be lost, what happens when an external service fails, and whether customers can safely retry.
DORA's research also treats software reliability as broader than simple uptime, including areas such as performance and scalability. The goal is knowing how the important parts behave when reality goes wrong.
3. The cost to serve customers is getting worse.
A growing cloud bill is not automatically a problem. If customers grow, usage grows, and revenue grows, more infrastructure spending may be perfectly reasonable. The more useful question is: “Is the cost of serving the business growing for a good reason?” Look at something meaningful for your business. For example: infrastructure cost per active customer, infrastructure cost per transaction, infrastructure cost per order, storage cost per customer, and processing cost per workflow.
Suppose customers increase by 30%, usage rises by 35%, but infrastructure cost rises by 90%. That does not prove the architecture is bad. It tells you to investigate. Perhaps the business is using more valuable workloads. Perhaps data retention has changed. Perhaps the product now needs stronger reliability. Perhaps the infrastructure is inefficient. The point is to understand the reason. Do not optimize a number simply because it looks large.
Not every slow engineering team has an engineering problem.
A founder may see slower delivery and thinks: “Our architecture is bad.” Maybe. But the actual problem could be: unclear priorities, constant changes in scope, too many simultaneous projects, weak product decisions, unclear ownership, slow approvals, excessive meetings, poor planning, and/or unrealistic deadlines. This matters and is an important reality check because engineers can become the visible part of a much larger problem.
Before changing architecture, ask: “Where exactly is the work getting stuck?” You may discover that the system is fine, but the delivery process is the constraint. Or you may discover that the process looks reasonable, but the system makes every important change difficult. The same symptom can have very different causes. That is why this is a diagnosis problem.
Technical debt is not automatically a problem.
The term “technical debt” can create a negative reaction. Founders sometimes hear it and think: “We need to clean everything up.” That is usually a mistake. Think of a shortcut like borrowing money. You may take the shortcut because it gives you something useful today, like getting the product into customers' hands faster. That can be a good trade. But the shortcut can create future work.
Almost every real software system has some. The useful questions are:
How often do we touch that feature?
What does that feature cost us?
What risk does adding a new feature or updating an existing feature create?
Is the cost increasing with feature releases?
You do not repay every debt immediately. You only deal with the debt that is becoming expensive.
Four tests to tell whether shortcuts have become expensive.
1. Frequency
- How often does the problem happen? Once every two years is different from every week.
2. Impact
- What does it affect? Does it cost revenue, customers, engineering time, delivery speed, support time, infrastructure spend, and/or trust?
3. Growth pressure
- Is the business actually approaching a point where the problem will get worse? Design for real growth, not imaginary scale.
4. Cost of delay
- What happens if you leave the problem alone for another year? A problem that costs very little today may become extremely expensive if the business is about to double.
Measure before you change the architecture.
When someone says: “We need to rewrite this.” That is a proposal, not a diagnosis. Ask for evidence. For example: How long do important changes currently take to reach customers? How often do releases fail? How long does recovery take? Which parts of the product create the most incidents? Which parts take the most time to change? Which workflows depend on one person? Which infrastructure costs are growing fastest? Which customer-facing failures are increasing? These questions turn a vague technical discussion into something the business can evaluate.
Knowing something about delivery performance is not the same as knowing whether your product strategy, architecture, business model, or priorities are correct. That distinction is important. Metrics are evidence.
Your most important workflows deserve the most attention.
You do not need to review every part of your software equally. Start with the three workflows that matter most to the business.
For one company that might be: Sign up → create account → start using product.
For another: Order → payment → fulfillment.
For another: Patient → appointment → payment → records.
Then map what happens. For example: Customer → Web App → Application → Database → Payment Provider.
Then ask where it can fail, what happens if the database is slow, what happens if the payment provider is unavailable, what happens if the customer clicks twice, how to detect the failure, if the customer and the team can recover, who knows how to fix it and/or how much revenue depends on this workflow.
That is architecture translated into business language.
Your architecture does not need to become complicated.
It’s a trap when a startup discovers its system is becoming harder to change because someone often says: “We need microservices”; or “We need Kubernetes”; or “We need event-driven architecture.” Maybe, but none of those is automatically a sign of maturity.
Complexity has a cost. More services mean more things to understand. More infrastructure means more things to operate. More moving parts mean more failure paths. More distributed systems can make debugging harder.
A simple application can sometimes serve a growing company very well. A modular application can provide useful separation without forcing the team to operate a large distributed system. A managed database may still be the right database. The objective is to remove the constraint that is hurting the business, not to build the most sophisticated system you can. That is a very different goal.
What you should fix first.
Begin with the things that matter to the business. A useful order is:
- Unacceptable risk. Protect important customer data, revenue-critical workflows, and the ability to recover from serious failures.
- Major business constraints. Fix the parts of the system that are clearly slowing delivery, reliability, customer experience, or growth.
- Repeated engineering friction. Improve areas that the team touches often and that repeatedly waste time.
- Cosmetic technical improvements. Leave them until they have a clear reason to matter. Your engineering team may know that a certain component is ugly. That does not mean it is the company's most important problem.
What you should not change.
Do not rewrite a stable part of the system because it is old, introduce microservices simply because the company has grown, optimize for traffic you do not have, replace working technology because something newer is popular, spend six months improving an internal system while a customer-facing bottleneck remains untouched, and do not let the phrase “technical debt” become an automatic reason to spend money.
Always ask what business outcome the change will improve. That one question can prevent a lot of expensive engineering work.
When a rewrite makes sense.
A rewrite can be the correct decision, though a strong case for a rewrite usually has several things behind it.
- The current system has a serious constraint that affects something important to the business.
- Incremental improvements are no longer enough.
- The team can explain what the new system needs to do differently.
- The business can afford the transition, and
- There is a clear way to measure whether the investment worked.
For example, the goal might be to reduce release lead time, reduce failures, improve recovery, reduce cost per transaction, and make an important workflow safe to change. That is a much stronger case than simply “The codebase or architecture is old.”
The better alternative to “rewrite or do nothing”.
Most engineering work does not need to be one giant decision. You can evolve the system step by step. For example:
- First: improve visibility, and make failures easier to see.
- Then: improve deployment safety, and reduce the chance that a normal release causes an incident.
- Then: fix the highest-cost database query.
- Then: separate one tightly coupled business area.
- Then: replace one unreliable dependency.
- Only then: consider larger architectural changes where the evidence supports them.
This is a healthier approach because every step should reduce a real problem. Grow the architecture in response to proven constraints, not building every possible future requirement today.
The cost of ignoring the problem is usually hidden.
Engineering problems show up in pieces like a feature takes three extra days, a release gets delayed, a developer spends days investigating an issue, a customer waits longer for a fix, an incident interrupts planned work, and/or infrastructure spending rises.
Each event seems manageable, but together they can become a serious business constraint. Here is a simple example, suppose an important feature used to take three days, now it takes eight. That is five extra engineering days. Do that ten times in a quarter, you have spent roughly 50 extra engineering days on the friction alone. And that does not include incidents, support work, delayed opportunities, or the cost of the extra coordination. The exact numbers will differ from company to company.
The principle is what matters: Engineering friction has an economic cost even when it does not appear as a separate expense.
The goal is not to punish your MVP.
Your MVP gave you something extremely valuable. EVIDENCE. It helps you learn what customers wanted, discover what they did not want, find important workflows, generate revenue, and give you a real system in the real world. That is a success. The mistake is failing to notice when those shortcuts stop being cheap.
Engineering decisions may be sensible for the business you had, but are now becoming expensive for the business you have
Your next stage requires something different.
“Our old architecture is no longer sufficient for the business we are becoming” is often much closer to reality because a system does not need to be perfect. It needs to be fit for the current business. That means your architecture should evolve when the evidence says the business now needs something different because the current system is creating a real constraint or unacceptable risk.
Your software product needs to be ready for the business you are becoming.
An MVP can be simple, contain shortcuts, have technical debt, and even be imperfect. None of that automatically means you built it wrong. Growth is what changes the pressure on the system when more customers depend on it, more people work on it, more data moves through it, more workflows depends on it, and/or more revenue depend on it.
Eventually, the shortcuts that once helped the company move faster can start slowing it down. That is the moment to pay attention because the business changed enough that some old engineering assumptions no longer fit.
The goal is to find the constraints that matter, understand their business impact, and fix the right things in the right order.
It’s not whether your MVP is technically good enough. It’s whether your engineering is still good enough for the business you are becoming.
Share this article
Send it to someone who would find it useful.