There's a habit in a lot of architectural practices of treating the specification as a single document that gets progressively more complete. You start something at Stage 3, add to it at Stage 4, and issue it when the drawings are done.
 

It's an understandable way to work. It's also the reason so many specifications arrive at tender carrying assumptions nobody has revisited since they were provisional.
 

An outline specification and a tender specification are not the same document at different levels of completeness. They're written for different readers, for different decisions, and they carry different kinds of risk. Understanding that distinction is one of the more practical things a practice can do to reduce late-stage surprises.

Here's what each stage actually needs.

Stage 2 — Concept Design: Establishing Intent, Not Products

Very few practices write anything resembling a specification at Stage 2, and for most projects that's reasonable. But there is value in capturing design intent in writing early, even informally.
 

At this point you're not specifying products. You're establishing the parameters that will constrain product selection later: performance ambitions, sustainability targets, any client or planning requirements that will narrow the field, and the procurement route if it's already known.
 

What's worth recording:

  • Client requirements that carry specification consequences (BREEAM targets, net zero commitments, specific durability or maintenance expectations)
  • Planning conditions likely to affect materials — particularly on heritage or sensitive sites
  • The likely procurement route, because it shapes everything downstream
  • Any performance standards the client has mandated

Why it matters: Decisions made at Stage 2 quietly foreclose options at Stage 4. Writing them down means the specification later reflects actual project requirements rather than being reverse-engineered from a drawing set.

Stage 3 — Spatial Coordination: The Outline Specification

This is where the outline specification properly belongs, and where most practices leave it too late.
 

An outline specification describes systems and performance requirements without necessarily naming products. It tells the reader what the building needs to do and how it's broadly constructed — external wall build-ups, roof systems, structural approach, key performance criteria — without committing to a named manufacturer for every component.
 

Who reads it: the client, the cost consultant, and increasingly the wider design team. A cost consultant cannot produce a meaningful Stage 3 estimate from drawings alone. The outline specification is what turns a drawn build-up into a costable one.
 

What a good outline specification does:

  • Describes systems and build-ups with enough clarity to be priced
  • States performance requirements — thermal, acoustic, fire, structural, weathertightness
  • Flags where design responsibility is likely to sit with a specialist contractor
  • Identifies which elements remain open decisions and which are fixed
  • Aligns to the procurement route

What it shouldn't do: pretend to certainty it doesn't have. An outline specification that names specific products across the board, when those decisions genuinely haven't been made, creates a false impression of resolution. Everyone downstream then treats provisional choices as settled.

The common failure: producing no outline specification at all, then discovering at Stage 4 that the cost plan was built on assumptions nobody in the design team ever made or agreed.

Stage 4 — Technical Design: The Tender Specification

This is the document contractors price against and build from. Its audience changes completely — you're no longer writing for your client and cost consultant, you're writing for a contractor who will read it adversarially, and for subcontractors who will read only the sections relevant to them.
 

That shift in audience changes how it needs to be written.

What the tender specification must resolve:
 

Design responsibility, explicitly. Which elements are contractor-designed portions, and precisely what performance criteria apply to them. Ambiguity here is where variation claims originate. "Contractor to design" without defined performance requirements transfers responsibility without transferring the information needed to discharge it.

Product selection, or a defensible basis for substitution. Where you've named a product, is it genuinely required, or are you open to equivalents? "Or equal and approved" means very little without stating the criteria by which equivalence will be judged. Define what "equal" means for that item — the performance attributes that actually matter.
 

Workmanship and standards. Which British Standards, Building Regulations approved documents, and industry codes apply. This is the section most likely to be copied forward from a previous project and least likely to be checked for currency.

Interfaces. Where one system meets another is where most site problems occur. The tender specification should make interface responsibility explicit rather than leaving it implied.
 

Coordination with drawings. The specification and drawings must not contradict each other. Where they do, the contract usually determines which prevails — and the practice usually finds out which under pressure.

Stage 5 and Beyond: Not the Time to Be Writing

By Stage 5 the specification should be doing its job, not being finished. What happens here is administration of what's already been written: reviewing contractor proposals against specified performance criteria, assessing substitution requests, and responding to technical queries.
 

If substantive specification writing is still happening at Stage 5, something has gone wrong earlier — and it's being resolved under time pressure with contractors already on site.

Performance vs Prescriptive: A Decision at Every Stage

Running underneath all of this is a choice that recurs constantly: do you specify what it must achieve, or what it must be?
 

Prescriptive specification names the product or system. You get certainty over exactly what's installed, and you carry the design responsibility for whether it performs.

Performance specification states required outcomes and lets the contractor or specialist propose a solution. You transfer design responsibility, but you accept less control over the final selection.
 

Neither is correct in general terms. Most specifications use both, and the skill is knowing which to apply where.
 

A rough heuristic: prescriptive where appearance, client preference, or critical compatibility matters, and where you have the expertise to stand behind the choice. Performance where a specialist genuinely knows more than you do — curtain walling, complex M&E, proprietary systems — and where you want that expertise engaged rather than constrained.
 

The mistake worth avoiding is using performance specification as a way to avoid making difficult decisions. Contractors recognise that quickly, and it usually returns as a query or a claim.

How Procurement Route Changes Everything

The same project produces different specifications depending on how it's procured, and this is routinely underestimated.
 

Traditional procurement: the design is largely resolved before tender. The specification tends toward prescriptive, with design responsibility sitting with the design team. It needs to be more complete at tender than under other routes.
 

Design and Build: substantial design responsibility transfers to the contractor. Your specification becomes a requirements document — and how tightly you write it determines how much control you retain. Employer's Requirements that are vague get Contractor's Proposals that are convenient.
 

Two-stage tendering: the specification develops alongside contractor input. This works well when the process is managed deliberately, and poorly when the specification is simply left unfinished on the assumption that the contractor will resolve it.

Writing a specification without clarity on procurement route is writing it for a project that may not exist. It's one of the first questions worth settling.

A Practical Stage-by-Stage Checklist

Stage 2: Record client requirements, sustainability targets, and planning constraints that carry specification consequences. Confirm the likely procurement route.

Stage 3: Produce the outline specification. Describe systems and performance criteria clearly enough to be costed. Identify where design responsibility will sit. Mark open decisions as open.
 

Stage 4: Develop the tender specification. Resolve design responsibility explicitly. Define substitution criteria. Verify standards are current. Coordinate against drawings. Make interface responsibility clear.
 

Stage 5: Administer, don't write. Review proposals against specified criteria and handle queries.

Where Specification Consulting Helps

Most practices know all of this. The gap is rarely knowledge — it's capacity. Specification writing is detail-intensive work that competes directly with design deadlines, and it's usually the task that gets compressed when something else is due.

That compression is where the risk enters: outline specifications that never get written, tender specifications assembled in a fortnight, standards carried forward from an old project without checking.
 

At SpecStudio, we prepare specifications at any stage of the design process — outline or tender — and tailor them to the project's procurement route, design responsibility split, design intent, material selection, and sustainability requirements. Our experts also check that your drawings carry the appropriate level of information to support what the specification says.
 

Working with us functions much like having your own in-house specification consultant. We bring the knowledge and experience, but you have the final say on what constitutes your specification — and whatever you decide, we work to make sure it's complete and aligned to the project's requirements.

Practices with different levels of need can review our service tiers, which scale from a basic specification through to a comprehensive design package.

Final Thought

The most useful shift a practice can make is to stop thinking of the specification as a document produced at the end of design, and start treating it as a parallel discipline that develops alongside it.
 

Outline at Stage 3. Tender at Stage 4. Administration at Stage 5. Each written for its actual purpose and its actual reader.
 

Practices that work this way spend noticeably less time answering contractor queries — because the questions were resolved before anyone was standing on site waiting for an answer.
 

Need support with specification writing at any RIBA stage? SpecStudio's specification consulting and writing team supports architectural practices across the UK and internationally, working in CAWS, Uniclass and CSI MasterFormat.

Get in touch to discuss your project.