Short answer
RaftLabs rebuilt an Irish utility company's customer loyalty platform from WordPress PHP to Sanity headless CMS and Gatsby JS, eliminating plugin compatibility issues, slow page load times, and the developer bottleneck that prevented the marketing team from updating content independently. The rebuild is projected to deliver 3x faster page load times, a 40% increase in user engagement, and a 60% reduction in content update time. The headless CMS architecture means all content (rewards, promotions, campaigns) can be updated in real time by non-technical staff without raising a development ticket. The project was delivered in 12 weeks.
The situation
The loyalty platform worked. The problem was everything that touching it required.
Built on WordPress PHP, the platform had accumulated years of plugin dependencies. Every update risked a compatibility conflict. Slow page load times had become a standing complaint. When the marketing team wanted to update a reward or run a campaign, they raised a ticket and waited for a developer to make the change.
A loyalty program that cannot be updated quickly is a loyalty program that loses relevance. The company needed the platform rebuilt on a foundation where content updates were the marketing team's job, not an engineering task.
The developer dependency turns a two-hour change into a two-week ticket. A campaign that should adapt to customer behaviour in real time launches when the buyer has already left. The rebuild was about who gets to act, not just how fast the pages load.
We rebuilt the platform on Sanity headless CMS and Gatsby in 12 weeks. The Sanity backend gives the marketing team full control over rewards, promotions, and content without touching code. Gatsby generates static pages that load in a fraction of the time the WordPress site took. No plugin conflicts, no developer bottleneck for content changes.
Engagement
The engagement
- Client
- An Irish utility company's customer loyalty platform
- Problem
- WordPress with years of plugin dependencies: slow pages, compatibility conflicts, and every content update stuck in a developer ticket queue
- What we built
- A rebuild on Sanity headless CMS and Gatsby: the marketing team publishes rewards and campaigns directly, pages generate statically, no plugin conflicts
- Delivery
- 12 weeks, migrated from live WordPress without disrupting the active program
- Status
- Live. Performance and engagement figures below are pre-launch projections, stated as such
Before and after
What changed
- WordPress platform accumulated plugin dependencies that created recurring compatibility conflicts
- Page load times were slow, frustrating customers and reducing engagement before they reached the rewards
- Every content update (a new reward, a seasonal promotion, a campaign banner) required raising a developer ticket
- No reliable way to push content changes quickly during active campaigns
- UI felt outdated and did not match the modern brand the company had built in other channels
- Technical debt made each change slower and riskier than it should have been
- Sanity headless CMS gives the marketing team a clean interface for updating rewards, promotions, and content in real time
- Gatsby static site generation produces pages that load significantly faster than the old WordPress setup
- No developer involvement required for content changes: the marketing team operates independently
- Seasonal campaigns and new rewards go live without a ticket queue
- Modern responsive design matches the utility company's current brand standards across all devices
- Architecture is built to extend with new features without accumulating the technical debt that slowed the old platform
What we had to solve
Migrating content from WordPress without disrupting an active loyalty program
The platform was live and being used by customers throughout the rebuild. Content (rewards, member tiers, campaign history) had to be mapped from WordPress's database structure into Sanity's schema without data loss or downtime. Every field in the old system had to find a clean equivalent in the new one, and the cutover had to happen without customers seeing an incomplete or broken reward catalog.
Designing a Sanity schema the marketing team could actually use
A headless CMS is only useful if non-technical users can operate it confidently. We had to design the Sanity content schema so that the marketing team could create a new reward, update campaign details, and change seasonal content without accidentally breaking a page layout or needing to understand JSON. That meant structured document types with validation rules, clear field labels, and previews, not just an empty content editor that exposes too much of the system's internals.
Proof
What this page can and can't claim
The figures below were pre-launch projections, not measured results. This page states that plainly rather than presenting estimates as outcomes.
| Result | What changed | Period or context | Evidence and limitation |
|---|---|---|---|
| Page speed | 3x faster page loads, projected | Gatsby static generation replacing WordPress PHP with plugin overhead | Pre-launch projection. No post-launch measurements were available for this review |
| Engagement | 40% increase, projected | Faster pages and a modern interface were expected to bring customers back to the rewards catalog | Pre-launch projection. No post-launch measurements were available for this review |
| Content velocity | 60% reduction in content update time, anticipated | The marketing team publishing directly in Sanity instead of raising developer tickets | Pre-launch projection. The workflow change itself, marketer-owned publishing, is project-recorded |
| What shipped | A live loyalty platform on Sanity and Gatsby in 12 weeks | Content migrated from WordPress without disrupting the active program, schema designed for non-technical marketers | Project-recorded |
the build
What we built
The rebuild separates the content management layer from the presentation layer entirely. The marketing team works in Sanity; customers see a fast, statically generated site built by Gatsby.
Marketers publish rewards and campaigns without raising a ticket
The Sanity schema is structured around the objects the marketing team actually manages: rewards, member tiers, campaigns, and promotional banners. Each document type has validation rules and a live preview so editors can see how their content will appear before publishing. A non-technical marketer can create a new reward, set its point cost and expiry date, and publish it to the live site without raising a ticket.
Customer pages load immediately, no database query on each request
Gatsby builds every page at deploy time from the content in Sanity. The result is pre-rendered HTML that loads immediately, with no database query on each page request. The rewards catalog, membership dashboard, and campaign pages all load significantly faster than the previous WordPress setup, without any infrastructure scaling required.
Content publishes to the live site in minutes, no deployment step for the team
When a marketer publishes a change in Sanity, a Vercel build trigger fires automatically. Gatsby rebuilds the affected pages and the updated content is live in minutes. The marketing team never has to think about deployments, and there is no manual step between publishing content and customers seeing it.
Members manage their account from any device without UI degradation
The rebuilt platform uses a clean, mobile-first design that reflects the utility company's current brand standards. Customers can browse rewards, check their point balance, and manage their membership from any device without the UI degradation that characterised the old WordPress theme.
The lesson
The CMS is a staffing decision
The technical question was WordPress or headless. The real question was who gets to change the website. The CMS is a staffing decision: the architecture had to put the controls in the hands of the people who own the loyalty program. Loyalty campaigns are inherently time-sensitive, and a reward that launches after the moment has passed is a reward that never mattered.
There is a trap here worth naming. A business hears that headless is the future, spends six months and a large bill, and ends up with a fast website the marketing team still cannot edit without calling a developer. The schema work, validation rules, field labels, and previews are what make the independence real. Without them, headless is just a faster way to wait on engineering.
How it runs
- Sanity
- The primary requirement was giving the marketing team content control without developer involvement. Sanity's structured content model, document validation, and real-time preview let non-technical users update rewards and campaigns confidently, and the schema can be extended as the program evolves.
- Gatsby
- A loyalty platform with thousands of registered customers needed fast page loads for the rewards catalog and member dashboard. Gatsby's static site generation builds pre-rendered pages that load quickly regardless of server load, eliminating the PHP rendering overhead that made the WordPress platform slow.
- Vercel
- Content updates in Sanity trigger an automatic rebuild and deploy via Vercel. This means the marketing team publishes a change and it is live on the site within minutes, with no manual deployment step and no server configuration to manage.
Common questions
A headless CMS manages content (rewards, campaigns, member tiers) separately from the front-end presentation. The marketing team works in a structured content editor. The website is built by a framework like Gatsby that pulls from that content. The result is that content updates do not require developer work, and the front-end can be rebuilt or redesigned without touching the content structure. For a loyalty platform that needs to update promotions frequently and maintain fast performance, that separation is the difference between a platform the marketing team controls and one they depend on developers to manage.
WordPress performance problems at scale come from the PHP rendering model: every page request hits the database and builds the HTML on the server. Plugins add overhead and create compatibility risks. These are architectural constraints, not configuration problems. Migrating to a headless architecture built on static site generation removes the root cause rather than patching around it.
Yes, with the right Sanity schema design. The key is building document types that match how the marketing team thinks about content (reward records with point costs, campaign objects with start and end dates, promotional banners with image and copy fields) rather than exposing generic page builders or raw JSON editors. With the right structure and validation rules in place, a marketer can publish a new reward or campaign in minutes with no technical knowledge required.
For a platform of this scope (live content migration, Sanity schema design, Gatsby frontend build, and Vercel deployment pipeline) 12 weeks is the typical timeline with a focused team. The most time-consuming part is usually the content mapping: understanding all the content types in the old system and designing the right Sanity schema to replace them cleanly.
Yes. The architecture (Sanity for content management, Gatsby or Next.js for the front end, Vercel for deployment) applies to any loyalty program where the marketing team needs content independence and the platform needs performance at scale. We have used it for retail, hospitality, and financial services programs. The specific schema design changes by industry, but the approach transfers.
Related work
More work like this
AI phone agents automate global feedback loops through voice interviews
Text surveys only reached people comfortable filling out forms. We built a voice platform that calls anyone with a phone, runs the interview, and has the findings ready when the last call ends.
Musgrave receipt scanning software case study for SuperValu and Centra
Musgrave's post-campaign report records 1,062 users and 1,610 receipt submissions. At the reporting snapshot, 1,158 were AI approved, 409 AI rejected, 4 manually approved, 10 manually rejected, and 29 remained processing.
Brux ships a dental marketing SaaS: AI smile previews, GoHighLevel sync, and self-serve onboarding built for 1,000-office scale
Brux Smile Makeover is a dental marketing SaaS where patients upload a selfie and get a lifelike AI smile preview in seconds. We built the AI pipeline, GoHighLevel two-way CRM sync, Stripe billing, and self-serve QR flyer onboarding built for 1,000-office scale.