We see it everywhere: in research labs, in development programs, and in businesses. A pilot dazzles. It has external funding, imported expertise, and the undivided attention of leaders. It succeeds.
And then it dies.
Or worse, it survives as a zombie—consuming resources but adding no real value.
Scaling pilots is one of the hardest challenges in systems change. Here’s why they fail, and how we can design them differently.
Why pilots fail to scale
1. Scarce attention. Pilots benefit from executive focus that can’t be replicated at scale.
2. Imported expertise. Solutions often rely on external consultants who leave, taking know-how with them.
3. Fragile funding. Pilots are financed like special projects; scale needs recurring budgets.
4. Context variance. Solutions overfit to one site; moving them elsewhere requires costly redesign.
5. Static systems. If the solution can’t evolve with user needs, trust erodes.
6. No institutional home. Without ownership, budget lines, and job descriptions, the pilot remains an orphan.
As my friends Gautham and Ameya observe in their paper “Distributing the Capacity to Solve: Digital Public Goods for Iterative Adaptation in Governance and Service Delivery”, many solutions also collapse under premature load‑bearing—they demand too much administrative effort from already fragile local systems, and instead of strengthening state capacity, they erode it.
Change the objective: from solution to durable systems
Most pilots are designed to prove a technical solution. At scale, what matters is proving sustained service:
• Can the local system run and adapt it without outside funding?
• Can it be replicated in different contexts?
• Has it been institutionalised—policies, governance, budget, roles—in a way that makes it irreversible?
• Are local experts in the driver’s seat, with external experts only supporting?
If not, we shouldn’t call it scale-ready.
Principles for scale-ready pilots
Start with a scaling hypothesis. Be explicit about what must be true (unit costs, staffing ratios, minimum system capacity) for scale to work. Have these assumptions been validated in practice?
Pilot at a minimum viable scale. Don’t limit testing to one pristine site; run in enough contrasting contexts to truly represent the diversity you expect at scale. Has it worked in more than one context?
Unbundle common vs. contextual. Standardise what can be reused; adapt what must be local. Is there clarity on what is reusable, and what must remain contextual?
Build maintainers, not just users. Invest in administrators, support desks, and local developers—not just end-user training. Can at least two local maintainers or vendors run it?
Make funding boring. Prove the unit economics and tie them to predictable budget lines. Is there a permanent owner and a recurring budget line?
Embed governance and policy. Bake in standards, procurement rules, and accountability during the pilot. Are policies, SLAs, and job roles in place?
Center frontline stakeholders. Citizens and workers drive adoption—design with them, not for them. Are there effective feedback loops for frontline users and citizens?
Test for survival. A pilot has scaled only if it can survive leadership rotations, vendor handovers, and normal levels of attention. Can it survive leadership and vendor turnover? Are monitoring tools, playbooks, and a release cadence live?
From pilots to ecosystems
Scaling isn’t copy-paste. It’s about distributing the ability to solve across governments, markets, academia, and citizens. That means:
Open participation rules (APIs, data standards, procurement transparency).
Clear ecosystem roles (who builds, who certifies, who supports).
Feedback loops for users and citizens.
Incentives tied to uptime, adoption, and continuous improvement—not just launch.
The bottom line
We shouldn’t stop piloting. We should change what a pilot is for.
Pilots must prove sustenance, replication, and institutionalisation—with local experts leading and external experts enabling.
That’s how we stop building fragile demos and start building durable systems that last.
Highly recommend a read of Think-Scale by the Societal Thinking Team and Sanjay Purohit (PDF, 2024). I’ll leave you with its opening lines:
Scale is not a synonym of growth.
What works, may not work at scale.
Scale is a journey of mindset shifts.
Scale emerges. It can’t be imposed.
Scale design is not an afterthought.
Complexity lingers, simplicity scales.
Agency fuels scale, and vice versa.
Diversity makes scale more relevant.
Set solutions grow, shared ideas scale.
Together we scale, divided we stall.