Government RFPs are how you should write every spec

Engineers tend to groan at the mention of public-sector procurement. The forms, the page limits, the rubrics, the explicit evaluation criteria — it all reads like a parody of slow, risk-averse process. Then you spend a few years building inside provincial governments in BC and Alberta and a heretical thought sets in: this is what good specs actually look like.

I am not arguing startups should write 80-page RFPs. I am arguing that most startup PRDs are bad in exactly the ways public-sector procurement forces you to fix.

1. The rubric forces clarity

A real RFP tells you exactly how a response will be scored. "Demonstrate the proposed approach to capacity building. Minimum score 28 of 40." That's not bureaucratic noise. That's the buyer telling you, in writing, what they actually care about and how they'll measure it.

The startup analogue would be: every PRD ends with a section called "How will we know this is done well?" with measurable success criteria. Not "users are happy." Not "engagement goes up." Specific, falsifiable claims, written before any code is shipped. Most teams don't do this. Government procurement does, because it has to.

2. Acceptance criteria have teeth

In government contracts, "accept" is a contractual event. Someone signs. Money moves. That changes the conversation about scope: ambiguity isn't a discussion to have later; it's a defect now. If acceptance is "the page renders," you've left every interesting question on the table — accessibility, browser support, performance under load, what happens at zero/one/many records. A good public-sector spec answers all of those before the kickoff call ends.

Apply this to your private-sector work and the conversation shifts. "Done" stops being a vibe. It becomes a checklist a stranger could verify.

3. Non-functional requirements are non-optional

Accessibility, security, privacy, performance, localization, audit trails, disaster recovery — government RFPs ask about all of them, explicitly, with minimum bars. Most startup specs treat these as someone-else's-problem until they aren't.

The discipline isn't "do all of these to gov-grade." It's "name which ones apply to this project, and name the bar." A consumer app may decide WCAG AA isn't a launch blocker. Fine — but write that down as an explicit decision, not as an absence. Silent assumptions about non-functionals are how projects die two months in to "we have to rebuild it for the security review."

4. Knowledge transfer is a deliverable

Public-sector contracts routinely require knowledge transfer, runbooks, documented architecture decisions, and post-engagement maintainability by the buyer's staff. The implicit assumption is that the vendor will be gone someday, and the system has to survive that.

Now consider the average startup codebase, where the only documentation is in the head of the engineer who quit last quarter. Treating knowledge transfer as a first-class deliverable — not a thing you do "when there's time" — is one of the highest-leverage habits an engineering org can pick up.

5. The bar for "we have done this before" is evidence

RFPs ask you to demonstrate experience with specific dates, scope, scale, and references. "We are familiar with X" doesn't score. "Between January 2023 and present, we delivered Y at scale Z, here's the contact who can verify it" scores.

This translates directly into how you should evaluate technical decisions internally. "Have we shipped this pattern before?" is a more useful question than "do we like this pattern?" Track the evidence, name the prior systems, be honest about what was different.

What to actually steal

You don't need a procurement framework to apply any of this. A minimum-viable version, on the back of an envelope:

• One paragraph describing the user, the problem, and the measurable outcome.
• Explicit acceptance criteria. Three to ten bullet points a stranger could test against.
• A named list of non-functional requirements that apply, with bars.
• A line about what documentation/handoff exists at the end of this work.
• A pointer to the closest prior work this builds on.

That's it. That's an RFP in 200 words. The shortcut every team thinks they're taking by skipping this work is, on every project I've watched, an expensive detour they take later — with worse information, under more pressure, and usually with less of the original context still in the room.

The actual takeaway

The slowness of government procurement is real. The discipline embedded in it is also real, and most of it earns its keep. The teams that learn to write specs with the rigour of a public-sector RFP — and execute with the speed of a startup — are the ones that ship things that last.