Case study · Jun 2026 – present
SEA Construction: retiring a legacy platform without drama
A UK construction-consumables manufacturer, trading internationally, with a website built as a bespoke ASP.NET application by an agency years ago — content locked inside a custom CMS, analytics half-dead, and no easy way forward. My brief: replace the platform without losing a page, a product, or a day of business.
01The engagement
SEA manufactures and supplies construction consumables — piling accessories, soil nail systems, screw piles — with a catalogue running to hundreds of products across ten categories, plus case studies, technical downloads and certification pages. All of it lived in a bespoke ASP.NET MVC application with a custom admin panel: a platform the business couldn't maintain, extend, or economically host, from a supplier relationship long past its natural life.
The trap with legacy replacements is treating them as rewrites. This is a working business with customers arriving daily; the site is its shop window and its technical library. So the project was framed the way I frame everything: incremental passes, each leaving something reviewable and the business untouched until the moment of a deliberate, reversible switchover.
02Inventory before architecture
Pass one wrote no code at all. I audited the live site page by page and produced a complete content inventory — every product in every category, every PDF brochure and technical document, every person, policy and certificate — so the rebuild had a definition of done that both sides could point at: nothing gets lost.
The audit also surfaced what a decade of quiet neglect looks like: a logo slot still reading "your logo here", an analytics property from a platform Google sunset years ago, inconsistent contact domains across staff listings, and terms-of-sale text that existed nowhere but the live page. All catalogued, all resolved in the rebuild.
You can't retire what you haven't counted. An afternoon of unglamorous cataloguing bought the whole project its safety net — and gave the client's directors a document they could review without needing to understand anything technical.
03The architecture
The public site is static files on S3 behind CloudFront — fast, effectively free to run, and with nothing to patch. Content management runs beside it, not inside it: a lightweight admin portal talks to a single Lambda through API Gateway, storing content in DynamoDB as a working draft and a published snapshot per section. The public site reads only published snapshots; editors can experiment freely without any way to break the live site, then publish deliberately.
- Draft → publish by design. Every content section — products, case studies, people, news, carousel — exists as a working draft and a published snapshot. Publishing is a deliberate act, and the live site cannot render a half-finished edit.
- Admin fully isolated from the public site. The portal lives outside the public deployment entirely, with its API behind Cognito-authorised routes — the public site and the editing surface can never leak into each other.
- Image uploads that never go stale. Editors upload via presigned URLs to uniquely-named objects with immutable caching — no cache invalidation, no overwriting, and routine deploys can never delete an editor's images.
- Built multi-site from day one. The same admin portal and content service are keyed to serve the group's related sites, not just one — a second brand costs a prefix, not a platform.
04Working with the client
The stakeholders are directors and coordinators at a manufacturing firm, not IT people — so the working method matters as much as the architecture. Everything is reviewable: the staged rebuild runs live for the client to click through, feedback arrives as plain-English emails ("change engineers to team members; add a purchase-order field to the enquiry form"), and changes land within the day, on staging and in the content store both.
It's the same discipline as fifteen years of sole-charge IT: translate business requests into system changes, keep every step reversible, and never make the client learn your vocabulary to get what they want.
05Where it stands
The engagement continues: stakeholder review, then the DNS switchover — deliberate, reversible, and boring, exactly as a cutover should be.