The right community development system disappears into the background. A resident applies for a permit online in minutes. A contractor tracks a project without calling in. A staff member spends more time serving the public than managing workarounds.

The wrong system makes itself known constantly. Staff maintain spreadsheets on the side. Data that should flow automatically, gets re-entered. People learn how to do their jobs in spite of the software, not because of it. At some point, those frustrations reach the same conclusion: it's time for something new.

For the person tasked with running that evaluation, the path forward may start with a request for proposals (RFP). An RFP is how municipalities and counties signal to the market what they need, attract vendors who can actually deliver it, and create a defensible basis for their final selection. Done well, it's the document that opens the door to something meaningfully better. Done poorly, it's the document that guarantees you'll end up with a more expensive version of the system you already have.

That failure mode is more common than most departments realize. Many procurement documents are written around existing processes — the workflows staff have learned to navigate and the fields that live in the current system. The RFP describes current reality rather than desired outcomes, and vendors respond accordingly. The result is a selection process that evaluates how well each option replicates the status quo, not how well it serves the community.

The best procurements create room for a better solution. This guide is designed to help you write one.

The Goal of an RFP Process

Governments typically use RFPs and similar procurement processes when a purchase is complex enough that price alone can't determine the right choice. The specifics vary by state and jurisdiction. Some purchases may qualify as discretionary spending below established thresholds, while municipalities and school districts may follow locally adopted policies. Before writing your RFP, understand the rules that apply to your department and work closely with your procurement team to comply with them.

Just as importantly, the goal shouldn't simply be to replace an existing system. It should be to create a process that helps identify the best solution available. An RFP written around yesterday's processes is likely to find yesterday's solution. One written around outcomes and open to modern approaches is more likely to uncover what's possible today. 

At a high level, here's how to approach the process:

• Start with outcomes in mind. Define what success looks like before writing requirements.
• Talk to the market before you write. Use requests for information (RFIs), demos, and conversations with peer jurisdictions to understand what's possible.
• Right-size your requirements. Focus on genuine needs rather than inherited specifications.
• Score proof, not promises. Evaluate demonstrated outcomes, references, and real-world performance over vendor claims.
• Look beyond the sticker price. Consider total cost of ownership over the life of the contract.
• Run a process that invites competition. Give qualified vendors a level playing field.
• Buy a platform that improves over time. Evaluate a vendor's ability to evolve the product, not just meet today's checklist.

While every procurement process will have different protocols to follow, the most successful ones tend to follow the same principles. 

Start with Outcomes in Mind

One of the most common mistakes when writing an RFP for government software is jumping straight into a requirements matrix before defining what success actually looks like. Requirements are important, but they should be informed by the problems you're trying to solve.

Before writing a single requirement, identify the outcomes you want the new system to deliver. Those outcomes should be specific enough that your team can clearly define what success looks like and measure progress over time. For community development departments, examples might include:

• Faster, simpler experiences for the public: from submission to approval, without unnecessary trips or phone calls
• Less administrative burden for staff: routine tasks handled automatically, data flowing between systems without manual re-entry
• Greater transparency for applicants: real-time status updates and automated notifications that reduce inbound calls and in-person visits
• Fewer errors and resubmissions: clear guidance that helps applicants get it right the first time
• Higher confidence in local government: through faster turnaround times, consistent service, and a public-facing experience that reflects well on the department

Before drafting requirements, write down your top three to five desired outcomes. Then, as requirements are added, ask a simple question: which outcome does this support? If a requirement can't be tied back to a meaningful objective, it may not belong in the RFP. This approach also leaves room for capabilities and approaches that may not have existed during your last evaluation, often where the most significant improvements are found.

Talk to the Market Before You Write the RFP

Once you've defined the outcomes you're trying to achieve, resist the urge to immediately start drafting requirements. Before you write the RFP, spend time understanding what the market actually looks like.

Many agencies avoid vendor conversations before a solicitation is released out of concern for fairness or the appearance of bias. In practice, procurement organizations such as the National Association of State Procurement Officials (NASPO) encourage early supplier engagement to help agencies better understand the market and write solicitations that reflect what vendors can realistically deliver. Common approaches include:

• Issuing a Request for Information (RFI)
• Scheduling demonstrations with multiple vendors
• Speaking with peer jurisdictions that have recently completed a similar implementation
• Visiting reference sites and talking with staff about their day-to-day experience

This step helps prevent one of the most common procurement mistakes: writing an RFP around an incumbent system or a single vendor's capabilities. The market changes quickly, and capabilities that required expensive customization a few years ago may now be standard. It's worth setting this expectation early; you're choosing among proven, off-the-shelf systems rather than commissioning a custom build. Understanding what's available in the market before drafting requirements means your requirements reflect what's possible today, not what was possible the last time you procured new tools.

Right-Size Your Requirements

After researching the market, you're in a much better position to begin drafting requirements. The challenge is to avoid two common mistakes: copying someone else's requirements and turning every preference into a requirement.

Many RFPs are built from an old proposal or a neighboring municipality's requirements matrix. While that can seem like a shortcut, it often imports someone else's vendor choice rather than reflecting your specific size, processes, and needs. The opposite mistake is just as common: requirements matrices that prescribe specific workflows, reporting formats, or interface preferences so precisely that they eliminate vendors before evaluation even begins.

As you draft requirements, keep the following principles in mind:

A well-written requirements section defines what matters most without unnecessarily limiting how vendors respond. The result is a more competitive procurement and a better chance of identifying the solution that best fits your department’s needs.

Score Proof, Not Promises

A confident claim and a substantiated one often read identically on paper. Nearly every vendor will describe their platform as intuitive, configurable, and capable of meeting your needs. Increasingly, many will describe it as AI-powered, without clearly explaining what that means in practice. The evaluation process is what determines whether those claims are backed by demonstrated outcomes and real-world use cases.

As you design your evaluation criteria, prioritize evidence over descriptions:

• Ask for documented outcomes. Instead of asking what a platform can do, ask what results it has delivered. Look for examples such as reduced permit turnaround times, increased online adoption, or measurable reductions in staff workload.
• Request references you can relate to. A city of 40,000 should talk to other cities of 40,000 — not just the vendor's largest customers. Ask references what implementation challenges they faced, what they would do differently, and whether the platform has delivered the results they expected.
• Use real-world demonstrations where permitted. Rather than a generic product tour, score demonstrations against actual scenarios, such as a permit type your staff reviews every day, your fee schedule, or a workflow that frequently creates bottlenecks.
• Evaluate staff usability. A system that is difficult to navigate leads to workarounds, errors, and abandoned adoption. Usability is an operational consideration, not just a product preference.
• Ask vendors to demonstrate, not describe. Any capability a vendor highlights (AI-assisted review, automated notifications, predictive workflows) should be shown working against a real scenario, not explained in a slide. The question isn't whether the feature exists, but whether it works in practice. 

Don’t simply identify the vendor with the most compelling proposal. Look for the vendor that can demonstrate that they can deliver the outcomes and value your department is looking for.

Evaluate the Total Cost of Ownership, Not the Sticker Price

Cost is an important part of any software procurement, but the purchase price is only one component of what a system will actually cost over its lifetime. A more useful framework is total cost of ownership, which includes implementation, data migration, training, ongoing support, future platform changes, and the operational impact of the system on your department day to day.

Some of the most important costs don't appear in the initial proposal:

• The cost of change. Adding a new permit type, updating a fee schedule, or modifying an approval workflow may require a paid change order on some platforms. Ask vendors specifically whether configuration changes are included in the contract or billed separately.
• The cost of vendor dependency. A system your staff can configure and manage independently is often less expensive over time than one that requires vendor involvement for routine updates.
• The cost of data migration. Moving records from a legacy system is often scoped separately and can be significant depending on data quality and volume. Ask how migration is scoped, priced, and who is responsible if it takes longer than expected.
• The cost of training and onboarding. Initial training may be included, but what about staff turnover? Ask whether ongoing training for new employees is covered or billed separately.
• The cost of ongoing support. Understand what is included in the contract and what generates additional fees. Ask whether support covers your staff and your community — and whether you'll have a dedicated point of contact or a general help queue.

As part of the evaluation process, ask vendors to clearly identify what your team can control after go-live and what requires their involvement. The answer often has more impact on long-term cost than the contract price itself.

Run a Process That Invites Competition

Competition is one of the most effective tools a municipality has for finding the right solution at the right price. More qualified vendors in the process generally means better options, better pricing, and a greater likelihood of finding a solution that fits your department's needs.

That means creating a process that gives qualified vendors a fair opportunity to compete. Timelines should provide enough time for new vendors to respond. Requirements should be written around outcomes rather than an incumbent's feature set. Evaluation criteria should reward demonstrated results rather than years of prior relationship.

Incumbents win re-procurements more often than they should — not always because they're the best option, but because the process was written around what they already do. If only one vendor can realistically satisfy your RFP, you haven't evaluated the market. You've documented a decision you already made.

Buy a Platform That Improves

Community development software isn't a one-time purchase. Long after implementation is complete, your department will still be adapting workflows, responding to regulatory changes, and looking for ways to improve the experience for the public.

The vendor you choose today is also the partner you'll rely on in the future. A platform with a consistent release cycle is more likely to keep pace with changing regulations, evolving community expectations, and new technology. One that improves infrequently (or that builds without input from the departments using it) can become a source of friction as quickly as it became a solution.

As part of your evaluation, ask vendors what they have developed in the last 24 months and how they decide what gets built next. Review their product roadmap and look for evidence that it reflects the challenges community development departments are actually facing. When speaking with references, ask not only about the implementation experience, but how the platform has changed since go-live — and whether those changes have made a difference.

Conclusion

The software your community development department selects will shape how staff work, how the public experiences government, and how efficiently your department operates for years to come. A thoughtful RFP improves the odds of finding a solution that fits your community's needs, delivers measurable results, and continues to improve over time.

GovWell works with community development departments across more than 40 states. If you're preparing a software procurement, we offer a step-by-step guide with examples from real RFPs and a fill-in template designed specifically for municipal procurement teams. Talk with our team about what other municipalities have learned going through this process.