Build, buy, or configure: choosing an approach for an agency system

Reference article · 8 min read

An agency needs a system: permit intake, case management, licensing. Someone asks whether to build it, buy it, or configure something the agency already licenses. The answer often arrives as a preference rather than an analysis, shaped by whichever project the people in the room lived through.

These are four different commitments, not four prices for the same thing. Each one places cost and risk somewhere: on agency staff, on a vendor's roadmap, on a platform license, or on a project the agency does not control. The license or contract price is one line in the total, and often the only line visible at the time of the decision. None of the four is better than the others in general. Each fits a particular set of conditions, and the sections below give those conditions and the ways each approach fails.

Custom development

Software written for the agency by a contracted team, by in-house staff, or by both.

It fits when the process is particular to the agency and cannot be changed, when most of the work is moving data between systems the agency already runs, when the need is too narrow for any product to address, or when the agency needs to control what changes and when.

It costs sustained attention. Someone from the program has to define requirements, decide on a regular cadence, and accept the result. After go-live the agency still funds rule changes, dependency updates, security patching, hosting, and accessibility testing, because no vendor is doing that work on its own schedule.

It is the wrong choice when nobody can own the product day to day, when requirements come from a group that will not decide, or when the agency is rebuilding what many vendors already sell. It also fails through key person dependency: one developer who knows the system, and no documentation.

A commercial product

A vendor's software, licensed as a subscription or installed on agency or hosted infrastructure, configured for the agency, usually with implementation services attached.

It fits common government functions where many agencies do roughly the same thing, because the vendor's development and maintenance costs are spread across its customer base. Updates for widely shared regulatory changes are often part of the subscription, though what is covered, and at what price, is a contract question rather than an assumption.

It costs more than the license. Configuration, data migration, interfaces, training, and change management are separate line items, and renewal terms often escalate, so price the full term rather than the first year. The cost least often planned is the work of fitting agency process to the product.

It is the wrong choice when the gap between the product and the requirement gets filled with custom modules the vendor supports poorly, when the roadmap is set by customers much larger than the agency, or when the contract makes leaving expensive.

A low-code platform configuration

An application assembled on a commercial platform, often one the agency already licenses, using forms, workflow rules, and configuration rather than hand-written code.

It fits workflow, approval, tracking, and inspection processes, particularly where agency staff will own the build and where a first working version can be delivered early enough to test the idea with real users.

It costs in licensing and in governance. Per-user or per-application pricing grows with adoption, and without a standard for who may build, how changes are tested, and how applications reach production, agencies accumulate applications nobody owns. Screens built this way still have to be tested for accessibility against whatever standard the agency is required to meet.

It is the wrong choice for high transaction volume, complex calculation, heavy integration, or strict performance and availability requirements. What is built is generally tied to the platform, so treat it as a long-term platform commitment rather than a quick fix.

An open-source implementation

An existing publicly licensed codebase, deployed and maintained by agency staff or by a support vendor. This ranges from mature infrastructure software to applications released by another government.

It fits when a capable project exists, when comparable organizations run it in production, when the agency wants the ability to change support vendors without changing software, and when being able to inspect or modify the code matters.

It costs everything the license did not: hosting, upgrades, security monitoring and patching, integration, and support, paid either in staff time or in a support agreement.

It is the wrong choice when the absence of a license fee is the reason for choosing it. Check how many production deployments exist outside the project's origin, how active the contributors are, and who answers when the system fails outside business hours. A fork nobody maintains upstream becomes custom development without the budget line. License obligations also differ between permissive and copyleft licenses, and they matter most if the agency modifies and distributes the code.

How to decide

The questions below are ordered so that the early answers narrow the field and the later ones separate what is left. Write the answers down, because they become the justification in the record.

1. Trace each unusual requirement to its source. For every part of the process no product seems to support, identify the statute, regulation, interface to a state system, grant condition, or records requirement behind it. Requirements with a source are constraints, and they push toward custom development or configuration. Requirements that turn out to be habit are negotiable, which keeps a product in the running and moves the work into change management.
2. Count the interfaces and the volume. List each system the new one must exchange data with, the direction, the frequency, and the peak transaction volume. High volume, complex calculation, or strict performance requirements argue against a low-code configuration. Many interfaces and little unique business logic often mean the real project is integration around systems the agency already has, not a new system of record.
3. Name the owner in year three and the budget line that pays for it. Custom and open-source systems need technical ownership. Products and platforms need a contract manager with time to do the job. If the name is missing, drop the options that depend on it instead of assuming someone will appear.
4. Find out who else runs it in production. Ask in market research how many comparable organizations use it, at what size and volume. Talk to agencies similar to yours, including at least one that moved off the option. Anything with no comparable production use is a pilot and should be scoped and priced as one.
5. Price the full life in the same categories. License or subscription with renewal escalation, implementation, migration, interfaces, hosting, support, agency staff effort, at least one major upgrade, and the cost of leaving. Compare totals over the same number of years. When two options come out close, decide on ownership and exit rather than on price.
6. Test the exit before the entry. Ask for the export format, the cost of an export, whether history and attachments come with it, and who holds rights to configuration and to code the agency paid to develop. Weak answers should lower an option's score whatever its price.
7. Check the obligations the agency cannot transfer. Accessibility, public records and retention, security and privacy review, and any rules specific to the data involved apply to the agency regardless of who wrote or hosts the software. Ask for evidence, such as a current accessibility conformance report, and test against the standard your agency is required to meet rather than accepting a claim.
8. Structure the first phase so it can be stopped. A pilot, or a demonstration scripted on your scenarios and your data, shows more than a vendor-run demonstration, and a small first phase limits what a wrong answer costs.

What this means for your solicitation

• Describe the outcome and the mandatory requirements rather than the implementation. Naming an approach in the scope excludes options that might fit better.
• Consider allowing more than one approach in a single solicitation, scored on the same criteria: fit to mandatory requirements, cost over a defined period, exit provisions, and evidence of production use elsewhere.
• Require a complete cost model covering license or subscription, implementation, interfaces, hosting, support, and renewal years, along with data ownership, export at no additional charge, and escrow or delivery of source code the agency paid to develop. State the rights the agency expects in the contract rather than negotiating them after award.
• Ask every proposer how they would close the gap between the requirement and what they offer. Configuration, extension, and custom module carry different lifetimes and different support obligations.
• Score a demonstration built on your scenarios and your data, and keep the first phase small enough to stop after.

HQT provides custom development, systems integration, and platform and open-source implementation services for public agencies, including the assessment that precedes this decision.

Frequently asked questions