MVP or State of the Art? When Is “Good Enough” Good Enough?

 

When starting a new product, there is always a difficult question: how much should you build from the start?

On one side, there is the MVP philosophy. Build only what you need, get it in front of customers, learn from their feedback and improve from there. Don’t spend months solving scalability problems for a product that might never have a scalability problem. Don’t automate processes before you even know whether those processes are the right ones. And don’t build a perfect architecture around requirements that will probably change anyway.

On the other side, there is an equally convincing argument. If you already know something will eventually need to be automated, why build it manually first? If you know you will need APIs, scalability, proper monitoring and high availability, why postpone them? Doing the work twice is rarely cheaper than doing it properly once. Even worse, changing something later can become very difficult once customers are using it and depend on the choices you made at the beginning.

This dilemma becomes particularly visible when we talk about Straight-Through Processing, or STP. In many financial applications, STP is almost considered a given. Users expect transactions or requests to move through a system automatically, without somebody somewhere manually intervening. But does that mean that every step really needs to be automated from day one?

Not necessarily. The experience presented to the customer and the process behind it don’t always have to be the same thing. If a request is accepted immediately and the user receives clear asynchronous feedback about its progress, quite a lot can still happen manually behind the scenes. From the user’s perspective, the process can already feel complete and professional, even if someone in the back office still needs to perform several steps manually.

That can actually be an advantage in the early stages of a product. Manual processing gives you an opportunity to learn. You see the exceptions, the strange cases nobody thought about during the design sessions and the situations where the supposedly simple business rules turn out to be much more complicated. After processing a few hundred real cases, you may discover that the workflow you originally planned to automate isn’t the workflow you need at all.

Automating too early therefore has a hidden cost. You risk becoming very efficient at doing the wrong thing.

There is also the simple reality of building new products: requirements change. What looked essential six months ago can suddenly become irrelevant. Features are added, removed or completely redesigned. Customer feedback changes priorities. Regulations or market conditions can introduce requirements nobody anticipated. Code that seemed beautifully designed at launch can become legacy code surprisingly quickly.

Add limited time, money and people to the equation, and shortcuts are almost unavoidable. The real question is therefore not whether you should take shortcuts. Most teams will. The more interesting question is which shortcuts you can afford to take.

A useful distinction is between reversible and irreversible shortcuts. Keeping an operational step manual for six months is usually reversible. Once the volume becomes large enough, you automate it. The customer may never even notice the change. Choosing the wrong data model is different. So is publishing an API contract that dozens of customers integrate with, or making an architectural decision that later requires every existing customer to migrate.

Those decisions become increasingly expensive to reverse as the product grows. What was a small technical shortcut with five customers can become a major migration programme with five hundred.

This is where the idea of a minimum viable architecture becomes useful. An MVP doesn’t have to mean building something that you expect to throw away. You can deliberately avoid sophisticated automation and infrastructure while still creating clean boundaries, sensible data ownership, stable interfaces and proper APIs. Security and auditability can be part of the foundation without every operational process being automated. In other words, you don’t have to build the house today, but it helps to put the right foundations from the start.

There is an interesting parallel with some of the engineering principles historically associated with Amazon. Services were expected to be designed with scale in mind and to expose functionality through APIs. Such principles inevitably put additional requirements on new developments. A small experimental product suddenly needs to think about questions that may have little relevance to its first ten users.

That can feel like a tax on innovation. Every additional architectural requirement costs time and money before you know whether the idea will succeed. Taken too far, a company can become very good at building technically excellent products that arrive too late or that nobody actually needs.

But there is another side to those principles. They force teams to think beyond today’s implementation. A service doesn’t necessarily have to run at Amazon scale from day one, but its architecture should not make scale impossible. There is an important difference between scalability and scalability readiness.

You probably don’t need infrastructure capable of supporting one million customers when you have ten. But it is worth understanding what happens when ten become a hundred, a thousand or a hundred thousand. If every step requires a complete redesign, the cheap MVP may eventually become surprisingly expensive.

The expected speed of success matters here as well. An experimental product entering an unknown market can reasonably optimize heavily for learning. A new capability launched to an existing customer base is different. If hundreds of customers could start using it within weeks, postponing every scalability and availability concern until "later" is much harder to justify. The architecture doesn’t only need to reflect today’s volume. It should also reflect the plausible speed at which today’s volume can change.

The same reasoning applies to automation. "If it can be automated, automate it" sounds attractive, but automation is an investment like any other. There is a development cost, but also a maintenance cost. The automated process needs monitoring, testing and support when something goes wrong.

If a manual task takes ten minutes per week and there is a reasonable chance that the process will disappear three months from now, automating it probably makes little sense. If every new customer adds an hour of manual work every day, the calculation quickly changes. At that point automation isn’t simply an engineering improvement anymore. It becomes necessary for the economics of the product itself.

There is also a risk in going too far in the opposite direction. "We’ll automate it later" is one of those sentences that can survive for an amazingly long time. Products grow, new priorities appear and the temporary manual process remains. Before long, an operational team has been created around something that was originally supposed to exist for a few months. The cost of replacing it has increased, while everybody has become dependent on it.

This is why it helps to be explicit about technical debt. If something is deliberately manual or simplified, define what would trigger the investment to change it. That trigger could be transaction volume, number of customers, operational hours per week, error rates or simply a date when the decision is reviewed again. A shortcut becomes much more dangerous when everybody forgets that it was a shortcut.

Not all non-functional requirements can be treated this way either. Performance can often improve progressively. Extreme scalability can usually wait. Observability can become more sophisticated as a service becomes more important. But security, data integrity, regulatory compliance and auditability can be much harder to add afterwards, especially in financial services. Some requirements are improvements you can grow into; others are part of the definition of an acceptable product.

So perhaps the choice isn’t really between building an MVP and building a state-of-the-art product. That makes the decision sound too binary.

The better question is where you want to spend your engineering effort while uncertainty is still high.

For every major capability or architectural decision, it helps to ask a few simple questions. How certain are we that customers actually need this? What do we learn by keeping it manual for a while? How difficult will this decision be to reverse? Will changing it later require customer migrations? What happens if adoption is ten times faster than expected? Are we creating operational, security or compliance risks by postponing the work?

Some answers will point towards automation and investment from day one. Others will tell you to build the simplest possible solution and wait until you understand the problem better.

And that is probably the balance worth aiming for. Build cheaply where you still need to learn. Build carefully where today’s decisions could limit tomorrow’s choices.