Build - Effort Model (Internal)¶
Never client-facing. A living model, fitted against five shipped MAJOR builds (see Calibration flag 1). Like Design, this is computed - price per project from the Cornerstone's confirmed counts through the line rates below.
Assumptions¶
- Conventions: website-pricing.md § Effort-Model Conventions (P here is the lead; M, engineering mid). Expected mix: 15:85 P:M chapter-wide - System-led 12 · Expressive 15 · Premium 20 (the band moves UI engineering only). Observed across five builds: 15%, range 9–20% - the assumption survives contact with the data.
- Pricing basis: computed estimate at rate card - the rates carry the margin; the Cornerstone's counts are the contract, in both directions (growth is priced; an under-count redeploys by default, as in Design).
- The calibration actuals include fix-as-you-go stabilisation and the internal QA pass to alpha. They exclude client review, user testing, and amends implementation (the Validate cycle line, below), and content population (Validate).
- Inputs come fixed from the Cornerstone: surface inventory split into templates / variants / tools (2.1), content model (2.1), scope table (2.4), integration map with volatility (2.2), ambition band (sold; confirmed at 2.3).
- Assumes Acorn is current - it is what makes the foundations line near-fixed.
- Excludes cross-cutting Management (PM/AM).
The Lines (the Surface Spine)¶
Build reads the same surface inventory Design prices, with its own rate column - one count at 2.1, two lenses, opposite weightings:
| Inventory item | Design rate (per surface) | Build rate |
|---|---|---|
| Template | 5.5 / 7 / 10.5 hrs by band | 8 hrs × UI band multiplier |
| Named variant | same as template | 2 hrs - a prop on a built Roost component |
| Interactive tool | same as template | 10–20 hrs by screens/states |
Plus the non-surface lines:
| Line | Rate | Band multiplier |
|---|---|---|
| Foundations: setup (Acorn, repo, hosting, CI/CD, stack ADRs) | ~14 hrs near-fixed | - |
| Frontend: the master UI (tokens + the component library) | the balance of the surface spine - see below | × 1 / 1.2 / 1.5 (SL / EX / PR) |
| Frontend: per template assembled from the master UI | 8 hrs, less its master-UI share | × 1 / 1.2 / 1.5 (SL / EX / PR) |
| Frontend: per variant | 2 hrs | same |
| Frontend: per tool | 10–20 hrs by screens/states | same |
| CMS & data layer: per content type | 4 hrs | - |
| Integrations (per the register below) | design 0–12 · build 4–28 hrs | - |
| Custom integrations | design and build hours entered per engagement, + the 2.2 risk allowance where volatile | - |
| Bespoke functional features (from the scope table) | scoped, tool-scale allowances | UI face only |
The Integration Register¶
Named integrations carry their own figure rather than a single standard rate: "forms" spans a fixed contact form and a client-facing form builder, and one number cannot hold both. Anything not named here is a custom integration at the standard or volatile rate above. Volatility is a property of custom lines only - naming and pricing an integration is the act of de-risking it, so a named line is by definition understood. A volatile or custom API remains an XL driver at 2.2 regardless of count.
| Integration | Design | Build | Scope |
|---|---|---|---|
| Analytics and consent | 2 | 4 | Analytics install, event and conversion tracking, consent platform wired to consent mode. Design is theming the consent banner, not drawing one |
| Forms: native, fixed | 4 | 8 | Built by us and selectable by the client: form UI, validation, spam protection, submission endpoint, notification, success and error states |
| Forms: native, client-created | 4 | 18* | The client composes forms in the CMS. Priced because clients ask for it; discouraged, because it hands editors a footgun and the output drifts from the design system |
| Forms: platform integration | 4 | 24* | An external forms platform such as Typeform: the vendor owns the definition, we fetch, render, and post back |
| CRM form submission | 0 | 8 | Our native form posts to the CRM: auth, field mapping, contact create-or-update, dedupe, failure handling. No design: the form itself is already designed under its Forms line |
| CRM form output | 4 | 20 | Form definitions fetched from the CRM, rendered in our components, submitted back. The same shape as the platform line; 4 hrs cheaper to build because the HubSpot and CRM playbooks exist |
| Email platform contact submission | 2 | 8 | Mailchimp or Klaviyo: auth, audience and tag mapping, double opt-in |
| Search: simple | 6 | 16 | Index config, indexing pipeline on publish and unpublish, search input and results UI, relevance and synonyms. Design covers the input, results, empty, no-results and loading states |
| Search: faceted | 12 | 28 | The above plus facet configuration, refinement UI, URL state sync, sorting, multi-index or federated search. Design adds the facet panel, applied-filter chips, sort control and mobile filter drawer |
| Gated downloads | 3 | 6 | Gate, access token or session, signed file delivery, download tracking. Requires a form line: it is access control layered on a form, never standalone |
| Maps: single pin | 1 | 4 | Key, embed, one marker, brand styling |
| Maps: multiple pins | 4 | 12 | CMS-driven locations, markers, info windows, clustering |
| Maps: filterable | 10 | 24 | The above plus filter UI, category or region filters, list-and-map sync. Design covers the filter UI, the list-and-map layout and its mobile behaviour |
| External data source | 0 | 10 per source | Auth, fetch, normalise into the content model, caching and revalidation, error and stale handling, scheduled sync. No design: the data renders into surfaces already designed |
| Custom integration | entered | entered | Design and build hours set per engagement, because custom work varies too widely for a standing figure. Mark it volatile where the API is volatile or custom: that is the 2.2 XL driver and what carries the risk allowance |
*Unvalidated: see Calibration flag 8.
Forms, CRM, Search and Maps are single-select: a project takes one row from each, and where a tier ladder applies the higher tier includes the lower. Search is named by capability rather than by vendor, so Algolia, Typesense, or Meilisearch all price the same.
A named integration is never also a surface. Its design and build hours are here in full, so counting a search results page, a store locator or a gated library again in the surface inventory prices the same work twice. The surface inventory carries templates, named variants, and set pieces that no integration covers: calculators, configurators, quizzes, bespoke visualisations. Design hours here do not take the ambition-band multiplier, on the same reasoning as build: they join the Design chapter's hours before its P:M split, but are not multiplied by the per-surface rate.
Validate's companion line (priced on the same estimate, owned by 5.3 UAT): client review, user testing, and amends implementation = 12 hrs per cycle (S 1 · M 2 · L 3 · XL 5)
- £1,500 per cycle at the Validate cycle line's 25:75 mix.
Notes:
- The band multiplies UI lines only. Design complexity is frontend engineering (Premium set pieces are custom code); schemas, integrations, and foundations cost the same at any ambition.
- Variants are cheap to build and expensive to design - the same surface inventory drives both models with opposite weightings.
- Stabilisation and internal QA are inside the line rates, per the calibration basis. No separate 4.5 line.
Indicative Grid (Computed from the Lines)¶
Representative counts per size: S 2T/1V, 3 types, 2 integrations · M 5T/5V, 8 types, 2 integrations · L 9T/10V + 1 tool, 8 types, 3 integrations · XL 16T/17V + 2 tools, 12 types, 4 integrations.
These are the single representative set, shared with Design's effort model and both pricing grids: 3 · 10 · 20 · 35 surfaces. A figure quoted for a size means the same shape everywhere. Each row sits at its band's representative count, not its floor - an L at 21 surfaces prices well below the L row.
| Size | System-led | Expressive | Premium |
|---|---|---|---|
| S | ~68 hrs · £8,000 | ~72 hrs · £8,500 | ~77 hrs · £9,500 |
| M | ~120 hrs · £14,000 | ~130 hrs · £15,500 | ~145 hrs · £17,500 |
| L | ~180 hrs · £21,000 | ~200 hrs · £23,500 | ~230 hrs · £28,000 |
| XL | from ~292 hrs · £34,000 | from ~329 hrs · £39,000 | from ~383 hrs · £46,500 |
All + VAT; XL always quoted bespoke. Real projects price from their actual Cornerstone counts through the lines - the grid is indicative. S and M moved down and L and XL up when the integration register replaced the flat per-integration allowance: the register prices faceted search and filterable maps at several times a consent banner, which the flat figure averaged away in both directions.
Calibration Flags (the Important Part)¶
- Fitted against five shipped builds: | Site | Band | Computed | Actual | Delta | |---|---|---|---|---| | CDSDS | SL | ~169h | 180h | −6% | | Tracsis | SL (incl. ~25h IR feature allowance) | ~275h | 290h | −5% | | Concurrent | EX | ~201h | 190h | +6% | | Source EV | EX (incl. calculator, map, form flows, flow-system build) | ~245h | 250h | −2% | | Into Games | PR | ~265h | 300h | −12% | Into Games' gap is a known skew - new team members on that build - so the Premium multiplier (1.5×) leans on a discounted single observation: treat it as provisional.
- The Validate cycle line is a deliberate cap, not a fit: the cycle allowance (20 hrs × size step: S 20 · M 40 · L 60 · XL 80) sits below the historical actuals (30 / 130 / 60 / 90 / 70h), which contain uncapped amend behaviour. The severity gates and capped windows are what make the allowance hold. The Build/UAT boundary (amends implemented in UAT) is current practice and can move - if it does, the line moves chapters, not price.
- Band multipliers (1 / 1.2 / 1.5, UI lines only) are fitted, not observed per band - calibrate against line-level actuals.
- Bespoke allowances are the model's judgement seam. Tracsis's IR features, Source's form flows and flow-system build - these are read from the Cornerstone's scope table as tool-scale allowances. Log every allowance explicitly on the estimate so the seam calibrates rather than leaks.
- Line-level capture, lead engineer, sprint hygiene - actuals logged in this model's line format, reviewed at chapter close; the house build-time metrics fall out as a by-product.
- Foundations is setup; the master UI carries the build. Foundations is ~14 hrs - repo 6, hosting and CI/CD 4, architecture and stack ADRs 4 - and the weight sits in the master UI, the tokens and component library the templates are then assembled from. Setup is a small part of engineering; master template development is the rest, which is Acorn working as the margin lever it is meant to be. This split is argued, not measured. The five calibration builds were logged with a heavier foundations line and a lighter frontend one, and both readings come to the same chapter total, so nothing in the price depends on which is right. What depends on it is where actuals get logged. Capture at this line split on the next build and confirm it. Drift in Acorn shows up here first.
- Prices are hours × rate card rounded to a clean number, as Design. Margins and internal figures live here and nowhere else.
- Two integration figures are unvalidated. Forms: platform integration (24 hrs) and Forms: native, client-created (18 hrs) are estimates with no shipped actuals behind them. Capture per-line actuals on the first engagement carrying either, and revise the register. Every other figure is anchored on either a shipped rate or a live playbook, and the 4-hour gap between CRM form output and the platform line is precisely the value of a playbook: build a platform playbook and that line should fall to 20.