How Public-Sector Teams Buy Custom Software Without a Painful RFP

If you work in a municipality, a health authority, a school district, or any public body, you already know the problem. The tool you need doesn't exist off the shelf, the vendors who do exist want a five-year contract and a login for every seat, and the moment you say "custom software" someone says "that means an RFP" — and an RFP means six months, a committee, and a real chance that nothing ships at all.

It doesn't have to work that way. Public-sector teams buy custom software all the time without drowning in procurement. The trick is knowing which lane you're actually in before you start.

Start by being honest about the size of the buy

Procurement rules scale with dollar value. Almost every public body has a tiered threshold structure — small purchases can be made directly, medium ones need a few written quotes, and only the large ones trigger a full competitive RFP. The exact numbers vary by jurisdiction and by the trade-agreement coverage that applies to you, but the shape is always the same.

The mistake teams make is assuming "custom software" automatically lands in the top tier. It often doesn't. A focused first build — one workflow, one form, one integration — frequently fits inside the quote-based tier, not the RFP tier. You don't need to procure the whole five-year vision on day one. You need to procure the first useful thing.

Use a pilot to de-risk the buy and the procurement

This is the single most useful move available to a public-sector buyer: scope a small, fixed-price pilot first.

A pilot build is one workflow, delivered in a couple of weeks for a fixed price. From a procurement angle, that does three things at once:

• It usually fits under your direct-purchase or quote threshold, so you skip the full RFP.
• It produces a working artifact your team can actually evaluate — not a slide deck or a reference call.
• It gives you real numbers and a real working relationship to point to if a larger build later does go to competitive procurement.

A pilot turns "we think this vendor can do it" into "this vendor already did the first piece, on time, for the price they quoted." That is a far stronger position to be in when you ask for a larger budget — and a far easier thing to defend in an audit.

Insist on ownership in writing

Here's the question that separates a real custom-software engagement from a dressed-up subscription: when the final invoice is paid, who owns the code?

With most SaaS vendors, the answer is "not you, ever." You're renting. If they raise the price, get acquired, or sunset the product, your options are limited and your data may be hard to extract.

A proper custom build should hand you the source code, the data, and the intellectual property outright. We write that into the statement of work: on final payment, the public body owns 100% of what was built. No per-seat fees, no licence that can be revoked, no lock-in. That's the Own It model, and for public bodies it's not just cleaner commercially — it's easier to justify to council, to a board, or to a finance committee, because you're buying an asset, not signing up for a liability that renews forever.

Ask for these specifics in writing:

• Source code ownership transfers on final payment.
• Data export is available at any time, in an open format, at no charge.
• Hosting can move to your environment or a Canadian-hosted provider you approve.
• No mandatory ongoing fees to keep using what you paid to build.

If a vendor hedges on any of those, you've learned something important before signing.

Build accessibility and bilingual requirements in from the start

For public-facing tools, accessibility isn't a nice-to-have — it's a legal and procurement requirement. Most public bodies are obligated to meet WCAG 2.1 AA, and many also need bilingual English/French support. These are far cheaper to build in from the first line of code than to bolt on after a complaint or an audit.

When you scope the work, name the standard explicitly. A vendor who builds accessible software as a default will treat WCAG 2.1 AA as table stakes; one who treats it as an add-on will surprise you with a change order later. We build to AA as standard and can deliver bilingual EN/FR, with Canadian data residency where it's required — because for the public sector, those constraints are the job, not an upsell.

What "Canadian-hosted" actually buys you

Data residency comes up in almost every public-sector conversation, and for good reason. Depending on your jurisdiction and the sensitivity of the data, you may be required to keep records inside Canada. The practical implication is simple: confirm, in writing, where your data physically lives and who can legally compel access to it. A custom build lets you choose the hosting arrangement that satisfies your privacy office — instead of accepting wherever a global SaaS vendor happens to run its servers.

A realistic path that survives an audit

Put together, the low-pain route looks like this:

1. Scope the first workflow narrowly so it fits your quote-based procurement tier.
2. Run a fixed-price pilot to prove the vendor and the approach with a working tool.
3. Get ownership, data export, and accessibility terms in writing before any larger commitment.
4. If a bigger build is warranted, take it to competitive procurement — now backed by a delivered pilot and hard numbers, which makes the whole process defensible.

None of this requires you to gamble a six-month RFP on a vendor you've never worked with. It lets you start small, prove it, and scale the commitment to the evidence.

We do this kind of work for public bodies — fixed-price, accessible, Canadian-hosted, with ownership that transfers to you. If you want to talk through where your project would fit, book a free 30-minute call or read more about how we work with the public sector. No pitch — just a straight read on what the first useful build would be and what it would cost.