01 / The problem
What was actually hard.
The surface is genuinely large: sixteen services, six packaged solutions, sixteen industries, work, insights, careers and pricing. Hand-authoring that many pages guarantees they rot, because nobody updates ninety pages consistently. It has to be content-managed from the start, with the taxonomy — service, solution, industry — modelled properly so the cross-links between them stay correct.
Taking money raises the bar sharply. A payment link that a client opens, pays and receipts has to survive duplicate webhooks, out-of-order delivery and a gateway that reports success twice. Each provider does this differently, so 'add a payment gateway' is really 'add another set of failure modes'.
02 / What we built
The system.
- A content model, not a page builder
- Services, solutions, industries, projects, posts and testimonials as first-class entities with their own relationships, so a new service appears everywhere it should without anyone editing a navigation file.
- Client portal
- Sign-in with quotes, invoices, payment history and profile — so a client checks their own account instead of emailing to ask.
- Payment links with multiple merchants
- A link, a hosted checkout and a receipt, with a merchant abstraction so more than one gateway can be configured and swapped without touching the checkout.
- Webhook handling built for reality
- Delivery events persisted and de-duplicated so a replayed or out-of-order callback cannot double-record a payment.
- Passwordless sign-in
- Login codes with recovery codes, which removes a stored-password liability from a site that also handles invoices.
- Careers with real applications
- Openings and applications as data, so a role posts to the site and the responses arrive somewhere structured rather than in an inbox.
- Quote and lead capture
- Enquiries captured against the service or solution they came from, so the first reply already knows what the person was reading.
- Hand-written front end
- No CSS framework and no build step — the stylesheet and scripts are authored directly. Deployment is a file copy, and there is no toolchain to keep current.
03 / What carried over
Decisions worth reusing.
The parts of this build that we would apply again on a different problem in a different sector.
- A build step is a liability on a long-lived site
- Removing the front-end toolchain removes a whole class of future breakage. Five years on, a site with no build step still builds.
- Model the taxonomy before the pages
- Services, solutions and industries cross-reference each other constantly. Getting those relationships right is what stops ninety pages drifting out of sync.
- Payments are an idempotency problem
- The interesting part is never the happy path. It is the duplicate callback, the abandoned checkout and the gateway that answers twice.
04 / More work
Other builds.
Different sectors, the same delivery discipline.
Encore Episode
A vertically-integrated event commerce platform — ticketing, gate control, cashless payments and vendor settlement in one system.
eSign Platform
An e-signature platform with envelopes, templates, a REST API and a tamper-evident certificate of completion behind every signed document.
Property Marketplace
A verified-first property portal — listings that carry evidence, in-app messaging, and a shortlist and visit flow built around actual buyer behaviour.
Next step
Have something like this to build?
Start with a diagnostic. It is fixed-fee, time-boxed, and it will tell you honestly whether the thing is worth building — including when the answer is no.