The Difference Between Configuration and Custom Software in GovTech

August 2025

Ask any platform vendor whether their product can handle your process and you'll hear the same word: configurable. It isn't a lie. It also isn't an answer. Configuration and custom software solve different problems, and which problem you have is the most expensive question in a procurement — usually answered after the contract is signed, when the answer costs the most.

What Configuration Honestly Covers

Configuration means adjusting a system within the shapes its designers anticipated: rename fields, add fields, build a form, set up an approval chain, change a notice template, turn modules off. If your process fits the platform's underlying model — what a record is, who touches it, how it moves — configuration is genuinely enough. It deploys in weeks, the vendor maintains it, and it survives upgrades. A standard license renewal cycle, a fee table, a basic inspection calendar: configure it and move on. When the shoe fits, wear it.

Where Configuration Ends

It ends at the data model, and the data model is invisible in a demo. Here is what the boundary looks like on the ground. A backflow assembly sits at a rental property. The platform has one Primary Contact field per service address. The assembly needs two responsible parties — the owner who pays for the annual test and the property manager who actually schedules it — and they need different letters at different times. There is no setting for that. The vendor suggests putting the property manager in the comments.

So staff adapt. Within a year there is a field called Notes2 that everyone in the office understands to mean "exempt — see paper file." The new utility clerk doesn't know that. Two wrongly issued shutoff notices later, she does. Then a consultant builds the workaround layer: a nightly export, a cross-reference spreadsheet, a mail merge that adds the second party back into the letter batch. It works until the platform's next upgrade renames the export columns, and the workaround quietly starts dropping records. Nobody is assigned to notice.

None of this appears as a line item. The system demos as a fit and operates as a misfit, and the gap is paid in staff hours indefinitely.

The Five Awkward Parts Test

Before you buy, write down the five most exception-heavy parts of your real process. Not the intake form — the weird parts. The assembly with two responsible parties. The vacant service that still has a device on the line. The tester whose certification expired between the test date and the report submission. The account that exists twice because the billing system and the county assessor disagree about the address. The thing you track in a spreadsheet because the last system couldn't hold it.

Then make the vendor show — not describe — how each one lives in their system, on screen, with the record open. If all five fit naturally, configure with a clear conscience. If the answers involve repurposed fields, a comments workaround, or the word roadmap, you have found the boundary. A workflow specific enough that you'd be funding workarounds for years is specific enough to justify building.

The Five-Year Math

Configuration looks cheaper because its costs arrive later, as operations — the reconciliation spreadsheet, the quarterly report assembled by hand, the clerk hours spent translating Notes2 for every new hire. Custom looks expensive because its costs arrive first, as a project. Compare both over five years, staff time included, and the answer flips more often than vendors would like.

Five Cases, First Demo

Configurable is a property of the software. Fit is a property of your workflow, and only one of them is on the demo screen. When the work fits, configuration is the responsible choice — take the faster, cheaper path without apology. When the exceptions are the work, no settings page will close the gap. Write down your five awkward cases before the first demo. They will tell you which procurement you are actually running.