Summary
Nine operators need Figma files before development can finish for 1 December. Six are light, three are dark. The base light design system is still being built and the base dark one hasn't started.
There are two ways to do this. Route 1 keeps the current setup: every operator gets its own independent copy of the design system. Route 2 puts the existing components onto a layered token structure, so one central library drives every operator through a brand layer and a light/dark theme layer.
Recommendation: Route 2, at four days a week
Route 1 needs 31–46 days (£15,500–£23,000). There are 21–28 working days before the mid-November design deadline, so it cannot finish in time, and every later change has to be made in eleven files. Route 2 needs 22–30 days (£11,000–£15,000), fits the window at four days a week, and leaves one file to maintain afterwards. It also costs less to maintain once live (see value after launch).
All costs are at £500 per day plus VAT.
What the current design system looks like
Measured directly from the base light Figma file on 25 September 2026.
- There is no theme or brand layer. Colour, type, spacing and radius each sit in one collection with a single mode. Every variable holds a fixed value, and none refer to another.
- Colours are named by what they look like, not what they do. Text-Dark, Shade-Light and Opacity-Dark can't flip for a dark theme without the names becoming wrong. Building dark this way means relinking components by hand, then repeating that in every dark operator file.
- There are duplicates and errors. Three colour variables hold the same green. Two hold the same navy. There is a misspelled variable (Odds-Drifitng) and two separate component sets both called Button-CTA-Primary.
- The good news: most of the work is relinking, not rebuilding. 86% of colour fills already use variables. Footer and Navigation account for almost half of the hard-coded fills.
- The live site doesn't match the design file. proper.bet uses different transparency steps (8, 12, 20, 40, 48, 64, 80%) from the design file (8, 16, 32, 64%). Only two of them line up.
The two routes
Route 1: separate files
Finish base light, duplicate it into base dark, then duplicate again into nine independent operator files.
Estimated design days
£15,500–£23,000 + VAT
Confidence of finishing by mid-November
Pros
- No change to how the current files are set up, so there's nothing new for the team or developers to learn
- Steady output: operators arrive one at a time from week 3
- Each file can be changed without affecting the others
Cons
- Doesn't fit the deadline: about five of nine operators ready by mid-November
- Every fix or redesign has to be made in up to eleven files. This continues after launch, for as long as the platform runs
- Files drift apart over time, and design and code drift with them
- Dark theme means relinking components by hand, in four files
- Operators can't switch between light and dark without a new file
Dependencies
- Base light signed off and frozen before duplication. Later changes have to be copied by hand
- Operator brand colours supplied
- Timely feedback from Playbook
Route 2: one central library
The existing components, relinked to a layered token structure: brand, theme and component-level overrides.
Estimated design days
£11,000–£15,000 + VAT
Confidence of finishing by mid-November
Pros
- Fits the deadline at four days a week
- A fix is made once and reaches every operator
- Dark theme comes from the same components, not a separate build
- Any operator can offer light and dark later, with a small amount of extra development
- Every future sport is designed once and appears for all operators
- Once an operator's brand values are in, setting it up is a few mode switches: brand, theme, typography and radius
- Component names and structure stay the same, so developers see minimal change
Cons
- Slower start: no operator files until about week 5
- Depends on the development team agreeing to the approach and having the capacity to adopt it alongside the 1 December build. If they can't, the design-side savings still apply, but the development savings don't
- A more advanced setup for other designers to learn
- Any components that need redesigning add time on top
- Uses all ten brand slots on the current Figma plan (base plus nine operators). An eleventh operator means upgrading the plan
Dependencies
- Development team agrees the token approach before work starts
- Current Figma plan (ten modes per collection) stays in place
- Edit and publish rights on the library file
- Operator brand colours supplied
- Timely feedback from Playbook
How the output arrives
Route 2 spends its first four weeks on the library, the dark theme and relinking the components. After that, operators take about a day each. Route 1 starts delivering sooner, but each operator costs two to three days, plus the time spent copying changes between files.
Midpoint estimates at four days a week. At three days a week, both lines move right by about a third.
Where the days go
| Work | Route 1 | Route 2 |
|---|---|---|
| Clean up base light: hard-coded fills, duplicate variables and components | 3–4 | Included in relinking |
| Token structure: brand layer for nine operators, theme layer, overrides | — | 4–5 |
| Relink all 103 component sets to the new tokens | — | 5–7 |
| Base dark theme | 6–8 | 2–3 |
| Operator files: 9 at 2–3 days (Route 1) or 1–1.5 days (Route 2) | 18–27 | 9–13.5 |
| Copying base changes across files during the build (seven weeks) | 4–7 | — |
| Token handover for developers | — | 2 |
| Total design days | 31–46 | 22–30 |
| Cost at £500 per day + VAT | £15,500–£23,000 | £11,000–£15,000 |
Weekly spend is £1,500 at three days a week or £2,000 at four, plus VAT.
How the central library is built
Each layer only refers to the one below it. That's what lets one set of components serve every operator, in light or dark, without copies.
Operator screens sit in their own files and use the library. Switching an operator from light to dark is a setting on the file, not a rebuild.
Value after launch
The launch estimate is only part of the picture. The bigger difference is what every change costs once nine operators are live.
| After launch | Route 1 | Route 2 |
|---|---|---|
| Fixing one component | Made in up to 11 files | Made once |
| New components or market templates | Designed once, then copied into 10 more files and checked in each operator's colours | Designed once, available to every operator |
| A new operator | 2–3 days, and every future change now reaches one more file | Add its brand values, then a few mode switches: brand, theme, typography and radius |
| Light or dark for an operator | A new file | A setting on the file |
| Consistency | Files drift apart over time, and design and code drift with them | One source. Operators differ only by brand values |
| Development | Each operator's build is checked against its own file | Operators are checked against one set of components |
Where this leads: operator branding as data
Route 2 sets up the ideal long-term workflow. Each operator's brand values (colours, fonts, radius and overrides) are exported from the library as one JSON file per operator. Development points each operator's site at its file. When a brand changes, design updates the library, exports a new file and hands it over. There's no rebuild, and no reading values off a design.
- Design owns the brand, development owns the build. A clear line between the two teams.
- What's designed is what ships. Values are never retyped, so they can't drift.
- New operators are faster on both sides. A new brand is a new file, not new code.
For this to work, three things have to be agreed with development. The token names become a fixed contract, so renaming one needs both teams to agree. Brand files go through a review step before they reach the live site. And this covers brand values only; changes to layout or components still go through the normal design and build process.
If development doesn't adopt the tokens
Route 2 still pays off. The design team maintains one library instead of eleven, and every operator file shows the exact values for that operator. Development can keep reading the designs the way they do now. Adopting the token names is what brings the development savings, but it isn't required to start.
Route 2 plan
- Agree the approach with developmentWeek 1. One session to confirm how themes are built in code and match the tokens to it.
- Set up the token structureWeeks 1–2. Brand, theme and override layers. The current 32 colours mapped to their roles.
- Relink the componentsWeeks 2–4. Fix the 558 hard-coded fills, merge duplicates, and check every component set in light and dark.
- Build the operator filesWeeks 5–7. Adapt each operator's colours to the new roles, starting with proper.bet as the reference.
- Hand overWeek 7. Token documentation for developers, plus a guide for adding future operators.
Decisions needed to start
- Which route, and at three or four days a week.
- A session with development in week 1 to go through the questions below.
- All nine operators' current brand colours, fonts and logos.
- Who signs off the library and each operator file on Playbook's side.
Questions for development
The live site is built with Emotion, a styling library usually paired with React. It has no CSS variables, so its colours appear to come from a theme set in code, but the structure of that theme can't be seen from outside. Before committing to Route 2, we need answers to these.
- Is there one theme per operator in code? If so, what are its keys, and could we see one?
- Do you use design tokens or variables exported from Figma, or build by reading the designs?
- How much work would it be to map the new token names onto your theme keys?
- Is supporting light and dark for the same operator possible later, and roughly how much extra work would it be?
- Which transparency steps should be correct: the ones in code or the ones in the design file?
- Could each operator's theme load from a JSON file supplied by design? What format would you need?
What this estimate assumes
- The day counts cover my time only. The outsourced team's designer works separately and isn't counted here.
- Operator files are re-branded copies of the design system with minor customisations. Screen design isn't included.
- Operator brand colours need adapting to the new roles; for example, the primary colour currently fills the header background.
- Component redesigns are extra and would be estimated separately.
- Designing sports phases 2–6 is not part of this estimate.
- The 103 component sets in the file today are the full scope for launch.
- Day rate £500 plus VAT.
- The design deadline is Friday 13 November, with work starting Monday 28 September.