01 Overview
A business that sells the truth about countries, on a site that couldn't say much about it.
The client rates the risk of every country on its own scoring, and sells one report per country. The brief was a move from Squarespace to WordPress. What the site needed was the product speaking for itself: a design the new brand could live in, and previews that ran on the platform's data instead of the CEO's typing.
01.1 The problem
No clear way to buy a report, and every country's preview typed in by hand.
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 Squarespace template couldn't carry the new branding or the CEO's ideas, and there was no clear way to buy a report: buyers emailed him and sorted it out in the thread. ~4 a week report requests, all by email to the CEO, by Chris's estimate. | Every interface redesigned on a new design system, with previews that show what the full report holds and, later, tiers and pricing pages. | See the work |
| Engineering problem Each update was written twice: once to their DevOps for the platform, then again on the site, by hand. 2–3 a day manual changes, almost every day. | The platform became the source of truth: its data relayed into WordPress, cleaned on the way in, and every preview updates itself. | See the work |
01.2 The timeline
Hired in 2021 to move a site. Five years later, still designing, building and keeping it.
The work never changed shape: design, development and upkeep, hourly the whole way. It grew by what the client added: a web app in the first months, tiers and pricing in 2024.
- 2021August
Hired to move the site off Squarespace; Chris designs, and Jake is on from the start.
- December
We design the platform's web app and build its front end, for their DevOps to wire in.
- 2022March
The new WordPress site goes live, replacing Squarespace.
- 2024May
The tiers and pricing pages come in.
- 2026October
The engagement ends as they move off WordPress to a platform of their own.
01.3 Context
A new brand, a template that couldn't hold it, and a CEO with a lot of ideas.
What the work started from, before any of it was ours to change.
What they sell
A risk rating per country, on their own internal scoring: money laundering, sanctions, corruption, terrorism financing and more. Each report covers one country. It wasn't about comparing countries.
How we came in
A co-founder of two earlier clients, both also moved off Squarespace, introduced us. They hired us after seeing that work.
The brief
Move every Squarespace page to WordPress. Squarespace couldn't be customised beyond a bought template, and the templates didn't fit their brand or their plans.
The brand
Someone else had just redone the branding. From the old white-and-green site, only the green came across; nothing else was kept.
As they scaled
"The project cannot speak for itself a lot." No sign-ups, no sales, no tiers: no clear path to a premium, full report.
Who led
The CEO is "a type of client that has a lot of opinions. He is very passionate about his own product. So we let him take the wheel." It wasn't restricting: we built from his ideas, not ours.
02 Design solution
A redesign, not a move. Every interface rebuilt on a new design system, from the CEO's own ideas.
The template couldn't carry the new brand, so we decided at the first discussion to redesign. A design system in Figma came first: colours, rules, typography, section designs and consistency checks. Then every page, from the CEO's specifications, with a lot of UX planning around what a preview shows and how someone gets to the full report.
02.1 The work
Every screen, shown whole.
The redesign in one long run that pans as you scroll: the country previews, the tiers and pricing pages, and the left-hand navigation that made the site read like a web app.
02.2 The messaging shift
The site stopped leaving the selling to an email thread and started explaining the product itself.
Three things the redesign moved: how the brand looks, what a preview tells a buyer, and how a buyer gets to the full report.
| Before | After | What it aligned | |
|---|---|---|---|
| Brand | A Squarespace template in white and green that couldn't carry the new branding. | The new brand on its own design system, with only the green carried over. | The site with the identity the business had just commissioned. |
| Preview | Preview pages that couldn't say much about the paid report. | Previews planned so a buyer can picture what the full report includes. | The free page with the paid report it's selling. |
| Buying | Email the CEO and sort it out in the thread. | Tiers and pricing pages: a clear path from preview to full report. | The site with how the business sells. |
02.3 The design process
Every page started as the CEO's message and went back to him before any code.
Each page came as a message naming it, with a screenshot of the old Squarespace page, since the site itself had expired. We aligned it to the design system and sent it back for his approval. What came back was rarely a fix: it was ideas Squarespace had never let him build, new CTAs, sections, asides.
- The CEO's message
- Align to the system
- The CEO's review
- New ideasBack to 02
- Approved
- Front end
Caught at 03 The CEO's review
The navigation moved to the left, like a web app.
The site had too many tabs for a usual top bar. We compacted it hard, and he still didn't like it.
- Top-level links
- ~15, all in view
- Who, and where
- The CEO, reviewing the first navigation.
02.4 Design decision
Asked to move pages, we redesigned them, from the CEO's ideas rather than ours.
Three calls shaped the design: redesign instead of migrate, whose ideas to build from, and a navigation unconventional for a marketing site.
| The call | The easy answer | What we chose | What it cost, and what it bought |
|---|---|---|---|
| Move or redesign | Move every Squarespace page across as it was. | Redesign every interface on a new design system, decided at the first discussion. | Every page designed new before the move, seven months from start to launch. A site that carries the new brand, with room for the ideas the template couldn't take. |
| Whose ideas | Explore our own directions and present them. | Build from the CEO's ideas, with nothing moving without his green light. | Our own directions for the previews, left unexplored. A redesign he was very happy with, because it followed his specifications. |
| Where the navigation goes | The usual top bar, compacted. | A left-hand navigation, like a web app. | An unconventional layout for a marketing site, which in hindsight wants more hide-and-show. A site consistent with the web app we designed next, which the CEO liked. |
03 Engineering solution
The platform became the source of truth, and WordPress learned to read it.
The CEO had been typing each country's update in twice. We wired the previews to the platform's own data: their DevOps set up the endpoints, a relay kept the keys out of sight, and Jake cleaned the data on its way into WordPress. It was our first time connecting WordPress to a back end.
03.1 The wiring
From the platform to a preview, in one picture.
The build on one page, in six steps: the platform's data, the endpoints their DevOps set up, the relay that keeps the keys out of sight, and WordPress cleaning it on the way in before the preview updates. The sections after it are the parts, what they changed, and how a change went live.
03.2 The parts
Previews that read the platform, a relay in between, and widgets the CEO can move.
What we built around WordPress, what each part does, and where it runs. Chris's front end, Jake's WordPress side.
| The part | What it does | Where it runs |
|---|---|---|
| Country previews | One per country, each showing the summary the platform sends and updating itself whenever that data changes. | WordPress, fed from the platform. |
| Data inputs | Custom inputs that bring each country's data into WordPress, stripping its HTML and in-house tags on the way in. | WordPress, built by Jake. |
| Relay server | Keeps the platform's API keys on one server, out of sight. Their DevOps asked for it. | Express, between the platform and WordPress. |
| Elementor widgets | Chris's front end, turned into reusable widgets the CEO places and moves himself. | Every page of the site. |
| Tiers and pricing | The path from a preview to the full report, added in 2024. | WordPress. |
| Old links | Every Squarespace address redirected to the same URL as before, so the analytics carried on unbroken. | WordPress, from launch. |
| Web app front end | The platform's interface, designed and built by us, handed to their DevOps to wire into their system. | Their platform. |
03.3 The workflow shift
A country update used to be written twice by hand. Now it's written once, on the platform.
Each row is a step a change passes through, before and after.
| Before | After | What it saved | |
|---|---|---|---|
| Update | The CEO wrote each update for DevOps to change the platform, then made the same change on the site. | The change lands once, on the platform; the preview updates itself. | Two or three manual edits a day, almost every day. |
| Layout | A Squarespace template that couldn't be customised beyond what was bought. | Widgets the CEO moves around himself, in an editor that shows the page close to how it looks. | Ideas left waiting on a template that couldn't take them. |
03.4 The engineering process
Two sign-offs before anything went live, and a check on the data after.
Chris's front end went to Jake to wire into WordPress, then to staging for the CEO's approval before production. Before launch everything lived on staging; after it, changes were batched there first. Once the previews ran on live data, the CEO's assistant checked them and told us when something was wrong.
- Front end
- Wire into WordPress
- Staging
- The CEO's approval
- Production
- The assistant's checkBack to 02
03.5 Engineering decision
Two calls kept the CEO in charge of the page and out of the data entry.
What a preview shows was never our call: the CEO decided, DevOps distilled it, and the site shows what the platform sends. How it got there, and how he edits around it, were.
| The call | The easy answer | What we chose | What it cost, and what it bought |
|---|---|---|---|
| The page builder | WordPress's own blocks. | Elementor widgets. | Every front-end component rebuilt as a widget. The CEO, who likes to move things around, edits in a view close to the real page; blocks "look like blocks in the editor". |
| Who cleans the data | Wait for their DevOps to send it clean. | Strip the HTML and in-house tags ourselves, as the data comes into WordPress. | Much of Jake's work on the project. Previews that update themselves without anyone tidying them by hand. |
04 Field notes
What a country's data shows, what WordPress turned out to be, and the one thing we'd add.
What seeing all of the data taught Chris, what the project changed in how we build, and what we'd do with more time.
From the inside
Building the previews, Chris saw nearly all of their data. "You can only really see the truth about the country when you see their data."
WordPress, opened up
We had thought of WordPress as "a closed ecosystem", a website and CMS only, and reached for front-end frameworks for APIs. "We were kind of close-minded like that." This project showed WordPress could do it too.
Why above 90
We aimed page speed above 90 so the CEO could trust the site was faster than Squarespace while carrying the new identity.
In hindsight
Keep the left-hand navigation, and add more hide-and-show and compaction. "But I wouldn't say it's a very important thing."
05 Team and stack
Two people across design and engineering.
Built on WordPress, Elementor, Express, and WordPress REST API. Made with Figma and Adobe XD.
- Built on
- WordPress · Elementor · Express · WordPress REST API
- Made with
- Figma · Adobe XD
Chris Javier Oliveros
UI/UX Designer, WordPress Developer
Moved the website from Squarespace to WordPress and redesigned every interface to the client's new branding on a new design system; designed the per-country report previews and the tiers and pricing pages; designed and built the front end of the client's web app, handed to their DevOps to wire into their system.
- Country previews update themselves from the client's platform; before, the CEO made two or three changes by hand almost every day.
- By his estimate, report requests rose from about four a week, by email, to 12 to 20 a week after launch.
- Page speed above 90 on the new WordPress site, against around the low 40s on Squarespace (from memory).
Jake Christian Oliveros
Lead Developer
Owned the WordPress side: turned Chris's front-end code into reusable Elementor widgets, wired the client's back-end country data into WordPress through custom inputs, and stripped its HTML and in-house tags on the way in.
06 Impact
Above 90 on page speed, no previews updated by hand, and three to five times the report requests.
Each row is a measure before the new site and after it. The page-speed before is from memory; the report requests are Chris's estimates, with no data on purchases.
Page speed
Squarespace, then the new WordPress siteAbove 90
Before
Low 40sManual preview updates
on the old siteNone
Before
2–3 a dayReport requests
a week12–20
Before
About 4, by email