Shipping a site for a small business and watching it go live

There are few moments more clarifying than changing a DNS record. You stare at the A record, triple-check the IP address, and click save. For the next few minutes—or hours—you are in a state of professional purgatory, constantly refreshing, clearing your cache, waiting for the digital world to acknowledge a change you made.

When it’s for a large enterprise, that change is buffered by teams and process. When it’s for a local florist or family-owned garage, you are the entire department. The success or failure lands squarely on you, and the phone will ring if it’s the latter.

The Unforgiving Feedback Loop

My early career was filled with these moments. Building a simple five-page site for a small business is a rite of passage, but the technical simplicity masks the immense responsibility. For that business, the website is their digital front door. If it's down, they are effectively closed.

The feedback loop is direct and unforgiving. It isn’t a bug ticket in a queue. It’s a text from the owner on a Saturday morning: "The contact form isn't working." You realize every submission is a potential job, real revenue now vanishing because of a misconfigured setting. This raw, immediate feedback is the essence of what a mature engineering culture formalizes. Instead of an anxious client, you define Service Level Objectives (SLOs), but as the engineers at Google explain in their foundational book on Site Reliability Engineering, the principle is identical: a promise to the user has been broken. You fix it. Now.

This experience recalibrates your understanding of production. It’s not an abstract concept; it’s a system people depend on. It taught me to respect monitoring, backups, and solid deployment automation—the boring parts that actually work at 3am.

Durability Through Determinism

These early projects cemented a core architectural principle: a system should be as simple and deterministic as its requirements allow. For a small business site, the correct choice was almost always a static site generator pushing flat files to a content delivery network (CDN). No database, no complex server-side rendering, no single point of failure.

The system was completely deterministic. A given source file produced the exact same HTML page every time. It’s an idea practitioner Dan McKinley famously articulated in his essay "Choose Boring Technology." You trade your own desire to experiment with the latest framework for their need to have a phone that rings. While modern platforms make dynamic applications incredibly robust, the principle of minimizing your failure surface area remains the most durable architectural choice. It is a trade-off in favor of durability, and it is always the right one for foundational systems.

From Static Sites to Agentic Systems

Today, I design systems that are far more complex and often intentionally non-deterministic. We build pipelines where LLM agents are expected to handle ambiguity, to produce novel outputs from messy inputs. The world of predictable, static HTML seems distant, but the lessons are the same.

Andrej Karpathy helped define this industry shift in his post on "Software 2.0," describing a new paradigm where we build systems by training models on data instead of writing explicit code. But this new, probabilistic layer requires an even more robust and deterministic foundation to succeed in production. The lessons from that small business site are the bedrock on which these new systems must be built.

Grounding AI in Production Reality

An LLM agent that routes customer support queries is, in its own way, a new kind of contact form. If it fails silently, the business loses opportunities just as surely as if the SMTP server was down. The problem is that the failure modes are harder to detect. The agent might not be "down"; it might just be performing poorly, giving subtly wrong answers, or failing to escalate critical issues. The unforgiving feedback loop is still there, but it’s slower and more insidious.

This is why observability in AI systems is so difficult and so important. We need to measure not just uptime, but semantic correctness. We need evaluation pipelines that act as the modern equivalent of that simple uptime ping, constantly checking if the agent is still sane and serving its business purpose. We must ground our agentic systems in deterministic automation that can scaffold, constrain, and monitor their behavior.

Core Principles for Building Today

That feeling of watching a DNS record propagate never really leaves you. It’s the feeling of direct ownership. Whether you're deploying a five-page static site or a fleet of AI agents, the core responsibility is the same. What holds up in production are a few durable ideas.

• Build probabilistic systems on deterministic foundations. Use reliable, predictable components as the bedrock. Reserve the complexity and non-determinism only for the specific parts of the problem that truly require it. Agents need guardrails.
• Trace feedback loops to human outcomes. Whether it's a broken form or a subtly biased agent, map the system's behavior back to its real-world impact. This is how you define what "working" actually means.
• Instrument for semantic correctness, not just uptime. For agentic systems, "online" is not enough. You must have automated checks to ensure the *quality* and *correctness* of the agent's output over time.
• Minimize the failure surface area. Before adding a new database, a new service, or a new model, be honest about the new ways it can break. The simplest architecture that meets the need is the most reliable.