Build - Productised Elements¶
The Model¶
- Build is computed, not tiered. Priced at Cornerstone confirmation from four confirmed inputs: the surface inventory split into templates, variants, and tools (2.1); the content model (2.1); the scope table's functional features (2.4); and the integration map with volatility (2.2). The Cornerstone confirms what the sales estimate assumed or highlights what changed - then the counts are the contract, in both directions (growth is priced; an under-count redeploys by default, as in Design).
- The ambition band multiplies UI lines only (System-led 1× · Expressive 1.2× · Premium 1.5×). Design complexity is frontend engineering - Premium set pieces are custom code - but a schema, an integration, and the foundations cost the same at any ambition.
- One inventory, two lenses. Design and Build read the same surface inventory with opposite weightings: variants are heavy in Design (a new frame) and cheap in Build (a prop on a built Roost component); integrations are absent from Design and real in Build. Clients see one consistent inventory across both estimates.
- Acorn and the playbooks are what productise. The foundations line is near-fixed because every build starts from Acorn; standard integrations price low because the playbooks exist. The same instruments-not-hours economics as the rest of the process.
- Stabilisation and internal QA are inside the build price - the alpha promise ("we would demo every feature without apology") is part of Build, not an extra. Client review, user testing, and amends implementation are Validate's cycle line - 20-hr cycles, one per size step - priced on the same estimate so the full journey to launch is visible at Cornerstone time.
How Build Prices¶
Build is computed from the Cornerstone, like Design - no tier menu. The lines read straight off Cornerstone sections:
| Line | Cornerstone source | Scales with |
|---|---|---|
| Foundations | Technical specification | Near-fixed (Acorn) |
| Frontend | Surface inventory (templates · variants · tools) | Counts × the ambition band |
| CMS & data layer | Content model | Content types |
| Integrations | Integration map | Kind and volatility |
The band multiplies UI lines only. Design complexity changes what frontend code has to do (custom animation is engineering); it does not change a schema, an integration, or the foundations - those price band-free. Stabilisation and internal QA live inside the line rates (that is how the calibration actuals were logged); the UAT & amends line (20-hr cycles, one per size step) belongs to the Validate chapter and appears alongside on the estimate.
Design and Build read the same surface inventory with opposite weightings: variants are heavy in Design and cheap in Build (a new frame in Figma; mostly a prop on a built Roost component); integrations are absent from Design and real in Build. One inventory, two lenses - and the same contract: growth beyond the confirmed counts is a priced variation with the Decider, never absorbed.
Indicative Price Grid¶
The public face of the computed model - real projects price from their confirmed Cornerstone counts. All + VAT.
| Size | System-led | Expressive | Premium |
|---|---|---|---|
| S | £8,000 | £8,500 | £9,500 |
| M | £14,000 | £15,500 | £17,500 |
| L | £21,000 | £23,500 | £28,000 |
| XL | from £34,000 | from £39,000 | from £46,500 |
- Sizes use the same surface bands as Design (S ≤5 · M 6–12 · L 13–25 · XL 26+) and the same representative counts (3 · 10 · 20 · 35 surfaces), each carrying the integration map typical of its size (S 2 · M 2 · L 3 · XL 4); a content-heavy or integration-heavy site prices above its size row - the lines, not the grid, are the price.
- The small rows sit low and the large rows high, because the integration register prices each integration on its own hours rather than a flat per-integration allowance: faceted search and filterable maps cost multiples of a consent banner, which the flat figure averaged away in both directions.
- The UAT & amends line (5.3) appears alongside - see the Validate effort model.
- Volatile or custom APIs carry their 2.2 risk allowance explicitly.
- XL is always quoted bespoke from the actual counts.
Validation Against Shipped Builds¶
Fitted against the same five sites as the Design model - build hours including internal QA, excluding client review/amends and content population:
| Site | Band | Computed | Actual |
|---|---|---|---|
| CDSDS | System-led | ~169h | 180h |
| Tracsis | System-led | ~275h | 290h |
| Concurrent | Expressive | ~201h | 190h |
| Source EV | Expressive (high) | ~245h | 250h |
| Into Games | Premium | ~265h | 300h (new-team skew) |
The UAT cycle allowance sits deliberately below the same sites' uncapped amend history (30 / 130 / 60 / 90 / 70h) - the severity gates and capped windows are what hold it. The market anchors bracket the grid: Focused £10–15k ≈ S, the £15–30k Standard anchor ≈ M, Complex £30–60k ≈ L and the XL floor.
Selling Notes¶
- The overlap is the speed story. Foundations and the stable schema exist before the first template is signed; frontend trails design batches by design. "Design finishes, then build starts" is the competitor's timeline, not ours - and delivery speed is the proof our market understands (touchstone §14).
- Sell alpha as a promise, not a milestone. Full functional scope, internally QA'd, budgets met - demonstrable before real content lands.
- The inventory next to the price, always - the same surface inventory the Design estimate carried, plus content types and the integration map. That consistency is what makes variations a number, not a negotiation.
- "+ VAT" always stated.