Case study 02
Lloyds Wealth
Lead developer on the Lloyds Wealth website, from the original Schroders Personal Wealth build through the rebrand and into ongoing support, all under financial-services compliance.
- Client
- Lloyds Wealth
- Agency
- Bond and Coyne
- Role
- Lead developer
- Year
- 2025
- Discipline
- Financial services · Enterprise web
Overview
I've led the Lloyds Wealth website from the start. I set up the project in March 2025, built the original Schroders Personal Wealth site, carried it through the rebrand to Lloyds Wealth and now look after it under an ongoing support agreement. It's a team of three: I did most of the development and led a mid-level developer, setting their work and reviewing it, with our Technical Director stepping in when needed.
Working in a regulated industry
- Sign-off: nothing goes live without the client's approval. Every change is ticketed, tested in UAT, signed off and released on a schedule.
- Documentation: we documented the architecture, infrastructure, releases and deploy order as we went.
- Accessibility: WCAG work ran throughout, from skip links and accessible form labels to contrast and HTML validation fixes, aiming for a Lighthouse accessibility score of 100.
- Consent: no analytics, tracking or search storage is set until a visitor consents, using Cookiebot with Google Consent Mode.
- Audit trail: the CMS logs editor activity and API requests.
The rebrand
Design-system work began in February 2026, the new production infrastructure went live at the end of March, and clean-up ran through May. The scope covered the full visual identity (colours, fonts, the Lloyds icon set, logos and navigation), a move to the lloydswealth.com domain and CDN, new production infrastructure, redirects, and renamed tracking parameters and CMS fields.
Because the site was built on a token-driven design system, most of the visual change happened in one place and flowed through every content block. I also extended the CMS icon picker so the old and new icon sets worked side by side, so no content broke mid-migration.
Reliable lead forms
The "book a call" and referral forms send leads through the client's API to their CRM, so they have to work every time. I made them dependable end to end:
- One shared Zod schema validates on both the client and the server, so the two always agree.
- Access tokens are cached with a safety margin, with a single automatic refresh and retry when one expires.
- Reads retry with backoff, and submissions get a longer timeout so the downstream call can finish.
- Real errors are logged rather than swallowed.
The intermittent failures stopped, and anything that does go wrong is now visible straight away.
Faster and easier to run
- All infrastructure in Terraform, covering AWS and the Vercel project, with separate staging and production environments.
- Versioned releases and changelogs with Release Please and GitHub Actions.
- Faster insights pages: queries run in parallel, and archive pages use a much lighter query (9 GraphQL fragments instead of more than 60).
- Pages cached and refreshed every 30 minutes, with on-demand updates when editors publish.
- Error boundaries and isolated data fetching, so one failed query can't take down a page.
- Regular dependency and security patching, including the upgrade to Next.js 16.
- Custom CMS tools for editors, including asset usage and keyword search.
Stack
Next.js and Tailwind CSS on top of headless Craft CMS through GraphQL, with Algolia for search. Hosted on Vercel and AWS, defined in Terraform, and tested with Vitest and Playwright.

