Buy or Build? What Homegrown Rulemaking Systems Cost Agencies

A lot of state agencies are running the same setup. A rulemaking tracker built in-house years ago, by a developer who has since moved on. It runs on a version of SharePoint nobody wants to touch. It "mostly works," except during the stretch when it doesn't, and that stretch always seems to land right before an audit or a legislative session.

Washington State's Department of Health knew that setup well. Rule reviews and approvals lived in a homegrown system, while collaboration happened over on a separate SharePoint site. When the homegrown system broke or needed an update, fixing it was a time- and labor-heavy process, and it still couldn't give the department a way to manage or analyze citizen engagement on its rulemakings. WA DOH scoped other rulemaking platforms before choosing to modernize with a purpose-built system instead of patching the one it had.

Build or buy used to be a close call, it isn't anymore. IT budgets tightened, audit requirements got stricter, and the agencies still running rulemaking through a system one person understands are the ones feeling it first.

The math on building it yourself doesn't work like it used to

A homegrown system feels free in year one. It's staff time, not a line-item cost, so it doesn't show up on anyone's budget request. That's exactly what makes it expensive later.

IT teams are already stretched across the things that actually can't wait.
Network uptime, endpoint security, cyber threats. A rulemaking tracker competes for the same limited hours as the problems that show up in a breach report. Every hour spent patching a homegrown system is an hour not spent on the modernization work leadership actually asked for. When a home-built system needs a fix, someone is pulled off a higher-priority initiative to do it, and that initiative is the one that quietly slips.

Institutional knowledge walks out the door with the one person who understands the system.
Ask any IT director what happens to a custom build when the developer who wrote it leaves. Usually: nobody touches it, everybody's afraid of it, and it runs on hope until it doesn't.

The real cost of a build is almost never the build.
It's licensing for the tools underneath it, staff hours for testing, the ongoing maintenance nobody scoped at the start, and the other priorities that get bumped every time the internal system needs attention. A SaaS platform has a cost you can actually budget for. A homegrown system has a cost you find out about later.

What this looks like day to day

For a rulemaking coordinator, it looks like tracking redline versions across six email threads and hoping the "final_v3" someone sent last week is actually final. For general counsel, it's not being able to say with confidence which version of a rule was in effect on a specific date, without reconstructing the timeline by hand. For an agency executive, it's getting asked "are we compliant?" during an audit and not having a fast, defensible answer, because the record lives across three systems and one shared drive.

None of that is a technology failure so much as an infrastructure failure. These tools weren't built to govern, they were built to hold documents.

Why agencies are choosing a partner who's done this before

The agencies moving off homegrown systems aren't chasing a shiny new feature. They're solving for four things a custom build almost never delivers:

A platform that's actually built for how government works.
Complex approval hierarchies, mandatory review cycles, multi-stakeholder sign-off, public-facing publication requirements. Generic tools need to be bent into this shape. Government-built platforms already assume it.

An audit trail that holds up when someone asks.
Full version history, timestamps, role-based access, and a record of who acknowledged what and when. When an auditor or a records request comes in, the answer should take minutes, not a week of reconstruction.

A deployment timeline you can actually plan around.
A defined professional services process, from discovery through configuration to launch and training, means an agency knows its start-to-finish timeline after kickoff. Custom builds rarely offer that kind of certainty.

Continuity that doesn't depend on one person staying employed.
A platform maintained by a team with deep experience across dozens of agencies is not vulnerable to a single staff departure. That stability is the whole point.

Esper's own work with agencies like Washington State DOH, Iowa's rulemaking agencies, and Kansas's statewide rules portal points to the same pattern. These are agencies that scoped their options, weighed a purpose-built rulemaking platform against continuing to patch what they had, and chose the platform because it gave them consistency at scale that a homegrown fix couldn't.

The real question isn't build vs. buy. It's what you're actually protecting.

Most agencies didn't set out to build a homegrown policy system that would become a liability. They built something that solved a real problem at the time, with the tools and budget available then. The system did its job for years. The conditions around it just changed faster than it could.

The agencies rethinking that decision now aren't doing it because building software is bad. They're doing it because the risk of a policy record that can't stand up to an audit, a records request, or a leadership transition has gotten harder to justify carrying.

If your agency is still running rulemaking through a system one person understands, or a SharePoint site duct-taped to something older, it might be worth asking not "could we build something better," but "what would it cost us if we didn't have to."

Curious how Esper's rulemaking and policy lifecycle platform compares to a custom build for your agency?

Request a briefing to learn how we're working with other state agencies and what a defined implementation timeline could look like for you.