How a Small, Read-Only Assessment Fits Normal Public-Sector Purchasing Policy

If you work in a municipality, a health authority, a school district, or any public body, you already know the problem. There is a system that cannot be left alone and cannot be replaced this year, and nobody has an honest written answer about what it would take to keep it running. The moment you say "custom software" someone hears "a multi-year commitment," and the question stalls.

It does not have to start there. The first useful step is small: a read-only condition assessment of one system, producing a written report. That is an ordinary operating purchase, and the point of this post is to show how it fits inside the purchasing policy you already have, whatever your policy requires.

Start by being honest about the size of the buy

Every public body's purchasing policy scales its process with the dollar value and the nature of the purchase. The numbers and the rules are set by your bylaw, your policy, and the trade agreements that apply to you, not by any vendor. The first honest question is therefore not "how do we get around the process" but "what, exactly, are we buying, and what does our policy say about a purchase of that size and kind?"

The mistake teams make is assuming "custom software" automatically means the whole five-year vision has to be bought at once. It does not. A read-only assessment of one existing system is a small, fixed-price professional service that produces a written report. It is an operating expense, not a capital project, and it is small enough to fit a budget a director already controls. Whether your policy treats it as a direct purchase, a quote process, or something that must be competed is a question for your procurement office, and the right answer is whichever one your policy gives.

Use a small assessment to de-risk the decision

This is the single most useful move available to a public-sector buyer: buy the written answer before you buy the work.

An assessment is a read-only review of one system, delivered for a fixed price, that tells you in writing whether the system should be extended or replaced and what each path would cost. From a procurement angle, that does three things at once:

• It is a bounded, ordinary purchase that your finance and procurement offices can process the way they process any small professional service, by whichever route your policy requires.
• It produces a document your team can actually evaluate and keep, not a slide deck or a reference call.
• It gives you real numbers and a real scope to put in front of a committee, a council, or a competitive process if a larger piece of work does follow.

An assessment turns "we think this system needs work" into "here is the written condition of the system, the options, and a ceiling price for each." 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, because the larger decision is made on evidence rather than on a vendor's pitch.

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-outright 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. For public bodies we deploy in Canadian regions by default, confirmed in writing per engagement, 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 route looks like this:

1. Scope the first purchase narrowly: one system, read-only, a written report, a fixed price.
2. Buy it the way your policy says to buy a purchase of that size, whether that is a direct purchase, written quotes, or a competition. Ask your procurement office rather than the vendor.
3. Get ownership, data export, and accessibility terms in writing before any larger commitment.
4. If larger work is warranted, take it through whatever process your policy requires for that value, now backed by a written assessment and hard numbers, which makes the whole file defensible.

None of this asks you to commit to a vendor you have never worked with. It lets you start small, get the answer in writing, 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 the system in question already exists and the real question is whether to extend it or replace it, that is what a fixed-price application condition assessment answers, in writing, on one system. If it's a new build, send us the requirement or read more about how we work with the public sector. Our registry numbers and pre-qualifications are published if you need them for a vendor file.