And the reality is that very few get there: over 70% of public sector artificial intelligence (AI) projects never make it past the pilot stage, according to a study of 4,372 initiatives published by the tech consulting firm Nortal.

It’s not that the technology doesn’t work. More often than not, the issue is that integration and operations were never planned from the start. Energy gets focused on the solution—how to solve a single use case—rather than thinking about API reusability, interoperability, or actual operating costs.

The team is focused on the product, but nobody is leading integration from Day Zero.

At Gobe, we’ve seen how important it is to think about "Week 53" before the first meeting even happens. To avoid getting stuck in the pilot phase, here are a few key takeaways to keep in mind from minute one.

1. Moving from the "Wow" Factor to Operational Trust

A product needs to excite. It has to show clearly how it solves a use case, how it makes civil servants' lives easier, how it improves life for citizens, and how it allows public money to be spent where it has the greatest impact.

However, the "wow" factor isn't enough.

Whoever buys the solution needs to understand the operational details: how it functions, what it costs, and how it integrates into existing systems. The problem, generally, is that the person interested in the product—usually the department looking to solve the immediate use case—doesn't have all the information. What's more, many aspects and decisions regarding costs and integration are the responsibility of other people in other departments (such as Finance or IT).

All too often, these areas are only brought into the conversation at the very end, once the pilot is proven and discussions turn to scaling. And that's where the problems start. On the startup side, the conversation shouldn't just be handled by the CEO or salesperson either.

There are details that need to be ironed out CTO-to-CTO.

Fostering these conversations early builds operational trust and reduces the classic "yes, but..." that holds back scaling.

2. The CTO’s Notebook: A Checklist of Key Questions

It’s common for startups to wait for the client to ask about integration. But to really sell at scale and avoid getting stuck in the pilot phase, we need to lead the conversation on integration. The risk of not doing so is that, after all the development effort and a successful pilot—with everyone high-fiving over how good the solution is—you run headfirst into a hard "NO" on scaling that slams the door in your face.

How can we avoid this? By asking questions that might break the magic of a good demo meeting just a little, but are crucial for ensuring long-term success.

Here are seven questions that, in our experience, are key:

1. What are the critical systems to integrate with (ERP, GIS, CRM) and who manages them?
2. What data formats and data dictionaries (JSON/GeoJSON/CSV) will we need to scale?
3. What minimum documented API is available?
4. What licenses are required? Do any create critical dependencies?
5. What are the interoperability requirements for information exchange and retention (technical, semantic, and organizational)?
6. Does our product meet the required accessibility standards?
7. What security requirements do they expect from us?

This checklist can be helpful for that first or second technical meeting, but there is undoubtedly one piece of information even more important than all of them: who is accountable?

Finding out who owns each part of the system is key. Not only to clarify who will make the final decision, but also to establish from the start who will be responsible for managing the relationship during integration. And, by the way, this also means deciding who will take charge of this on the startup's side.

These are the people who will be in charge of preparing a runbook (startup, monitoring, backup/restore, key rotation, incident escalation) and a handover/training plan for the client's team. It is also important to agree, as needed, on a ticketing system and response times.

3. Nothing Is Free: Bringing Budget Owners to the Table

Many digital solutions, especially AI tools, are usually charged by subscription or usage (users, tokens, API calls, storage, inferences). This can cause costs to skyrocket when scaling, especially if metrics aren't properly anchored during the pilot.

It’s key to have the technical leads at the table, but also the people who manage the pursestrings. In the end, that department will decide whether the cost of the product at scale fits the budget.

Again, here are a few practical tips to make sure there are no surprises ruining the celebration when the decision is made to scale:

• Define the billing unit (user, call, token, GB, etc.) and run scenarios.

• Establish alerts and caps (technical and contractual) by environment/area.
• Break down total operating costs: infrastructure (cloud), licensing (OSS/BYOL/proprietary), observability, support, and business continuity.
• Document scaling curves (what happens if usage goes x10?) and quality trade-offs (for example, latency vs. cost).
• Present value and cost together. It’s not just about showing expenses, but also the value generated by that total spend.

Talking about costs too early can feel a bit "anticlimactic," but the risk of avoiding it is getting stuck in the pilot phase forever. It’s better to have difficult conversations at the beginning than to avoid them and run into a brick wall later. Plus, putting these issues on the table from day one helps build trust.

Integration Isn't Delegated, it's Led

For a startup looking to sell to the public sector, the goal isn't winning the demo and running a pilot: the goal is operating in Week 53.

In an ecosystem moving toward GovTech 3.0, where startup innovation truly integrates into public institutions and coexists with major integrators, the competitive advantage is the ability to integrate and operate.

Delegating integration means risking staying stuck in the pilot. If the startup leads the conversation from day zero, it will surely be there to celebrate Week 53.
‍

‍

* Invited firm: Fernando Fernandez-Monge, Senior Associate at the Bloomberg-Harvard City Leadership Initiative at Harvard University and researcher at the Institute for Innovation and Public Purpose at University College London. An earlier version of this article appeared in the DataPolis Newsletter.