01
Web architecture
Designing scalable and maintainable web platforms.
CTO · Web Architect · Engineering
Building, fixing, and modernizing complex web platforms.
I work across architecture, backend engineering, infrastructure, performance, SEO, integrations, and internationalization to make complicated web systems simpler, faster, and more reliable.
The request path
Every layer is a place things go wrong.
Where the symptom appears, and almost never where the cause lives. Device, network, service worker, cached HTML.
Cloudflare and CDN rules rewrite, redirect and cache before your application ever sees the request.
Page cache, object cache and browser cache each hold a different version of the truth. Correct code can look broken here.
Apache config, rewrites, headers, TLS and HTTP/3 — the layer everyone skips when reproducing a bug.
WordPress, Laravel, routing, plugins and the accumulated decisions of everyone who came before.
Query shape, options tables, multisite scale and the slow path nobody profiled.
External APIs, tag managers, consent platforms and identity providers, each with their own idea of state.
Introduction
More than a developer.
CTO · Web Architect
I've spent years working on the parts of the web that become complicated after a platform grows: multisite environments, legacy code, integrations, infrastructure, internationalization, tracking, consent, SEO, caching, performance, and systems that have to keep working while everything around them changes.
That work never sits in one place. It runs the whole length of the stack, and the useful engineer is the one who can follow it there.
Problems I like to solve
Give me the complicated problems.
- 01
“Your WordPress installation has become too complex.”
- 02
“We need to modernize the frontend without rebuilding everything.”
- 03
“Cloudflare, caching, and the application don’t agree.”
- 04
“International SEO behaves differently across regions.”
- 05
“Tracking scripts are firing before consent.”
- 06
“An old system needs to communicate with a modern application.”
- 07
“The website is slow, but nobody knows why.”
- 08
“Several systems disagree about authentication.”
- 09
“The code works, but nobody wants to touch it.”
These aren't isolated coding problems. They're system problems.
Expertise
Nine layers, one system.
02
WordPress engineering
Advanced WordPress, multisite, custom plugins, themes, routing, APIs, and performance.
03
PHP & backend
PHP, Laravel, WordPress internals, APIs, authentication and integrations.
04
JavaScript & frontend
Modern JavaScript, frontend architecture, progressive enhancement and performance.
05
Cloud & infrastructure
Cloud hosting, Apache, CDN, DNS, caching, HTTP/3, deployment and troubleshooting.
06
Technical SEO
Technical SEO, hreflang, canonicalization, redirects, indexing and crawlability.
07
Internationalization
Multilingual platforms, localization, translation systems and regional websites.
08
Analytics & consent
GTM, analytics, attribution, OneTrust and consent-aware tracking.
09
Legacy modernization
Incremental modernization, static HTML extraction, architecture simplification and technical debt reduction.
Selected work
Categories of engineering work.
Real problem shapes rather than client logos. Each one names the layers involved and what actually had to be decided.
Project 01
Large WordPress Multisite Architecture
Project 02
From Page Builder to Clean HTML
Keep the CMS where it adds value. Remove it where it doesn’t.
Project 03
International SEO & Localization
Project 04
Debugging the Edge
When infrastructure layers disagree, debugging the application alone isn’t enough.
Project 05
Consent-Aware Tracking
Project 06
Laravel + WordPress Integration
Engineering philosophy
How I approach engineering.
- 01
Understand before rebuilding
First understand why the system behaves the way it does.
- 02
Simplify
Complexity is often a bigger problem than outdated technology.
- 03
Modernize incrementally
Not every legacy system needs a complete rewrite.
- 04
Follow the request
Debug the complete request path — browser, CDN, proxy, server, application, database and third-party services.
- 05
Optimize for the real system
Architecture should reflect actual traffic, people, constraints and business requirements.
- 06
Leave things better
Good engineering should reduce future complexity, not just solve today’s problem.
Engineering notes
Writing, in progress.
Notes I'm drafting on problems that cross layers. Nothing published yet — the list is the plan.
- 01
Why a WordPress problem is sometimes not a WordPress problem
Drafting - 02
How CDN caching can make correct code look broken
Drafting - 03
When should you remove WordPress from the frontend?
Outline - 04
Static HTML vs React vs WordPress
Outline - 05
Why hreflang implementations fail
Planned - 06
Debugging a request across Cloudflare, CDN, Apache and WordPress
Planned - 07
Consent management is an architecture problem
Planned - 08
How to modernize legacy websites without rewriting everything
Planned
Have a complicated web problem?
Let's solve the difficult one.
If the system is complicated, the documentation is incomplete, and everyone has a different theory about what's wrong — that's usually where I can help.
Architecture, infrastructure, legacy systems, integrations, performance, SEO, or something nobody has quite figured out yet.