The first agency asked for something specific. Your team built it, mostly by hand, and it worked well enough that people inside the agency talked about it. Now a second agency wants the same thing, except its taxonomy is different, its data arrives on a different schedule, and it cannot use a service that runs on your infrastructure. This is the moment a data company either builds a government edition or accumulates a portfolio of one-off systems that each need someone to remember how they work.
The decision is usually framed as a resourcing question, which is why it goes badly. It is an architecture question. What separates a product edition from a pile of custom deployments is not how much work went in, but whether the differences between customers live in configuration or in code.
Why the second agency is the one that matters
A single custom build for one agency is a consulting engagement with a software artifact attached. It has a revenue number and nothing that compounds. The second request is the signal, because it tells you the underlying need is not specific to one office. What it does not tell you is whether the two needs are the same product with different settings, or two products that resemble each other.
The way to find out is to write down every difference between the two requests and sort them into three piles before writing any code.
- Data differences. Different source systems, different field names, different code sets for the same concepts, different refresh cadences, different volumes. These are almost always configuration, if the pipeline is built to accept a mapping rather than to assume a schema.
- Semantic differences. The agencies use the same word to mean different things, or need a rollup the other does not have. Sometimes configuration, sometimes a real modelling problem. This pile decides whether you have one product.
- Environmental differences. Where it runs, who administers it, how identity works, what the security requirements are, what the interface must support. Never configuration in the sense of a settings file, but almost always a packaging problem rather than a product problem, and it is the pile most companies underestimate.
If the semantic pile is small, you have a product edition and the work is to build the configuration surfaces. If the semantic pile is large and irreducible, the honest answer is that you have a services business in that segment, and the strategy question is whether you want one.
Configuration over customization, concretely
"Configuration over customization" is easy to say and specific to implement. It means a defined set of extension points, each with a schema, each versioned, each testable in isolation, and a firm rule that customer-specific behaviour lives only there. In a data and analytics product for government buyers, the extension points that earn their keep are consistent.
An ingestion mapping layer. Every customer arrives with a different source shape. The mapping from source fields to your canonical model belongs in a declarative artifact, versioned per customer, validated on load, with a clear error when a source changes shape. The pipeline code should be identical across customers. If a new customer requires a code change in the ingestion path, the extension point is in the wrong place.
A reference-data and taxonomy layer. This is the one that decides whether the product generalizes. Agencies classify things by their own code sets, and those code sets change with policy. The product needs a canonical internal taxonomy plus per-customer crosswalks to it, with the crosswalk versioned and the version pinned to any output that used it. A result produced under last year's crosswalk must remain reproducible after the crosswalk changes.
A rules and thresholds layer. Analytical products carry parameters: what counts as material, what triggers review, how a score bands. Different agencies set these differently, and the setting is often a policy decision the customer must own. Put them in a governed configuration store with a change record, not in code and not in a spreadsheet someone emails.
A presentation and terminology layer. Labels, definitions, help text, the names of things in the interface and in exports. Trivial engineering, disproportionate effect. An interface that speaks the customer's vocabulary reads as built for them; one that speaks yours reads as a commercial tool they were handed.
An output and integration layer. Exports in the formats the customer's downstream systems consume, with stable identifiers, and an application interface with documented versioning. Government customers frequently need to move results into a system of record that predates your product.
Extension points that determine whether the second customer is cheap or expensive
Editorial weighting, illustrative rather than measured. The last row is deliberately low: a customer branch feels fast once and is the most expensive decision on this list.
The government data model
Commercial data products model the entities their commercial customers care about. Government customers care about overlapping but distinct things, and the gaps are specific enough to design against.
Agencies think in terms of organizational units, programs and appropriations rather than accounts and territories. They need lineage: not only the current value of a field but where it came from, when, and what it was before. They need point-in-time reconstruction, because a decision made last March will be reviewed against what was knowable last March. They need to record why a value was overridden and by whom, because the override is itself a governed act. And they frequently need to attach their own annotations to your records without those annotations being lost when your data refreshes.
That last requirement deserves attention because it breaks naive designs. If your refresh strategy is to replace a table, every customer annotation keyed to a row identifier that changed is orphaned. The fix is a stable internal identifier that survives refreshes, an entity resolution layer that assigns it, and customer annotations stored against that identifier rather than against a source key. This is unglamorous work that determines whether the product feels like a system of record or a report generator.
Two further properties are worth building early. Coverage statements: for any slice the customer cares about, what proportion of it your data actually covers, expressed as a number the customer can quote in their own documentation rather than a claim they have to take on faith. And explicit freshness: the as-of date on every record and every aggregate, surfaced in the interface and in exports, so a user never has to ask how current a screen is.
Deployable architecture, and why it decides the deal
The single most common reason a strong commercial data product fails to convert agency interest into a contract is that it can only be consumed as a multi-tenant service on the vendor's own infrastructure. The evaluation ends there, before anyone assesses whether the analytics are any good.
Building for more than one deployment target is a design constraint, and it is much cheaper as a constraint than as a retrofit. Three targets cover most of the demand.
| Deployment target | What it demands of the architecture | Who operates it | Where the effort concentrates |
|---|---|---|---|
| Government cloud region | No dependence on services unavailable in the region; identity through the customer's provider; data residency held to the region | You, in an account the customer can audit | Service inventory and substitution; separate build and release pipeline |
| Customer's own cloud account | Infrastructure defined as code the customer can read; no outbound calls to your infrastructure; a licence and telemetry model that works without a callback | The customer, with your support | Packaging, upgrade path, and diagnosing failures you cannot see |
| On-premises or isolated network | Fully offline install; no external model or data dependency at runtime; updates delivered as signed artifacts | The customer, entirely | Dependency vendoring, offline licensing, and a support model without remote access |
| Multi-tenant service only | Nothing extra; the default commercial shape | You | Frequently eliminated during evaluation regardless of product quality |
The engineering discipline that makes all three reachable is the same: no hidden dependence on a service you happen to run, configuration injected rather than assumed, infrastructure expressed as code, and a build that produces a versioned artifact rather than a deployment to one environment. Teams that adopt that discipline for the government edition generally find the commercial product gets easier to operate too, because the same properties make staging environments and disaster recovery straightforward.
One design decision deserves separate mention: any dependence on a hosted model endpoint. If your analytics call a model service over the public internet, that call is a hard blocker in two of the three targets above. The architecture that survives puts the model behind an interface with more than one implementation, so the same product can run against a hosted endpoint commercially, a model deployed inside the customer's environment for a government edition, or a smaller model running locally where nothing may leave the network.
Security documentation as a product artifact
Government buyers require a written account of how a system protects information, who can reach what, how changes are controlled and how incidents are handled. Companies usually treat this as paperwork generated under deadline by whoever is available. Treating it as a versioned product artifact, maintained alongside the code, changes the economics of every subsequent deal.
The practical form is a control description maintained in the repository, written against the control framework the customer's authorization process uses, with each control statement pointing at the mechanism that implements it. When a control says access is logged, the statement names the logging component and the retention setting. When it says data at rest is encrypted, it names the mechanism and where the key lives. Reviewers can tell the difference between a description written from the system and one written from a template, and the second kind generates rounds of questions that cost weeks.
Alongside it, three artifacts pay for themselves repeatedly. A current architecture diagram with data flows and trust boundaries marked, kept accurate rather than drawn once. A dependency inventory with versions and licences, produced by the build rather than maintained by hand. And an accessibility conformance report for the interface, based on an actual assessment, because interface accessibility is a requirement in federal buying and a failure discovered late is expensive to remediate.
The compounding effect is the point. The first agency deal produces this package under pressure. Every subsequent one reuses it with a delta, which turns a multi-week scramble into a review, and it makes your product easier to say yes to than a competitor whose answers arrive slowly.
What slows a government edition down, by frequency in our delivery work
Editorial weighting, illustrative rather than measured. The last row is deliberately low: model quality is rarely what stalls a government edition.
Identity, access and the boring parts that decide adoption
A government edition has to accept the customer's identity provider rather than asking users to create accounts. That means standards-based single sign-on, group membership carried in from the provider and mapped to roles in your product, and a role model expressive enough for an organization that separates duties formally. Commercial products often ship two roles, admin and user, and that is not enough for a customer whose policy distinguishes people who can see data, people who can change parameters and people who can approve a change.
Audit logging is the companion requirement. Not application logs for your engineers, but a user-facing record of who did what, when, and to which record, retained for the customer's stated period and exportable in a form their own reviewers can read. Building this after launch means backfilling a history that does not exist.
The third item is the administrative surface. Someone inside the agency will run this system, and they need to manage users, see ingestion status, review failures, adjust governed parameters and pull an audit extract without contacting you. Every one of those actions that requires a support ticket becomes a recurring cost and a renewal risk.
The support model, and why it is a product decision
A government edition deployed into a customer-controlled environment cannot be supported the way a multi-tenant service is. You cannot look at production. You cannot deploy a fix at will. The support model has to be designed accordingly, and it is better decided during the build than discovered during the first incident.
0
Companies that skip this end up flying engineers to sites or asking for screen shares during incidents, which is slow, unpopular, and does not scale past a few customers.
Keeping the commercial roadmap moving
The organizational risk is more common than the technical one. A first agency deal absorbs the product team's best engineers, the commercial roadmap slips two quarters, and the company learns the wrong lesson about whether government business is worth having.
The structure that avoids it separates the work by type rather than by feature. The government edition is mostly packaging, deployment, identity, documentation, configuration surfaces and a support model. It is real engineering, but it is not the analytical core, and it does not need the people who understand the models best. It needs people who are good at deployment, security engineering and systems integration, working from the same codebase, contributing the extension points back into the main line rather than forking.
That is the shape an outside engineering partner fits well. The partner builds the government edition inside your repository, against your architecture, while your product team keeps shipping the roadmap the commercial business is funded on. The extension points the partner adds are improvements to the product, not a parallel branch, which is why the arrangement only works when the partner works in your codebase rather than beside it.
How we work inside a data company building this
Precision Federal builds AI, data and cloud systems and delivers them into production, including inside federal agencies. On a government edition we work in your repositories alongside your team, and the deliverable is running software rather than a plan.
The first three weeks produce a written architecture for the edition, naming the extension points and specifying each one's schema; a difference analysis across the agency requests you already have, sorted into the data, semantic and environment piles, so the product question is answered with evidence; a deployment target decision with the dependency inventory that supports it, including any hosted service that will not be available; and a running deployment of a thin slice into the target environment, so the packaging is proven before the feature work starts.
After that the work runs in fixed increments with acceptance criteria written before each one begins. Typical increments: the ingestion mapping layer and its validation, the taxonomy crosswalk service with version pinning, identity integration and the role model, the audit log and its export, the administrative surface, the deployment package for each target, and the security control description maintained in the repository against the framework your customer's process uses.
You keep all of it. Code in your source control under a written assignment, data in your environment, documentation as your asset, models and configuration yours. Your engineers work in the codebase throughout so operating and extending the edition afterward is continuous with building it. Your customer relationships stay yours, and we stay unnamed unless you want us named.
Pricing is fixed-price by milestone where scope is defined, or a committed team at a fixed monthly rate where you want capacity you direct. Not hourly, because hourly puts our interest against yours on every estimate.
The first step is one email with a one-page brief: what the product does, what the agency requests have asked for, where it must be able to run, and what date matters. We return a scoped, priced statement of work with the increments and acceptance criteria written out.
Bottom line
A government edition is won or lost on packaging, not analytics. The companies that build one successfully make the same four moves: they sort the differences between agency requests into data, semantics and environment before writing code; they put every customer difference behind a versioned extension point rather than in a branch; they design for a deployment target the customer controls, which means no runtime dependence on services they cannot reach; and they maintain the security control description as a product artifact in the repository so the second deal reuses the first one's work. Do that and the second agency is cheaper than the first. Skip it and every agency is the first agency again.
Frequently asked questions
Write down every difference between the agency requests you have and sort them into three piles: data differences such as field names, code sets and refresh cadence; semantic differences where the same word means different things or a rollup is needed that another customer does not have; and environmental differences covering where it runs, how identity works and what the security requirements are. Data and environment differences are nearly always packaging and configuration problems. If the semantic pile is small you have one product with extension points. If it is large and irreducible, you have a services business in that segment and should decide deliberately whether you want one.
A defined set of extension points, each with a schema, each versioned, each testable alone, and a firm rule that customer-specific behaviour lives only there. For a data product that usually means a declarative source-to-canonical mapping, a taxonomy crosswalk layer with versions pinned to every output produced under them, a governed store for thresholds and rules the customer owns, terminology configuration in the interface, and an export and integration layer with stable identifiers. If onboarding a new customer requires a code change in the ingestion path, the extension point is in the wrong place.
Not always, but the ability to is frequently what keeps the product in the evaluation. Many agencies will not consume a capability that exists only as a multi-tenant service on a vendor's infrastructure, and that constraint is applied before anyone assesses the analytics. Designing for a government cloud region, a customer-controlled cloud account and an isolated network is much cheaper as an upfront constraint than as a retrofit. The discipline it requires, no hidden dependence on a service you happen to run, injected configuration, infrastructure as code and a versioned build artifact, tends to improve the commercial product too.
A written control description maintained in the repository against the framework the customer's authorization process uses, where each control statement names the mechanism that implements it rather than restating the requirement. Alongside it, an architecture diagram with data flows and trust boundaries kept current, a dependency inventory with versions and licences produced by the build, and an accessibility conformance report based on an actual assessment of the interface. Treated as a versioned product artifact, this package is written once and reused with a delta on every later deal, which is where the compounding return comes from.
Separate the work by type rather than by feature. A government edition is mostly packaging, deployment, identity integration, audit logging, an administrative surface, documentation and configuration surfaces. That is real engineering but it is not the analytical core, and it does not need the people who understand the models best. Staff it with people strong in deployment, security engineering and systems integration, working in the same codebase and contributing the extension points back into the main line rather than forking. That separation is also why an outside engineering partner fits, provided the partner works inside your repository rather than beside it.