The minimum viable product is one of the most influential ideas in modern technology. The logic is compelling: rather than spending years building a complete system before getting feedback, build the smallest thing that tests your hypothesis, release it, learn from real users, and iterate. Fail fast. Fail cheap. Find product-market fit before you run out of money.
This is good advice for a consumer application. For a farmer in Karnataka who is depending on your crop disease diagnosis to decide whether to spend ₹4,000 on a fungicide treatment, it is the wrong frame entirely.
What MVP Logic Assumes
The minimum viable product framework rests on several assumptions that are true in consumer software and false in the domains Truffaire operates in.
The first assumption is that failure is cheap. In consumer software, this is largely true. If a social media app has a bug that causes it to crash, the user is annoyed. They switch to a competitor. The company loses a user. These are recoverable situations.
In agricultural diagnostics, failure is not cheap. An incorrect disease diagnosis leads to incorrect treatment. The farmer spends money on the wrong product, the disease progresses while the treatment does nothing, and by the time the correct diagnosis is made, the intervention window has closed. The cost of that failure is not a lost user — it is a damaged crop and the debt that comes with it.
In defence and law enforcement, an MVP in forensic imaging equipment might produce evidence that is subsequently challenged in court because the equipment's accuracy was not sufficiently established. Cases built on inadequately validated forensic tools fail. The cost of that failure is not a lost user — it is a failed prosecution.
In healthcare, the consequences are self-evident.
The second assumption is that users can meaningfully evaluate an MVP and give you useful feedback. This assumes a level of domain expertise and evaluation capacity that exists in some user populations and not in others. A startup's early adopters in the consumer technology space are typically technically sophisticated, understand that they are using an early product, and provide feedback that reflects their genuine experience.
A farmer in a rural district who is using a crop disease diagnosis tool for the first time is not in a position to evaluate whether the diagnosis they received is accurate. They lack the specialist knowledge to assess accuracy. They will act on the diagnosis. If the diagnosis is wrong, they will not immediately know it — they will know it weeks later, when the treatment fails and the crop is already severely affected.
The feedback loop that MVP logic depends on is broken in contexts where users cannot evaluate the quality of the output they receive.
The third assumption is that the cost of learning is borne by the company, not the user. In consumer software, a bad user experience costs the company a user. In the domains we work in, a bad system experience costs the user something they cannot recover — a crop, a case, a patient outcome.
What We Build Instead
We build what we call minimum sufficient systems — systems that meet the full performance requirements for the context they are deployed in before they are deployed.
Minimum sufficient is a different standard from minimum viable. Minimum viable asks: what is the smallest thing we can build that tests our hypothesis? Minimum sufficient asks: what is the smallest thing we can build that is genuinely adequate for the use case?
For ARCORA, minimum sufficient meant building a diagnostic model validated against expert agronomist assessments before deploying to farmers. It meant testing across the full range of crops and disease presentations that Karnataka farmers encounter, not just the most common ones. It meant building a treatment protocol layer that is medically accurate before giving farmers the capacity to act on it.
This takes longer than building an MVP. It costs more upfront. It produces a first release that is later and smaller than an MVP approach would produce.
What it does not produce is a version of the system that a farmer relies on, receives incorrect advice from, and suffers a crop loss because of. That outcome is not recoverable with a patch or an update. The trust once lost in this kind of context does not return.
The Right Kind of Speed
The argument against MVP thinking in critical domains is sometimes read as an argument for slowness. It is not.
Speed matters enormously. A farmer's crop disease is progressing right now. A crime scene's integrity is degrading right now. A medical student's clinical training is happening right now, in whatever form it is happening in.
The right kind of speed in these contexts is the speed of getting something that works into deployment, not the speed of getting something to market before it is ready. These are different things. They require different approaches to development, to testing, and to the definition of "done."
A system is done when it is ready to use, not when it is ready to test. The testing happens internally, under conditions that replicate real deployment without the real-world consequences of failure. The deployment happens after the system has demonstrated that it is adequate for the purpose.
This is how we build. It is slower in the early stages. It is faster in the long run, because we do not spend time managing the consequences of deploying systems that were not ready.
And it is the only approach that respects the people who depend on what we build.