01 Overview
Two platforms, one brand, and every section built twice in two codebases.
In 2018 the site looked old, outdated and stale, and responsive was becoming the standard. The brief asked for something simple. What the brand needed was a foundation to stand on: one design language first, then one codebase to carry it, answered in that order.
01.1 The problem
No source of truth for the design, and every section built twice in code.
Each row is a layer: what went wrong, what it cost, and what we did about it.
| What was going wrong | What we did about it | |
|---|---|---|
| Design problem The brand had no identity of its own, and in the first weeks the asks pulled in many directions at once: with no source of truth, there was no clear direction. 3–4 rounds of two to three days each, before a design was final. | A design system built around the brand, and a pipeline every digital visual passes through: a foundational rule to follow while exploring something new. | See the work |
| Engineering problem Every section was built twice, in two codebases, once per platform, and marketing asked for several variations of each: "it doesn't only double the work, probably quadruples it". A change in code hit the whole site, unseen until it was pushed. +2 days of code on every page to rebuild it for the second site, and at least two weekends a month. | One codebase both platforms install, with each site's colours and spacing as settings in its own admin, previewed before they go live. | See the work |
01.2 The timeline
Hired as a designer in 2018. By 2026, a team of four running both platforms on one codebase.
The work grew a layer at a time: the front end two months in, because the client couldn't build the designs; a team in 2024, when the client grew; one codebase in 2025, when a new VP made the call.
- 2018March
Hired as a designer to remake the site, from a post titled "SIMPLE".
- May
The front end added: design, their approval, then code.
- 2019
The second platform joins the work, on its own codebase.
- 2024May
Jake joins on WordPress, Dan on QA.
- June
Dave joins on graphics.
- 2025
A new VP calls the move to one codebase; deployment freezes for 40 days.
- October
The first platform relaunches on it.
- 2026January
The second relaunches, and the messaging changes reach it.
- October
The engagement ends; all four leave together.
01.3 Context
Nobody in-house built pages, and the brief itself split the brand across two codebases.
What the work started from, before any of it was ours to change.
In-house, in 2018
Nobody made pages or visuals, and nobody handled WordPress.
Why two codebases
The brief wanted the second platform aligned with the brand but "not too the same", so it got a codebase of its own. Later, the client wanted the two as alike as possible.
Why we were hired
The higher-ups had complained that the site needed updating, so the head of marketing hired a designer through Upwork: on contract, design only.
Who backed it
The head of marketing, from the very beginning. Every pitch came as the problems first, then our suggestions.
The second platform, before
Each section was rebuilt inside the limits of its own theme: "duplicate and constricted work", aligned to the new design but kept on its old font so the two didn't look disconnected.
One codebase, argued for
We pushed for one codebase for years before anyone who could make the call was there to make it.
02 Design solution
One design language, and a route every visual has to take to get out.
The brief was a refresh. What went back was the full picture of what a brand needs: a design system that settles type, colour and components once, and a pipeline that puts every digital output through it. It outgrew the site: the rest of the product lineup took on its fonts and colours.
02.1 The work
Every screen we're proud of, shown whole.
The designs in one long run that pans as you scroll, shown whole rather than taken apart. The sections after it are how they got this way: the message they carry, the loop that settled them, and the call that shaped both.
02.2 The messaging shift
The order, the look, the information and the navigation changed, and each changed what the brand says about itself.
Sections were put in the order of a story, rebuilt to look and feel new, and the plugin-looking navigation and widgets were rewritten. All four started on the first platform and reached the second with its relaunch.
| Before | After | What it aligned | |
|---|---|---|---|
| Narrative | Ordering sections by what analytics said users cared about, with the brand never saying what it does. | A site that tells a story section to section, explaining what the company does step by step. | What users came for, and what the brand does, on the same page. |
| Standard | Looking like a "normal" brand website. | Sections that look and feel brand new, with updated UX, ready for the standard of the category. | The site with the products and competition it's measured against. |
| Approach | Leaving the information on a page to chance. | An information strategy thought through page by page, so the site feels approachable. | Every page with the story of the whole site. |
| Investment | Running plugin-looking navigation and widgets, so the site read as templated. | Navigation and widgets axed and rewritten as the brand's own. | How the brand looks with how much the company cares how it's seen. |
02.3 The design process
Every design passed their review before code, and the system gave each review a rule to point back to.
Every design went from brief to their review and back for changes before it reached code. In the first weeks the asks kept moving, and each round took two to three days. Once there was a source of truth to refer back to, most designs needed one, and some none.
- Brief
- Design
- Their review
- ReviseBack to 02
- Approval
- Front end
Caught at 03 Their review
A design system: a foundational rule to follow while exploring something new.
The asks pulled each design in many directions; with no source of truth, it took three to four rounds of two to three days before anything was final.
- Review rounds per design
- 3–4 → 1–2
- Who, and where
- Marketing, reviewing every page design from the first weeks of 2018.
02.4 Design decision
They advertised for something simple. We answered the bigger brief.
Taking the post at its word would have meant a better-looking version of the same problem. What went back was the problems, with suggestions as the solutions. That reframing is the call the engagement turned on.
| The call | The easy answer | What we chose | What it cost, and what it bought |
|---|---|---|---|
| What to answer | Take the post at its word: a restyle of the site. | A design system, and a pipeline every digital visual passes through. | More hours up front, and a slower start. Review rounds per design down from 3–4 to 1–2, and fonts and colours the rest of the product lineup took on. |
03 Engineering solution
Two sites, one plugin, and a config that decides the difference.
The front end came two months in, because the designs needed someone who could build them pixel-perfect. Planned like the design: one SCSS file per design component. It ended as a single codebase both sites install, every setting per site.
03.1 The wiring
Everything both sites run on, in one picture.
The build on one page: the plugin both sites install, what it carries, and the settings each site keeps for itself. The sections after it are how the parts fit, what each does, and what they changed for marketing.
03.2 How it fits together
One library underneath, and a config on each side of it.
The plugin carries everything the two sites have in common. Each site keeps its own settings, written out as a stylesheet the components read, so the same section takes on each site's values. "The same, but able to be different, since the config is the source of truth."
03.3 The parts
Everything the two sites share, in one install.
Blocks, site settings, an icon library and a navigation builder, shipped as one plugin. What each part does, and whether both sites share it or each sets its own.
| The part | What it does | Where it runs |
|---|---|---|
| Blocks | 22 blocks pages are built from: buttons, cards, panels, galleries, pills, customer stories, expandable cards. | Both sites, from the one codebase. |
| Elementor widgets | About 20 widgets for the parts of the sites built in Elementor, beside the blocks. | Both sites, from the same theme. |
| Site settings | Colour, type, spacing, radius, shadow, containers and section padding, then a set per component. | Each site, in its own admin, with its own values. |
| Navigation builder | The brand's own navigation, in place of the plugin-looking menus. | Both sites, from its own admin screen. |
| Icon library | Dave's icon set, loaded from one file. | Both sites. |
| Stylesheets | One SCSS file per design component, so a component has exactly one file in code. | Inside the plugin, shared by both sites. |
03.4 The workflow shift
A page took three weeks or more. Now marketing builds one from the prepared components within the day.
Workflow was one of the engagement's biggest wins. Each row is a step a page passes through, then and at the end.
| Before | After | What it saved | |
|---|---|---|---|
| Build | About four days of code per page. | Two to three days, in the plugin. | Up to two days a page. |
| Duplicate | Two more days rebuilding it for the second site, three to four sections a month. | None: a section built for one site is already synced on the other. | At least two weekends a month. |
| Change | A core value changed in code, hitting the whole site, unseen until it was pushed. | A setting in the site's admin, previewed first. | A code push for every change of mind. |
| Edit | Editors breaking widgets they were wary of, and us going in to fix it most of the time. | Edits likely to break something, we take over; the rest, we sign off. | Fixes after the fact: about 12 a month, now one or two. |
| Page | A new page designed, approved and coded by us: three weeks or more. | Marketing assembles it from the prepared components within the day. | Our hands on every page: marketing builds 5–10 a month itself. |
03.5 The engineering process
Two checks before anything went live: Dan's checklist on every release, staging review on every edit.
Marketing used every new section first, handing over a whole page to replicate. Dan checked each release against a UI checklist: text, design consistency, headings, spacing and layout; we decided which flags were real. The one release that broke was an Elementor cache-timing issue, fixed with a few settings in an unrelated plugin, no code. After the relaunch the editors built pages themselves, and everything they worked on went through staging before production.
- Marketing hands over a page
- Build the new sections, reuse the rest
- Dan's UI checklist
- Real flag or falseBack to 02
- Staging review
- Release
Caught at 05 Staging review
Edits that looked likely to break something, we took over; the rest we signed off.
Intimidated by the widgets, they broke things, and most of the time we went in to fix them.
- Editors' changes needing a fix
- ~12 → 1–2 a month
- Who, and where
- The site's editors, building pages with the widgets after the relaunch.
03.6 Engineering decision
Two sites wanted two themes. They got one plugin.
Two-week deploy windows couldn't hold a rebuild of two sites, so for years the move was too risky. When a new VP made the call, we froze deployment for 40 days and relaunched.
| The call | The easy answer | What we chose | What it cost, and what it bought |
|---|---|---|---|
| Where shared code lives | Keep building in each site's own codebase, inside the two-week windows. | One plugin both sites install. | A 40-day deployment freeze, across 200+ and 100+ pages. A section built for one site is already on the other, with no second development round. |
| What makes them different | Rebuild a section inside each site's own theme. | The same sections, with each site's own colour and spacing values. | Planning every setting up front, before we could trust the system. The two sites differ by config, not by code. |
| Where settings live | Values configured in code. | Settings in each site's WordPress admin, dynamic and previewable. | Admin screens planned in from the start, as part of the same planning. One place where we, marketing and the stakeholders tune the design system, and see a change before it ships. |
04 Field notes
What the client said at the end, what came after, and the one thing we'd do differently.
What the client said, the calls behind the work, what we'd change with more time, and what the eight years come down to.
The client, unnamed
Thanked us for "accepting an impossible task", and for being "brave enough to accept that challenge".
In hindsight
What went wrong first was onboarding the editors, not the code: the widgets intimidated them, and things broke. With the time, we'd have given everyone a week of onboarding and full documentation; the 40 days had no room for it.
Dynamic and previewable
Settings live in the admin because the client changes its mind mid-sprint: "everything needs to be dynamic and previewable". "I would make any of my objections be evident in that preview."
A team, in-house
From 2024, with graphics, QA and WordPress in the team, the work moved "so much faster". Chris still took about 40% of the WordPress work, so nothing waited on a handover.
Staying on WordPress
Moving the sites to something like Astro would have been an optimisation, but a company that large is hard to steer. We built the foundation where the sites already were.
By the end
The VP was making new page designs with AI, in a day, and handing them to us to build. "From that point forward everything moved towards growth."
The brand, after
"A lot of that really paved the foundational branding": the design system outgrew the site, and "it made them very, very happy later on".
What it comes down to
The process: a design system, a design language, a source of truth. In Chris's words: "I am not just a designer or a front-end developer … I operate in and as a creative director."
05 Team and stack
Four people across design and engineering.
Built on WordPress, Elementor, Gutenberg Blocks, HTML, SCSS, and PHP. Made with Figma, VSCode, GitHub, and Git.
- Built on
- WordPress · Elementor · Gutenberg Blocks · HTML · SCSS · PHP
- Made with
- Figma · VSCode · GitHub · Git
Chris Javier Oliveros
Lead UI/UX Designer, Lead Frontend Engineer
Designed the brand's design system and the pipeline every visual passes through, then architected the front end to match — one SCSS file per design component — ending in one codebase both platforms install.
- The website's design system became the base of the client's branding: the rest of its product lineup took on the same fonts and colours.
- Moved both sites, 200+ and 100+ pages, onto one shared plugin: the first relaunched 2025-10 after a 40-day deployment freeze, the second 2026-01.
- By the end, a new page could go live within the day from the prepared components.
- Cut each page's front-end build from about six days (four, plus two duplicating it for the second site) to two or three.
- Cut a page design's review rounds from three or four, of two to three days each, to one or two.
- Editors' changes needing a fix fell from about 12 a month to one or two after the relaunch.
- By the end, marketing built all its own pages: about 5–10 a month.
Jake Christian Oliveros
Lead Developer
Owned the WordPress side: built the plugin's 22 blocks and wired its site settings.
Dave Mark
Graphic Artist
Made the icons, illustrations and other graphic assets most featured sections use, and fitted his SVGs into Chris's components in Figma.
Dan Marco
QA
Owned QA on releases once more went through the release pipeline and more could break.
06 Impact
Eight years in: one or two review rounds a design, no section built twice, and 200+ pages on the first platform.
Each row is a measure before the work and at the end. The befores aren't one year: review rounds are 2018, before the design system; the build figures are 2025, before the one codebase. A new page's after is one assembled from the prepared components, not a new design.
Review rounds before a design is final
per design1–2
Before
3–4, of 2–3 days eachFront-end build
per page2–3 days
Before
About 4 days, + 2 for the second siteA new page, to live
per pageWithin the day
Before
3 weeks or moreSections built twice
a monthNone
Before
3–4Editors' changes needing a fix
a month1–2
Before
About 12The first platform's pages
2018 to 2026200+
Before
About 12 landing, 30–40 blog