Procurement is a design constraint, not paperwork
A tool that cannot be bought by a district office will never reach a district, however good it is.
Engineers treat procurement as an administrative afterthought. In public-sector deployment it is closer to a load-bearing wall. A system that requires a recurring licence, a foreign payment gateway, or a cloud region nobody has cleared will stall in a file for two years and then quietly lapse.
The constraint is specific and learnable. Recurring costs need a budget head that exists. Data residency needs to be answerable in one sentence. A district officer needs to be able to explain the purchase to an auditor without a technical annexure. Systems that satisfy these move in weeks; systems that do not never move at all.
A tool that cannot be bought will never be used.
This is why we prefer handing over an asset rather than selling a subscription. An organisation that owns the code and the weights has nothing to renew, nothing to justify annually, and nobody to be held hostage by. It converts a procurement problem into a one-time transfer.
It also changes the engineering. Self-hostable by default. Exportable data in formats a successor can read. No dependency that dies if a company does. These are not idealistic choices; they are the difference between a deployment that survives a change of officer and one that does not.
If you are designing for public systems, read the procurement rules before the requirements document. They will tell you more about what is buildable than any stakeholder interview.