Minimal in features, scalable in architecture

Three meanings of minimum

In his distinction between MVP and MMP, Roman Pichler separates two purposes: learning with an early version and having a sufficient offering to enter the market. That difference helps explain why a useful experiment can still be far from a product ready to operate. Here I use MVP, Minimum Viable Product, in that learning sense: its scope depends on the question we need to test.

Roman Pichler — On MVP and MMP

To those two questions I add a third: what conditions does the product need to sustain growth in users, data and operations? I use MSP, Minimum Scalable Product, to discuss that capacity. Three meanings of minimum emerge: what enables learning, what provides a complete commercial experience and what prepares the system to evolve. The labels help separate problems, but do not establish a compulsory sequence. A product can be sold while still relying on processes it will not be able to repeat at the same pace.

The MVP-E proposal

The proposal is to read MSP in two ways: as a capacity that must eventually be demonstrated through use and testing, and as a criterion that can inform design before that point. Organising data and deciding how a user is added are early decisions, even when their consequences become visible later. Waiting for growth before considering them can turn a favourable validation into a reconstruction problem.

I call an MVP that keeps its features limited while protecting those initial conditions MVP-E, the Scalable Minimum Viable Product. The framework brings together user learning, architecture that can evolve, repeatable operations and early measurement. Its design criterion examines each saving in terms of what would have to be rebuilt if the experiment continued. A manual task can remain while it supports learning; a dependency that prevents data from being interpreted or transferred deserves attention before records accumulate. The question is how decisions keep the next product experiment possible, rather than how much development we can add.

This matters when the first version is expected to become the product’s foundation. A disposable or manual prototype can still be the right experiment: forms and spreadsheets may answer a demand question quickly. The problem arises when that solution becomes permanent infrastructure without revisiting its conditions. MVP-E calls for preparation proportionate to the initial growth worth investigating. Building for an imagined scale from the outset would also consume resources and could delay the learning that justifies the project.

Choose which decisions can wait

Technical debt helps name part of that trade-off, provided we do not treat every shortcut as the same mistake. Martin Fowler distinguishes prudent from reckless debt, and deliberate decisions from inadvertent debt. A team may consciously accept a future cost; it may also discover one as it comes to understand the product better. The question is what we know about that cost and how we will revisit the decision that produced it.

Martin Fowler — Technical Debt Quadrant

In our conceptual platform, a report can be prepared manually while the team discovers what information businesses need. That work may even reveal what should later be automated. If applications are stored without a clear relationship to the relevant business and vacancy, however, every change may require reconstructing information that should already be organised. To choose between those savings, I would ask what we need to retain, how we would recover its meaning and what would have to be rebuilt when adding another account. Manual reporting leaves a visible task that can be replaced; ambiguity in the data compromises the material needed for later learning and operation.

Conceptual example

The same recruitment platform, three ways to build it

Return to the same problem: small and medium-sized businesses need to publish vacancies, receive applications, organise candidates and produce basic reports. We can keep that scope and build three different configurations. The comparison lets us examine how much work it takes to add another business and what would need to change to serve it. That question makes concrete a discussion that might otherwise remain a preference for one architecture over another.

The third configuration requires initial work that the first avoids. To choose, we first specify the hypothesis to be tested and what would be retained if it were supported. We then examine whether another business could follow the same process and where a new dependency emerges. If the whole experiment will be discarded, setting up each case manually may be reasonable. If applications will carry into the next version, their relationships need a recoverable structure, even if reports remain manual. The point for revisiting the decision arises when the next learning step requires reconstructing data or processes already in use. That criterion informs a design discussion; its cost needs to be estimated for the particular product.

Readiness is not proof

The proposed MVP–MSP readiness matrix examines that decision across architecture, data, users and permissions, infrastructure, operations, observability, security, performance, support and maintainability. Its criteria and thresholds need empirical validation. Its conceptual value lies in separating questions that a general assessment such as “the product works” may conceal: operations can be repeatable while behaviour under load remains unknown.

The manuscript distinguishes four states for each dimension. Fragile describes a dependency without minimum preparation; basic, an initial but limited solution; prepared, conditions for evolution; and validated, a capacity examined through use or testing. The difference between the last two is essential: having a reasonable structure supports an expectation, while testing it allows an observed capacity to be discussed. A design intention does not take the place of that evidence.

The data row illustrates the progression. It begins with scattered or manually handled information, moves through a simple database with possible inconsistencies and reaches an organised, extensible model. The validated state adds auditable data and verified integrity. In the recruitment platform, organising businesses, vacancies and applications is a preparation decision. Checking that those relationships hold as information is created and changed is further work that the structure alone does not settle.

The operations row describes the progression from handling each case manually to documenting and partly automating the process, then establishing that it can be repeated with little additional effort. The rows need to be read together. A platform may have well-related data while still requiring a person to configure every business. In that situation, the data structure helps retain the work, while onboarding remains an unfinished task. The diagnosis helps decide whether that intervention contributes to learning or whether repeating it now displaces other work the team needs to do. The matrix preserves distinctions that a general maturity label would conceal.

Testing the framework would require following real products and comparing their initial decisions with later rework and operational demands. Onboarding time, manual steps, errors and recovery from failure would help describe that evolution. Differences between products would also matter: an improvement attributed to design might depend on volume, the team or a change in scope. Such an investigation would allow the matrix to be revised, rather than assuming its categories already explain the outcome.

I argue for a limited first release that supports learning while keeping the work to be retained intelligible. The size of the interface says little about that commitment. Report automation can wait; the relationship between an application and its vacancy deserves care if the next version will depend on it. MVP-E proposes making that choice explicit and revisiting it when the hypothesis, volume or intended future of the product changes. Preparation has value when it protects a particular learning step and the effort it requires can be explained.