Why Vertical SaaS Companies Selling to Local Governments Stall at the Second State

The first customer writes the product spec

A govtech company's first government contract rarely starts with a product. It starts with a jurisdiction's specific workflow: a county clerk's filing process, a state's benefits eligibility rules, a city's permit review sequence. The engineering team builds to that workflow because that is the only workflow in front of them, and because the contract has a go-live date that does not care about architectural purity.

This is a reasonable way to get a first government customer. It is a poor way to build a product, because the rules of that first jurisdiction get written directly into the application rather than treated as data the application reads.

Why hardcoded compliance rules are the default, not a mistake

Most engineering teams do not set out to hardcode compliance logic. It happens because government requirements are specific, numerous, and rarely documented in a form a developer can turn into a clean data model on day one.

A benefits eligibility rule might depend on household size, income thresholds that update annually, residency rules, and interactions between state and federal programs. A procurement compliance rule might require a specific retention period for records, a specific audit trail format, or a specific accessibility standard tied to that state's version of a disability access law. Under deadline pressure, the fastest way to ship any of this is an if-statement: if state equals the first customer's state, apply these thresholds, require this audit format, generate this specific form.

That if-statement is not a bug. It is the correct short-term decision. The problem shows up eighteen months later when a second state signs a contract, and nearly every one of those if-statements needs a second branch, written by someone who is reading an unfamiliar state's administrative code for the first time and trying not to break the first customer's production system while doing it.

Procurement cycles are not a sales problem, they are a build constraint

Horizontal SaaS companies that expand into a new vertical face a market-fit problem: does the product solve a real pain point for this new buyer, and will they pay for it. Govtech companies expanding to a second jurisdiction face something closer to a legal and procedural constraint, because the thing that differs between a state's procurement office and a county's procurement office is not taste or workflow preference. It is statute.

One jurisdiction might require a competitive RFP with a mandated minimum posting period. Another might allow a cooperative purchasing agreement that lets an agency simply adopt a contract another agency already competed for. A third might require a separate security assessment and a state-specific data residency requirement before any contract can be signed. These differences are not configurable in the sales process. They determine what has to be true about the product before a deal can even be discussed, let alone signed.

This is a meaningfully different expansion problem than the one covered in why vertical software companies build around utility procurement cycles, where a company adapts its sales calendar to a buyer's budget cycle. In government SaaS, procurement variance also reaches backward into the product itself: data residency requirements affect infrastructure, audit trail requirements affect the data model, and accessibility statutes affect the UI layer. A company cannot sell its way around a feature that a second state's procurement rules make mandatory.

The configuration layer nobody budgets for

The fix is a configuration layer that separates jurisdiction-specific rules from core application logic: eligibility thresholds, form templates, audit retention periods, and approval workflows all become data the system reads rather than code the system runs. Building this layer after the fact is expensive in a specific way. It requires finding every hardcoded rule scattered across the first customer's build, extracting it without breaking a live government system that cannot tolerate downtime, and replacing it with a general mechanism flexible enough for rules nobody has written yet.

Teams that have done this migration describe it less as a refactor and more as an excavation. Every rule has to be traced back to the statute or regulation that produced it, because the team needs to know which parts are genuinely jurisdiction-specific and which were just implemented in a jurisdiction-specific way out of convenience. A rule that looks like a California-specific requirement might actually be a general best practice the team happened to learn from California. A rule that looks generic might be legally required only in that one state. Getting this wrong in either direction either locks the product to one jurisdiction forever or quietly drops a compliance requirement a new state assumes is being enforced.

This work also touches hiring. A configuration layer substantial enough to support multiple states usually needs someone who understands both the legal domain and the data model well enough to design the abstraction, which is a different skill than shipping a feature to one government buyer under deadline. That compounds with the staffing reality described in why hiring engineers gets harder once a startup sells to government, where background checks and clearance timelines already slow down who can even touch the codebase.

What to build generically from day one

A team that knows government will be its first customer segment can make a handful of decisions early that are far cheaper than fixing them later.

Treat jurisdiction-specific numbers as configuration, not constants: thresholds, fee schedules, retention periods, and deadlines should live in a rules table an administrator can edit, not in application code. Separate the audit and compliance layer from the business logic layer, because audit requirements are usually the most jurisdiction-variable part of a government product and the easiest to isolate if isolated early. Build the data model around the regulatory concept, not the first state's terminology for it, since two states almost never use the same word for the same legal category.

None of this requires anticipating every future jurisdiction's rules. It requires resisting the urge to let the first contract's urgency become the product's permanent architecture. The first government customer will always shape the product. The question is whether that shape is a feature the company can turn on and off, or a wall it has to tear down to let the next customer in.