"Week 53" Mindset
How to avoid getting stuck in the “pilot phase” of government innovation
[This post was jointly written with my friend Mencey Melgar, CTO of Gobe. The kernel ideas are his, the initial draft was mine, and we jointly iterated them into this piece.]
You’re a startup founder who built a company to solve a public challenge. Maybe is a more accurate ECG reading tool prompted by your family’s health history, or a new way to track air quality in your city because you are worried about your kids’ health and don’t want to move to the suburbs.
Whatever it is, today is a great day. After endless meetings, sleepless nights, and about a thousand iterations, a government partner has just told you that your pilot perfectly solves a crucial pain-point in their administration. It feels like a stamp of validation and a gateway to a long-lasting relationship.
The temptation is to think about “Day 10” (flawless demo, applause, press release). But in the public sector, the real challenge is making it to “Week 53”: when the service is actually in production, integrated with legacy systems, handling real data, real users, and operational responsibilities.
Very few make it there. For example, over 70% of public sector AI pilots never graduate. And it’s not that the innovation doesn’t work. Often the problem is that integration and operations aren’t planned from the start. All the energy is poured into solving a use case, forgetting about API reusability, interoperability, or actual usage costs.
The team is laser-focused on the solution, but nobody’s leading the integration phase.
And yet, whether you’re a startup founder, a public official, or a government CTO, the goal is the same: making sure that public-value innovations reach Week 53 - that moment when your innovation has survived procurement, security reviews, integration with legacy systems, and is quietly serving real citizens every day.
But the best time to think about Week 53 is not week 52, is Day 0.
From the “wow factor” to building operational trust
An innovation needs to inspire. It needs to clearly demonstrate how it solves a use case. How it makes civil servants’ workday easier. How it improves citizens’ lives. How it ensures that public money goes where it has the most impact.
But the “wow factor” isn’t enough.
Governments need to understand the nitty-gritty of how it operates, what it costs, and how it integrates with existing systems. The problem? Usually, the person excited about the innovation, typically the department that needs to solve the use case it addresses, doesn’t have all the information. In fact, many aspects and decisions around costs and integration fall under other departments (Finance, Legal, IT Systems...).
These departments often only join the conversation at the end, after the pilot’s proven and when scaling discussions begin. That’s when problems surface.
If you are on the government side, you can flip this logic: bring your finance, security, and systems teams into the room early, and share your standards and constraints upfront. And from the startup’s side, it can’t just be the CEO or salesperson running the entire conversation. Some aspects need to be hashed out from (technical) expert to expert.
Starting these conversations early builds operational trust and reduces the classic “yes, but...” that kills innovations when it’s time to scale.
The “Day Zero” Notebook
Don’t wait for your government partner to ask integration questions. To truly scale and avoid “pilot limbo,” innovators need to lead the integration conversation. The risk of not doing so?
After all the design and development effort, after a successful pilot with everyone patting themselves on the back for such a brilliant solution, doors suddenly close, with a resounding NO to scaling.
How to avoid this? By asking questions that might break the magic of a meeting where you’re riding high on a demo, but are crucial for long-term success.
Here are 7 questions for the first page of your “Day Zero” notebook:
What are the critical systems to integrate (ERP, GIS, CRM) and who manages them?
What are the data formats and dictionaries (JSON/GeoJSON/CSV) we’ll need for scaling?
What’s the minimum documented API available?
What licenses are required (cloud, databases, third-party APIs)? Do any of them create critical vendor dependencies?
What are the interoperability requirements for information exchange and preservation (technical, semantic, and organizational)?
Does our innovation meet the required accessibility standards?
What security, compliance, and data protection requirements apply (e.g., certifications, audits, data residency)?
This checklist can be useful for that first or second technical meeting, but there’s one piece of information even more crucial than all of these: Who’s responsible?
Finding out who within the government is responsible for what is key. Not just to clarify who’ll make the final decision, but also to establish - from the beginning - who will manage the relationship during integration.
The price of not talking about costs
Many innovations, especially AI-powered ones, typically charge by subscription or usage (users, tokens, API calls, storage, inferences...). This can cause costs to skyrocket when moving to scale, especially if you don’t anchor metrics properly from the pilot phase.
Here it’s crucial to have technical managers at the table, but also those who control the purse strings. Ultimately, that department will decide whether the product cost - at scale - fits the budget or not.
Again, here are some practical tips to ensure there are no surprises that ruin the celebration when it’s time to scale:
Define the billing unit (user, call, token, etc.) and simulate scenarios.
Set up alerts and caps, technical and contractual.
Break down total operating costs: infrastructure (cloud), licenses (OSS/BYOL/proprietary), observability, support, and continuity.
Document scaling curves (what happens if usage increases tenfold) and quality trade-offs (e.g., latency vs. cost).
Present value and cost together. It’s not just about showing costs, but also the value generated by the total spend.
Talking about costs early can feel like a buzzkill, but the risk of not doing it is being stuck in the pilot phase forever. Better to have tough conversations upfront than avoid them only to crash into reality later. Plus, putting these issues on the table from the start helps build necessary trust.
Integration isn’t delegated, it’s led
If you’re a startup innovating with the public sector, you’re not playing to win the demo in Week 10: you’re here to be operational in Week 53. In an ecosystem moving toward Govtech 3.0, where startup innovation truly integrates into the core of institutions and coexists with major integrators, your competitive advantage is your ability to operate. If you delegate integration, you risk getting stuck in “pilot-land.” If you lead the conversation from the start, you’ll probably still be there to celebrate Week 53.