Selected work
Real case studies across product architecture, admin/API platforms, and enterprise direction.
These entries are concise public summaries of live product work, private operational architecture, and selected client-side architecture leadership.
Selected case studies
Three publishable proof points across product, operational architecture, and enterprise change
Each entry stays concrete about scope, architecture, and outcome. Where client confidentiality applies, the summary stays at the level already public in the role history.
World of Aletheia
A production Astro platform for tabletop worldbuilding and campaign play, built to handle public discovery, protected campaign access, and an Obsidian-first publishing workflow.
Problem
The site needed to serve both public world reference and protected campaign material without splitting authoring, discovery, and runtime access into disconnected systems.
Constraints
Content volume was growing, campaign areas needed fail-closed access control, and the publishing workflow had to stay lightweight for ongoing authoring rather than turning into CMS admin overhead.
Approach
Use an Astro-first architecture with explicit product domains, schema-validated collections, and an Obsidian-first sync path that keeps authoring separate from the deployment surface.
Architecture
Cloudflare Workers/Pages runtime, D1-backed discovery metadata, R2 object storage, Better Auth campaign boundaries, and runtime checks only where protected content requires them.
Outcome
A live product with public reference routes, protected campaign spaces, and a static-first posture that still supports authenticated boundaries and cloud-backed content operations.
Notes
Both the live site and public repository are available, so this case can show real architecture decisions instead of a retrospective summary only.
World of Aletheia Admin and API Platform
A private SvelteKit administrative platform and API layer supporting campaign membership operations, account-management workflows, and D1-backed public read contracts for World of Aletheia.
Problem
The public World of Aletheia site needed runtime-backed campaign and account capabilities without coupling the public repository directly to private administrative workflows or database internals.
Constraints
The system had to keep admin operations private, preserve clear public/API boundaries, support Better Auth campaign access, and prevent front-end behavior from drifting away from documented contracts.
Approach
Build a private SvelteKit admin service with OpenAPI-first contracts, explicit admin versus public API boundaries, Zod-backed validation, and focused operator workflows for account and campaign management.
Architecture
Cloudflare Workers/Pages runtime, D1-backed account and campaign data, Better Auth session boundaries for campaign-scoped access, Cloudflare Access for trusted admin-console operations, and OpenAPI contracts as the source of truth for public and internal API consumers.
Outcome
A private operational system that supports the public site while keeping sensitive administrative behavior out of the public repository. Public-facing development can rely on documented API contracts instead of private implementation details.
Notes
The repository remains private by design because it contains administrative workflows, security assumptions, and operational implementation details. Public portfolio references describe the architecture and contract discipline without exposing the admin surface itself.
Cloud platform architecture and technical governance for a UK national services organisation
A publishable summary of digital architecture work for a UK national services organisation, focused on AWS platform direction, legacy integration, vendor alignment, and early Technical Design Authority setup.
Problem
A national services organisation needed cloud platform direction that could support modernisation while still integrating with existing legacy systems and operating within established delivery constraints.
Constraints
The work had to balance cloud-native platform goals with existing systems, vendor involvement, delivery pressure, and the need for clearer technical governance before the platform moved into later delivery stages.
Approach
Define a pragmatic AWS platform direction, clarify integration needs, support vendor and solution evaluation, and help establish a Technical Design Authority function to improve consistency of technical decision-making.
Architecture
Focus on AWS platform architecture, legacy integration patterns, scalability and resilience concerns, vendor alignment, and governance practices that connected early solution design to wider platform direction.
Outcome
Produced initial architecture and design direction for a cloud-native platform initiative, supported technical integration and vendor selection, and contributed to the early foundations of a Technical Design Authority function before later delivery and production rollout.
Notes
This summary is intentionally anonymised and limited to early-stage architecture and design work. It avoids confidential programme detail, internal architecture specifics, production rollout claims, and invented delivery metrics.
Selected work
Need help with similar product, platform, or transformation pressure?
The services page explains how these patterns translate into consulting engagements. Contact is the direct next step when one of these situations already looks familiar.