- Platform
- Web App
- Duration
- 12 weeks
- Industry
- MarTech
- Read time
- 5 min
The 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 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.
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.
before & 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 every 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
- 01
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.
- 02
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.
outcomes
What we achieved
WordPress PHP with plugin overhead produced slow page load times that drove customers away from the rewards catalog before they had a chance to engage with it.
Poor performance and a dated interface reduced the platform's ability to keep customers returning between utility service interactions.
Every reward update and campaign change required a developer ticket. The marketing team had no independent control over the content they were responsible for managing.
Your loyalty platform is too slow and rigid to keep up with your growing customer base?
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.
Engagement
How we worked together
- 01Weeks 1–2
Discovery and scoping
We map the problem before writing code. Two weeks of technical audit, stakeholder interviews, and prototype — so both teams align on scope and risk before sprint one. - 02Ongoing
Two-week Agile sprints
Each sprint ends with working software, not a status update. You review a real build, request changes, and approve before we move forward. No surprises at handover. - 03Ongoing
Daily async updates
Slack for daily progress, Asana for task visibility, weekly video calls for decisions. You have full visibility without needing to attend every meeting. - 04Final
Handover and warranty
Full code handover with deployment runbooks and documentation. Thirty-day warranty period for production issues at no extra cost.
stack
Why we chose this stack
- 01The 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.Sanity
- 02A 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.Gatsby
- 03Content 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.Vercel
Still curious?
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.
