There is a single principle under everything here: always optimise for the solution to the problem, never for anything else. Not a favourite framework, not what is fashionable, not what was easy to demo. The right technology on the right infrastructure for the actual job, built to hold the scale it will one day have to carry.
The industry's "full-stack developer" writes both the front and the back. I mean something much wider. I design a system from the outside in: who has to interact with it, how it solves their problem, and then all the way down to the infrastructure it runs on. Normally that span is nine different people. Here it is one, with no translation loss between the roles.
The whole span, in one hand: chose the stack and the architecture, built the entire UX flows, made the interface, wrote the code, and configured the servers it all ran on. From infrastructure to pixel to business strategy, without a handoff in between.
When a system has to hold, the work is almost never "build another page" or "tweak a function." It is two deeper choices, working together: the tech stack it is built from, and the infrastructure it runs on. And here is the part the industry keeps getting wrong: neither choice has a universal right answer. Every pattern below is something I build both ways — the problem decides, never the preference. Anyone selling you the same architecture for every problem is selling their comfort zone, not your system.
Split services scale by part and isolate the hot paths — right when the load is uneven. But a monolith is often the smarter shape: my Pillar Two engine is deliberately monolithic, because splitting it would add seams and buy nothing. The pattern follows the problem.
Several stores when each earns its place — relational, vector, cache — and one when it covers the job. I recently removed a graph database from a system: it saved two to three milliseconds in a stack that answers in seconds. Complexity has to pay rent, or it goes.
Deployed near users when the users are everywhere. For a single-market system, global distribution is pure cost and complexity. Reach is designed to the actual market — with the door open for the day it grows.
Sometimes one well-run server is the whole answer. Sometimes serverless, sometimes a fleet of specialised parts — often a blend. The load pattern and the cost of failure decide the shape, never habit.
The stack chosen for the load and the job, not for fashion. The wrong choice here quietly caps a system for years.
Built so the next ten changes are cheap, not catastrophic — which sometimes means the humble choice today. The build should make tomorrow easier, not lock you into it.
The doctrine above, applied to growth: a system should only carry the complexity its current scale justifies — version one is not built for a million users, and you should not pay for one. But the jumps are designed for before they are needed: the architecture knows where its seams would split, long before anything is split. Note the unit: concurrent users, not total — a thousand people hitting a system at the same instant can sit behind a hundred thousand accounts. The point is that no rung ever arrives as a surprise. Each jump is a planned move, priced in advance, not an emergency rebuild.
A clean monolith or modest split, one region, sensible defaults. Fast to ship, easy to reason about.
Caching, read replicas, queues for the heavy work. The first seams where the architecture is designed to split.
Services split along the hot paths, multi-database by job, autoscaling. Load isolated so one part can't sink the rest.
Globally distributed, deployed near users, multi-region data. A plan that exists on day one, not a panic later.
We are in a discount era. Models are cheap right now, far cheaper than the tokens actually cost, so most builders reach for the biggest model for every job and never feel the bill. That works until prices normalise. Then a system that wastes tokens becomes expensive exactly when it starts to win. I build the opposite way. The rules are simple, and they converge on one discipline: cost as a design constraint. No system should cost more to run than the problem it solves justifies — and the same choices that hold the bill down are the ones that make it reliable.
The system comes first. An LLM is applied only where it adds genuine value, and never where plain executable code solves the problem more simply and reliably.
Pick a model trained for the actual job, not the most famous one. The best fit for a task is rarely the biggest model on the leaderboard.
Most jobs do not need a genius. A leaner model with the right tools beats a frontier model used as a sledgehammer, on cost and often on reliability.
Systems designed to waste tokens are the quiet killer of margins at scale. Keep the context lean and deliberate.
The doctrine, running — and measured properly, because a percentage without a method is marketing: ten real questions against a production codebase, answered two ways by three model tiers. With the knowledge pre-structured and exposed where the model needs it: sixty-six to seventy-six per cent fewer tokens and forty per cent faster than the same models reading raw source, with quality within a few points on a hundred-point scale — judged by two independent frontier models. At scale that is the difference between a system that stays profitable and one that dies of its own running costs.
To cover these disciplines properly, an organisation does not hire one or two people. It hires seven to twelve, and it usually starts with a project lead who owns the brief and passes it down the line. Each specialist has real depth, but they speak different vocabularies, and not one is trained to transfer what they know so the next person receives it intact. Every seam is a place the work can leak.
Each person compresses what they know so the next can use it. Something is lost at every step: context, intent, the reason behind a decision. The most expensive leak is the one nobody sees happen.
A team works in series, with dependencies: the designer waits on the strategist, the developer on the designer. One head runs all disciplines in parallel, and the decisions happen together rather than across briefs.
It takes only one specialist off their best day to drag the whole result down. Across seven to twelve people that is a dozen points of failure. With one operator, it is one.
One head removes the chain. No handoffs, no leakage, nothing lost in translation between layers that were never built to speak to each other. With one operator, the seams that leak simply do not exist.
A system built this way does more than scale. It is built to stand apart and to keep standing: the architecture is sound, the model use is durable, and the whole thing was designed for the problem rather than the trend. That is the doctrine, and it is the same one behind every system in the house and behind every commission.
// designed for the problem, not the trend, so it stands apart and keeps standing