We've built executive-facing analytics for a senior government office, and we're now preparing to bid on public-sector tenders directly. The pattern we keep seeing isn't technical — it's that most government automation projects are designed to fail before a single line of code gets written.
The RFP describes a destination, not a workflow
A typical tender says something like "digitize the citizen complaint process" or "build an AI-powered document management system." That's a goal, not a spec. It tells a vendor what the government wants to be true at the end, but says nothing about who currently touches the process, in what order, with what exceptions. Vendors respond with a slide deck that matches the goal — because that's all the RFP gave them to work with. Nobody has actually mapped the seventeen-step approval chain a single document has to survive.
We treat this as the first deliverable, not an assumption. Before we write a proposal, we ask for (or offer to run) a short workflow-mapping session with the actual people doing the work today — not just the office issuing the tender. It's the difference between automating a process and automating a guess about a process.
Paper-based workflows have undocumented exception paths
Every manual, paper-driven government process has a 'normal path' that covers maybe 80% of cases, and a set of exception paths that exist only in the institutional memory of whoever has been doing the job the longest. A missing signature gets escalated one way. A citizen without a national ID gets handled another way. None of this is written down, because it never had to be — a human was always in the loop to catch it.
Automation that only handles the 80% path doesn't reduce workload — it creates a new manual triage step where staff have to figure out which cases the system silently mishandled. We've seen this exact failure mode before, just in a different domain: when we built AgencyOS for a recruitment operation running on WhatsApp and spreadsheets, half of our actual sprint time went into modeling exception paths nobody had mentioned in the kickoff call, because nobody thought to.
Compliance and data sovereignty aren't a later phase
Government data — citizen records, financial data, anything tied to a national ID — carries handling requirements that consumer SaaS doesn't. Where the data is hosted, who can access it, how long it's retained, what happens on an access request: these have to be architectural decisions from day one, not a compliance checklist applied after the system is built. Retrofitting data residency into a system that was built assuming none of this mattered is not a small change; it is frequently a full rebuild of the storage and auth layers.
What we actually recommend
- Scope the workflow with the people who run it today, not just the office issuing the tender.
- Ask any vendor to name the exception paths they're explicitly not handling in v1 — if they can't name any, they haven't looked closely enough.
- Decide data residency and access control before architecture, not after a security review flags it.
- Prefer a vendor who will demo working software in sprints over one who presents a finished-looking deck with no live system behind it.
None of this is exotic advice. It's the same discipline that keeps any production software project honest — it just matters more in government work, where the cost of a wrong assumption is a citizen-facing failure, not a missed sprint deadline.