What Rigorous Research Actually Looks Like in Emerging Market Tech

A case against move-fast-and-break-things.

“Move fast and break things” was never really a philosophy of technology. It was a philosophy of risk allocation. It worked, to the extent it worked, in a specific context: a consumer social app, built for users in wealthy markets with alternatives available, where the cost of a broken feature was a bad afternoon and a quick patch. The mantra survived because the things that broke were mostly recoverable, and the people who bore the cost of breakage were largely the same people who chose to use the product in the first place.

That context does not describe most of what gets built in emerging market technology, and it especially does not describe technology built for governments, public institutions, and the communities that depend on them. When the thing that breaks is a land registry, a procurement system, a health record, or a revenue platform a local government relies on to pay teachers, the person who bears the cost of breakage is rarely the person who decided to move fast. This is the case for a different discipline entirely: not necessarily a slower one, but a more rigorous one, built around research rather than iteration for its own sake.

Why the Silicon Valley playbook doesn't transfer cleanly

It's worth being fair to the original logic before rejecting it. Rapid iteration, shipping imperfect versions early, and learning from real usage rather than endless planning are genuinely good ideas in the right setting. The mistake isn't the instinct to learn by doing. It's applying that instinct without adjusting for who absorbs the cost when the early, imperfect version fails.

In a consumer app market, the feedback loop is fast, the exit option is easy, and the failure is reversible. If a food delivery app has a bug, the user orders from a different app the next day and the company loses a transaction, not the user's trust in an entire category of technology. If a growth-stage fintech ships something broken, a well-resourced startup ecosystem exists to absorb the failure, iterate, and try again next quarter.

None of these conditions reliably hold where much of the highest-impact emerging market technology actually gets deployed. A local government adopting a new revenue system usually has no fallback running in parallel, no easy switch to a competitor, and often only one real shot at convincing skeptical staff and citizens that digitizing was worth the disruption. A rural health worker relying on a diagnostic tool can't treat a false negative as a learning for the next sprint. A small business owner who loses financial records to a poorly tested platform doesn't get that data back with an apology email and a service credit.

The exit option that makes rapid iteration safe in wealthy consumer markets, the ability to walk away cheaply and try something else, is exactly what's missing in the contexts where a lot of emerging market technology gets built. That absence is the entire argument for a different discipline.

The real cost of breaking things in public systems

It's easy to talk about this abstractly. It's more useful to be specific about what actually breaks, and what breaking it costs, when move-fast logic gets applied to institutional technology in under-resourced environments.

Trust breaks first, and it rebuilds slowest. A government that adopts a poorly tested system and watches it fail publicly doesn't just lose the investment in that one project. It becomes measurably more cautious about the next reform, the next vendor, the next attempt at digitization, even a well-designed one. Public-sector transformation runs on a finite, hard-won reserve of willingness to try something new. Spending that reserve on a system that wasn't ready is a cost that shows up years later, in a different project, with a different vendor who did nothing wrong and still inherits the skepticism.

Data breaks in ways that are often irreversible. In a well-resourced environment, a pipeline error is usually recoverable, because backups, redundancy, and mature monitoring exist. In lower-resource environments, a single instance of corrupted or lost records, land titles, tax histories, health records, can be damage with no clean recovery path, because the paper records the system replaced have often already been discarded.

People break, quietly, and stop being counted as a cost. When a system is rushed out without testing against real workflows, the burden of making it work falls on frontline staff, the clerk, the nurse, the council officer, who work around its failures with no formal acknowledgment that the system is the problem. This cost rarely appears in a project report. It shows up as burnout, quiet noncompliance, and an eventual, unremarked return to the old process, long after the tech team has moved on.

None of this means failure is avoidable, or that every risk can be engineered away in advance. It means the cost of a given failure has to be part of the design conversation from the start, not treated as an acceptable side effect of speed.

What research-first development actually involves

Rejecting move-fast-and-break-things doesn't mean moving slowly for its own sake, and it doesn't mean endless study without ever shipping, a failure mode that's just as real and just as damaging as reckless speed. It means being deliberate about which parts of a project can safely be iterated on quickly, and which parts need genuine rigor before anything goes live.

Front-load the research where the cost of being wrong is high, and iterate freely where it isn't. Interface design, workflow sequencing, and visual layout can be tested and adjusted quickly with real users, because getting them wrong is annoying, not catastrophic. Data architecture, security, and the core logic of anything touching financial records, legal status, or health information deserve a different pace entirely, because getting them wrong the first time can be close to unfixable. Treating every part of a system as equally safe to iterate on is its own kind of carelessness.

Validate assumptions with the people who will depend on the system, not just the people who commissioned it. A ministry official signing off on a project and a frontline clerk who will use it every day often have very different understandings of the real problem and what a workable solution looks like. Research that only consults the former will consistently miss the operational realities that decide whether a system survives daily use.

Build in genuine off-ramps, not just rollback plans. A rollback plan that assumes the old system is still intact and staff still remember how to run it is not a real safety net if deployment has already caused people to abandon the old process. Research-first development plans for a managed, gradual transition, running old and new in parallel long enough to be sure, rather than a hard cutover with no way back.

Treat the absence of a visible failure as inconclusive, not as success. In government technology, the most dangerous failures are the silent ones: a report nobody reads, a data field filled with placeholder values because the workflow doesn't support the real input, a workaround quietly replacing the intended process. A rigorous approach actively hunts for these rather than treating “nothing has visibly broken” as proof the system works.

The uncomfortable trade-off, named honestly

There is a real trade-off here, and pretending otherwise would be its own kind of dishonesty. Research-first development is genuinely slower to reach a first deployment than move-fast development. It costs more upfront, in time and in the discipline required to resist shipping something that looks finished before it is. For a founder or research team under pressure to show results quickly, to a funder, an investor, or a government partner with limited patience, that trade-off is a real cost, not a hypothetical one.

The case for accepting that cost isn't that speed doesn't matter. It's that in the environments where the highest-stakes emerging market technology gets deployed, the asymmetry between the cost of being slow and the cost of being wrong runs in the opposite direction from where Silicon Valley culture assumes. A consumer app that ships six weeks late loses some early-adopter enthusiasm. A land registry that ships on time but corrupts a village's property records doesn't get a second chance to build trust in that community, possibly for a generation.

What this looks like in practice

None of this argues for never shipping or treating every project as years of study before anything goes live. The discipline is about sequencing and proportionality, not paralysis. In practice it means doing the hard, slow work upfront on the parts where errors are expensive and hard to reverse, data architecture, security, the core logic touching people's legal, financial, or medical status, while moving quickly on the parts where errors are cheap to fix, like interface details and workflow sequencing.

It means piloting deliberately with the frontline staff and communities who depend on the system daily, not just the officials who commissioned it, and treating their feedback as primary data rather than a formality. It means building genuine, tested transition paths, not just documented rollback plans that assume conditions nobody has verified. And it means actively hunting for silent failure, the unused report, the placeholder data, the quiet workaround, rather than reading an absence of complaints as proof of success.

The bottom line

“Move fast and break things” was a reasonable strategy for a specific kind of technology, built for a specific kind of user, under a specific kind of risk. Most of what gets built for governments, institutions, and communities in emerging markets meets none of those conditions. The people who bear the cost of a broken system here are rarely the people who decided how fast to move, and the failures are rarely as recoverable as the mantra assumes.

The alternative isn't slowness for its own sake. It's rigor applied where rigor is load-bearing, and speed preserved everywhere it's genuinely safe. That is how Fomil Labs approaches research and system-building: not because caution is a virtue in itself, but because in the environments we build for, being right the first time is very often the only time we get.