Web Architecture Consulting

Web architecture for companies between $1M and $20M ARR.

First-generation stacks are built to validate a product, not to support a business. At $1M ARR that is fine. By $10M ARR, the same stack starts producing problems that compound: slow pages that affect conversion, data models that require workarounds for every new feature, and no observability into what is actually happening in production. The work is not always a rewrite — usually it is a targeted architecture intervention at the point where the original decisions have run out of headroom.

I work with SaaS and commerce companies at $1M–$20M ARR who have outgrown their first-generation stack and need a clear diagnosis of what to fix and in what order. The output is documented, type-safe, and observable from the day the engagement closes.

Start a conversation →See an example

Three failure modes I diagnose in almost every engagement.

These are not random problems. They are the predictable result of a stack built for early-stage speed that was never updated to support the business it helped create.

Performance debt

The first-generation stack was built for validation speed, not load. Pages that take 4–6 seconds to server-render. Database queries that block on N+1 patterns nobody caught during early development. A Core Web Vitals score that quietly costs you conversion rate every month. Performance debt compounds: the longer it stays, the more code gets written around it rather than on top of clean abstractions.

Observability gaps

You know the system went down after it went down. There are no structured logs, no distributed traces, no alerting on P95 response times or error budgets. When something breaks in production, the diagnosis is manual — reproduce locally, add logging, redeploy, wait. At $5M ARR this costs hours. At $15M ARR it costs deals. Observability is not optional infrastructure — it is the difference between managing a system and reacting to one.

Scaling that requires rewrites

The data model was designed for a single tenant. The auth layer assumes a single role. The file storage solution works at 100 uploads per month but not at 10,000. When these constraints surface — and they always do between $5M and $20M ARR — the options are: patch the original architecture indefinitely, or rewrite the part that was underspecified. Most rewrites are avoidable if the architecture decision was made correctly the first time.

What a web architecture engagement produces.

These are specific deliverables, not abstract outcomes. Every engagement closes with documentation your engineering team can act on without me present.

01

Architecture decision record

A documented ADR for every significant technical decision: why this database, why this rendering strategy, why this queue, what alternatives were considered and discarded. New engineers understand the system within days, not months. Decisions made under time pressure don't get silently reversed by the next developer who hits the same problem.

02

Documented data flow

A complete map of how data moves through the system: ingestion, transformation, storage, retrieval, and delivery. Every integration point is documented. Every mutation is traceable. When something breaks, the data flow map is the first place you look — and it tells you where to look next. Without it, debugging is archaeology.

03

Observable from day one

Structured logging with a consistent schema. Distributed tracing across service boundaries. Alerting on business-critical paths: checkout, auth, payment processing, API rate limits. Dashboards that show the health of the system, not just that the server is running. Built using OpenTelemetry so you are not locked into a specific observability vendor.

04

Type-safe end-to-end

TypeScript throughout the stack, with Zod schemas at every external boundary: API inputs, environment variables, third-party responses. The type system catches the class of bugs that cause production incidents — null pointer errors, missing required fields, unexpected shape changes from upstream APIs. Runtime validation at boundaries means errors surface where they originate, not three layers downstream.

Further reading on web architecture.

Each post covers a specific architecture decision or pattern in enough depth to be useful on its own. Sorted roughly by where they tend to matter most in the $1M–$20M ARR range.

→Web architecture decisions that scale: what to get right before $10M ARR→Next.js App Router patterns in 2026: what works in production→Database decisions at SaaS scale: Postgres, edge, and when to use both→API design patterns in Next.js: route handlers, tRPC, and when each applies→TypeScript and Zod in production: the validation layer that prevents incidents→Architecture for speed: how technical decisions affect conversion and CAC→Component library decisions: build, buy, or extend→When to rebuild vs. refactor: the decision framework for $5M–$20M ARR companies→Headless commerce vs. Shopify Plus: the architecture tradeoffs at scale→Technical debt audit for SaaS: how to find and quantify what's slowing you down→Multi-tenant SaaS architecture: isolation models and their tradeoffs→Internal tools vs. off-the-shelf: the build-vs-buy framework for SaaS companies

If your stack is accumulating constraints faster than your team can clear them.

The most useful first step is a conversation about what you are seeing and where the pressure points are. I can usually tell in 30 minutes whether this is a targeted fix or a deeper architecture problem — and what each path costs.

If you want to see how this kind of engagement runs in practice, the Meridian Analytics case study covers a full architecture engagement: the initial diagnosis, the decisions made, the trade-offs, and the outcome.

Start a conversation →See an example engagement

Based in Kamloops, BC. Works with SaaS and commerce companies across Canada and North America. Everything is remote.