Choosing the best path to modernization
Over the last 10-15 years, many government leaders looking to modernize have shifted away from complete reliance on self-built custom software. There has been a notable shift towards vendor Software-as-a-Service (SaaS) solutions, as leaders pursue best-of-breed functionality, continued feature enhancements, and shorter time to launch. Today’s SaaS solutions offer low- and no-code composability and easy API integrations — some purpose-built for government, others adapted for public sector use. But government modernization still moves slowly, so a mix of self-built and off-the-shelf software still powers operations in most agencies.
But the modernization landscape has changed since we first published the original version of this guide in 2022. Today, AI tools have made it fairly straightforward for even a non-technical person to “vibe code” websites and applications, and AI coding tools have enabled software developers to ship new solutions faster. In the AI era, the build-versus-buy question has once again stepped into the foreground of modernization planning. Today, a working prototype of a government solution or app is within reach of nearly any team, no matter how technical.
Along with the need for rapid modernization, leadership is confronted with a range of challenges: constrained budget, evolving community requirements, and ambitious business objectives in the agencies they serve. And the public sector is in the midst of a talent crunch that can present additional challenges for building and maintaining custom software systems.
That leaves leadership with a decision among three approaches:
Build a system in-house, the traditional way
Assemble one in-house with AI tools
Buy a composable software system from a vendor
If you zoom out, it seems like a simple choice: If the software solves a problem only you have, build it. If solutions on the market already address your problems, buy them. But it’s really a multifaceted decision that depends on the IT team, current tech stack, budget, and the features your community needs.
Real efficiency gains depend on broad adoption of digital services
Keep in mind that simply offering digital services doesn’t guarantee results. Widespread adoption by residents is the only way to achieve meaningful improvement in your operating efficiency, but it is not a foregone conclusion.
Our 2026 research among more than 600 government IT and line-of-business leaders found that on average, only 49.5% of resident payments are collected online today. And while 89% of the 1,038 U.S. adults we surveyed reported they had completed at least one government transaction online recently, more than one in three also reported they had abandoned an online transaction due to a confusing interface, technical problems, eligibility issues, or not being able to use a preferred payment method.
Poorly-adopted digital solutions can actually worsen an agency’s operating efficiency: now there is a digital payments channel to manage, but meaningful changes in mail or in-office volume don’t materialize. And if a digital solution is difficult to use or confusing, it can increase customer support costs.
As you evaluate the best path for your agency, look beyond just the required functionality to the user experience. Whether you build or buy, make sure the solution has an intuitive interface that gives residents from all walks of life the confidence to proceed with their transaction. A great user experience, combined with a communication strategy that builds awareness of the solution in your community, is the only path to broad-based adoption.
Define your goals and needs
Do you really need custom software?
Sure, agency processes differ, but that doesn’t necessarily mean you are a unicorn forced to build a solution in-house. Coding a software solution from scratch takes time (sometimes years) before it adds value to your agency’s operations. With the advent of composable, cloud-based SaaS, it’s more likely than ever that there’s a solution already developed that can be configured and leveraged quickly, saving internal IT horsepower for projects that really require it.
Before deciding, the most important thing to clarify and prioritize are your desired business outcomes and the features that best support those outcomes.
Business outcomes to prioritize
Features that you may need
It’s important to scrutinize a proposed project’s requirements and scope carefully. Consider whether any customizations included will have a meaningful impact on the outcomes the project is meant to achieve.
Factor in these key criteria
Evaluating functional requirements and features is a great first step. But other needs such as security and compliance, IT demands, staff skills, and innovation possibilities shouldn’t be overlooked — failure to consider these criteria could drain your budget and frustrate staff, or worse yet, leave you without an MVP (minimum viable product).
Just as a build requires careful consideration, buying software requires due diligence into the product, the vendor, and the team that will support your account. And an AI-assisted build carries its own unique risks.
Speed and innovation
SaaS vendors can provide scalable solutions that add new features and improvements over time. These companies have the team (and financial incentive) to deliver quickly and improve their product continuously. Unless you have a large IT team, building a solution will likely take longer to launch and iterate.
Usability
Even if your team has the technical skills for a build, it’s crucial to consider whether or not user-friendly design is your core competency. A functional, technically sound product won’t be of any value to your stakeholders or residents if it’s not easy to use. (Remember: Usability ties back to tech adoption, both inside your agency and among residents.)
Security
In-house doesn’t automatically mean more secure. In fact, the opposite often proves true. With an in-house build, the agency is solely responsible for protecting against malware, data breaches, phishing attacks, and other hacking attempts — which requires constant monitoring and regular testing and patching. When software is built with AI tools, especially without strong QA oversight and rigorous, ongoing security testing, the risk deepens. Cybersecurity vendors Veracode and Checkmarx have found that 45% to 70% of AI-generated code includes significant vulnerabilities. With IBM putting the cost of a breach north of $4M dollars, the security risk of a self-built solution is real.
On the other hand, solutions that use government cloud solutions benefit from enhanced security and lower costs, minimizing risks for the agency. A FedRAMP– or StateRAMP-authorized platform doesn’t just claim to be secure, it has to prove it on a fixed schedule: monthly vulnerability scans, a full independent third-party audit every year, and set deadlines to patch whatever those audits find.
That upkeep is backed by resources no single agency’s IT budget can approach: Microsoft and Google alone have committed $20 billion and $10 billion to cybersecurity investment in recent years.
And even if you self-build and host on a government cloud offering, risks remain. Gartner has found that through 2025, 99% of cloud security failures trace back to customer misconfiguration, not the underlying cloud infrastructure. Consider whether your team has the know-how to properly configure and maintain secure hosting.
Payments and Compliance
If your service includes payments, there are additional considerations before deciding to build your own. Deeply integrating payments into a software experience is not trivial work – the path of least resistance involves third-party processors that take the resident out of the main app workflow to complete payment — and the experience feels clunky and cobbled-together. This can be confusing to the user and undermines your ability to assist with questions or payment problems.
Do you want to own the responsibility and cost to stay PCI-DSS compliant, or does it make more sense to offload it to a vendor with stringent guidelines already in place? An in-house build would mean that your team is responsible for the cost of the initial assessment and certification, as well as upgrades, annual tests, and recertification.
Integrations
Integrating software to your system of record and payment rails can be surprisingly challenging. A good tech vendor will have the experience and tools to make integrations work, and may already have the payments integration in place. But if you build, you’ll have to create an API or flat file exchange with any of your in-house systems, as well as integrate payment processing in a way that feels seamless to the user. Even AI-assisted builds can struggle with that process.
Platform extensibility
The best approach for broad resident adoption and ease of management is a resident-facing platform that pulls together all digital services and payments, even complex ones, into a single place. While it may seem straightforward to build the basic online application form or payment page you need today, these solutions can proliferate into a patchwork of hard-to-manage pages and forms. Ensuring the ongoing security and operation of dozens of disparate solutions built over time creates a significant burden for the tech team.
Think about the future from day one — even if the near-term requirement seems simple, over time you will want more from digital modernization, and that makes self-building more daunting. You’ll ultimately want to offer complex or conditional workflows, document reviews, calls to your system of record or other databases, and pull all of that together in a cohesive experience for your team and your residents.
Customization
For leadership looking to solve a complex and truly unique use case, there is a small chance that no available solution can solve it, and some custom building is required. However, this is increasingly rare. Given the wide availability of composable software platforms and low-code solutions for process automation, a thorough market scan should precede a determination that a custom build is truly required. Although every government agency has unique business rules and processes, and the rise of AI-assisted coding lowers the bar for attempting a self-build, it’s rare that a custom requirement cannot be addressed through configuration of a vendor solution.
Vendor lock-in
It’s natural to worry about getting stuck with the wrong vendor. But it’s important to keep in mind that even if you decide to buy a solution from a vendor, you still own your data. That means if you renegotiate terms or decide to switch vendors, you can take it with you. However, always double-check vendor contracts for specifics on the portability of data. Never work with a vendor that says you don’t own your data.
On-staff talent
Does your team have the expertise required to build — then maintain and improve — the system? An in-house build will require a deep bench of subject matter experts such as software engineers, product managers, UX designers, fintech or payments experts, integration managers, infosec experts, quality assurance staff, and more. Even larger agencies may have trouble staffing and retaining a team that large, especially given the public sector talent crunch.
The true costs of building
Cost is one of the biggest considerations in a build versus buy decision, and a simple cost estimate is a good place to start. But over time it will be important to consider the total cost of ownership (TCO) of a solution balanced against the outcomes it drives. And factor in a cost avoidance estimate.
Remember: Building a digital customer experience and payments solution from scratch can take months to years. And, unless the scope is incredibly clear, the project could drag out longer than expected.
Can your budget handle these costs?
Math to build
The average salary for a public sector software developer working in the United States is between $120,000 to $140,000 per year — and that’s not including the cost of other benefits. Multiply that, since you’ll need more than one engineer. And along with the rest of the hires, you’ll also be paying for hardware.
Time to value
Let’s say you decide to build a new CRM system to improve customer engagement and help boost revenue. The agency’s initial costs won’t pay off until it sees improved customer relationships and increased revenue. Can the department’s budgets absorb the development costs until a viable project is complete? (For reference, public-sector projects take 3.9 years to complete, on average. Larger, more complex projects could take longer.)
Security and governance
Once your self-built system has launched, code review, penetration testing, and ongoing security protection continue to carry real costs, even if AI has made it less costly to build the system initially.
Maintenance
The costs don’t stop after a system is launched. Building software requires continued investments to upgrade, add, or change features; address tech debt; and maintain compliance certifications.
Opportunity and strategic business cost
Will an in-house build keep employees from solving other core business problems? Will waiting months or years for a custom-built solution decrease financial and business opportunities? A build can go awry in many ways, using up staff’s valuable time and potentially wasting millions of dollars.
Non-completion is also more of a risk with custom-built solutions — a large percentage fail. And in-house builds almost always cost more upfront, are expensive to maintain, and quickly become outdated. (Unfortunately, that means taxpayers pay more and internal processes are hindered.)
What’s right for your agency?
Consumers are accustomed to having most other services (health care, banking, entertainment, etc.) at their fingertips, and they expect intuitive digital government service delivery. Deploying tech solutions can be a “move fast or fall behind” game. In some instances, it might be better to partner with a specialized vendor that can amplify your team and speed up your goals.
There will be engineering work regardless of whether your team chooses to build or buy, but the two paths require very different levels of time and expertise. A fully custom build could be the right answer, but it will come with a higher cost and a lengthy timeline, and not every agency has the time, staff, or budget to handle an entire build. Composable SaaS technology is a more efficient, scalable, and flexible solution, especially for smaller IT teams or agencies wanting to quickly modernize the user experience.
Given the rapid pace of tech innovation and AI improvements, it’s more important than ever to consider your modernization projects carefully. That’s especially true now that AI has made it straightforward for even non-technical people to build technology, which can look faster on paper but shifts a new set of risks onto your team. Whichever path you choose, make sure it can keep up with how fast technology and resident expectations are changing.
Build vs. Buy:
Questions to ask yourself
Features
- What features are needed now? What about in the future?
- Are priorities clear? Have we decided on “must have” vs. “nice to have” vs “don’t need” features?
- Are future innovations in the picture? How will those be handled?
Technical
- What does our current tech stack look like?
- What’s our data source(s)? Are they accessible?
- Are we capable of integration if needed?
- Are there suitable solutions already available on the market?
Speed of delivery
- What is the timeline? What’s driving the timeline?
- Can the team deliver a solution on time?
- Are there consequences of delivering sooner vs. later?
Design
- What are our user needs (internal and consumer)?
- Do we have the knowledge to prioritize user experience?
Cost
- Have we accounted for all costs?
- How much does speed to delivery accelerate ROI?
- Are there any potential lost opportunities due to resource allocation?
