Procurement is a design constraint, not paperwork

A tender arrives as a PDF with numbered clauses, a submission portal and a deadline. It goes to the bid team. That is where most of the trouble starts, because a good third of the architecture is already written into the schedules, and the engineers who will have to honour it are usually reading the document for the first time after the contract is signed.

One clause says citizen data must remain inside national borders. Another says any change to a record must be reconstructable for seven years, including who authorised it. A third says the platform must be operable only by staff holding a particular clearance. A fourth, buried in the exit schedule, says that at contract end the buyer receives everything a different supplier would need in order to run the system. None of those is administrative. Each of them lands on the design, and each is far cheaper to accept in week one than in month nine.

The schedules are an architecture document in disguise

Public procurement writes requirements in the language of obligation rather than the language of systems, which is why engineers skim it. "The supplier shall ensure that all transactions are traceable to an authenticated individual" is a sentence about identity, session management, service accounts and every batch job you were planning to run under a shared credential. "The system shall be available during published service hours" is a sentence about rotas, escalation paths and which of our delivery centres carries the account.

Two more clauses surprise teams consistently. An accessibility standard named in a schedule is a conformance obligation testable by a third party, and it constrains the component library before anybody has chosen one. A requirement to serve a second official language is a decision about layout, content workflow and every document the system generates, taken at the start or paid for twice.

We now read the schedules with an architect in the room before we price anything. It is slower, and the bid team does not enjoy it. It has also stopped us bidding a design the contract would have made impossible to deliver.

Where the data sits decides who is allowed to look at it

A residency clause usually gets read as a hosting question and answered with a region name. The harder half is operational. If production data cannot leave the country, then neither can the people who debug production, nor the screen share they are sitting in, nor the log extract someone took at four in the morning to reproduce a fault. Support tooling, log aggregation, error reporting SDKs and crash dumps all move data across borders by default, and the default destination is usually somewhere else.

So the clause settles an operating model as well as a deployment target. We run engineering and delivery from New Delhi and corporate operations from Mississauga. A residency clause with a personnel condition attached can decide which centre carries an account, how the on-call rota is constructed, and whether follow-the-sun cover is available at all. Those are cost lines. They belong in the price, and they cannot be added afterwards without a variation.

Audit is a feature with a schema

Most systems store the current state of a record plus a timestamp for when it last changed. Most audit obligations require something else entirely: the sequence of changes, the actor behind each one, the authority that actor was acting under, and enough context to explain why the change was reasonable at the time. Those are different data models. The second cannot be reconstructed from the first after the fact, which is why retrofitting audit is the single most expensive late change we see in public sector work.

The usual retrofit is a trigger on every table writing before and after values into a shadow schema. It produces an enormous amount of data and satisfies nobody, because the auditor's question is rarely "what changed". It is "who decided this, on what basis, and were they permitted to". Answering that requires the decision to exist as a first-class event, recorded at the moment it was made, with the rule version, the inputs and the approver attached to it. If the domain model has no concept of a decision, no amount of table logging will invent one.

Settling this before the tender closes costs a design session. Settling it in month nine costs a rewrite of every write path in the system.

Security review runs on a calendar you do not own

In a commercial programme, security testing is something the team schedules. In a public programme it is a gate, with a queue, an owner outside the delivery organisation and a mandatory document format. Penetration test slots get booked months ahead. Findings come back with a remediation window and a retest that rejoins the same queue. A design authority may require an architecture pack in a specific template at a specific stage, and may decline to review code written against a design it has not yet seen.

There are two practical consequences. The review dates go on the plan as fixed points, and the build gets sequenced around them rather than the other way round. And the pipeline itself is in scope: organisations with a formal security boundary often require builds to be produced and signed inside it. A CI setup pulling dependencies from the open internet onto a shared runner is a finding, and rebuilding it inside a controlled environment in month eight is a month of work nobody quoted.

We run security review inside each delivery cycle rather than as a phase before release. That comes from scar tissue rather than from any attachment to a methodology. It is the only arrangement we have found that stops a formal gate becoming a three-month stop.

Integration counterparties you cannot instruct

An annex will list "integration with existing departmental systems" as a single line, occasionally with a count next to it. That count is the least useful number in the document. What matters, for each counterparty: which protocol and which version, who owns it, whether a test environment exists, how a change on their side is requested, and how long that request takes. The answer to the last one, in our experience, ranges from a fortnight to never.

Integration is usually the largest single item in an enterprise programme, and we scope it explicitly rather than folding it into contingency. On public work we also ask, before bidding, which counterparties have a non-production environment we can actually reach. With nothing to test against on their side, the integration becomes a rehearsal you get to perform once, in production, on a Saturday.

The exit clause is a design brief

Near the end of most public contracts sits an obligation to hand over, at the end of the term, everything a successor supplier would need to operate the system. Read as engineering rather than as legal risk, that clause forbids a whole category of decisions: the undocumented deployment step, the credential that lives in one person's head, the build that only works on one machine, the integration whose behaviour is described nowhere except in the code that calls it.

Our interest is aligned with that clause anyway. The firm's position is that the people who build a system are the ones answering the phone about it years later, and the artefacts an exit obligation demands are roughly the artefacts we would want if we inherited the thing from somebody else. Writing the runbook during the build rather than at handover is the practical version of complying with it.

What we settle before the tender closes

• Where data lives at rest, in transit and inside the support tooling, and which staff are permitted to see production.
• What the auditing body actually asks for, in its own words, and whether the domain model can answer it.
• Who authenticates users, whether that identity provider already exists, and what the service does while it is down.
• Every security gate: who owns it, what evidence it requires, and the earliest date it can be booked.
• The exit obligation, read as an engineering requirement rather than a legal one.
• Which integration counterparties have a reachable test environment, and which do not.
• Retention and deletion at contract end, which is a constraint on the storage layer from day one.

Settling those requires no knowledge of the eventual solution. What it requires is a clear view of the constraints that solution has to live inside, which is a different and much earlier piece of work than design.

Priced honestly, it looks expensive

A tender is the last cheap moment to change the architecture. After it closes, every change arrives with a variation order attached.

Bids that treat these clauses as paperwork come in lower, and sometimes they win. The difference reappears in year two as change requests, remediation work and an availability figure nobody wants to publish. We have lost work on price to that arithmetic. We have also inherited the result of it more than once, which is a less pleasant way of being proved right.

The paperwork framing survives because procurement and engineering sit in different rooms and read different documents. The correction is unglamorous. An architect reads the schedules before the bid team writes the response, marks the clauses that change the design, and prices them as work. That meeting takes an afternoon, and it is the highest-return afternoon in a public sector programme.