How One Person Built Production-Grade Distributed Infrastructure With an AI-Augmented Methodology

By Aaron Gammon · Founder, Inferrex · June 2026

This is a personal piece, and I want to be careful about what it is and isn't. It is not a how-to, and it deliberately doesn't hand over my methodology — that's the proprietary part, the factory rather than the product, and I sell the outputs of the factory, not the blueprints. What it is: an honest account of the fact that one person built something that used to require a team, what made that possible, and why I think it matters beyond me.

I'm wary of founder-origin stories that flatter the founder. So where I make a claim about what got built, it's verifiable against the live platform, and the figures that move live at inferrex.com/claims rather than in this essay.

I spent eighteen years in enterprise software sales — marketing automation, RPA, data protection, backup and recovery — carried into organisations like Shell, Barclays, British Airways, and Emirates. I didn't finish school; the environment I grew up in made that impossible, and I learned by doing instead, formalising it much later with a Level 7 in senior management. For most of my career I sold the software other people built. I was on the commercial side of the glass, watching engineering happen on the other side of it.

What that vantage point gave me, without my realising it at the time, was a very long education in what breaks. I sat in the rooms where integrations failed, where the consultant got hired to fix the thing that shouldn't have broken, where the renewal got threatened because last year's mapping had snapped when a provider changed. I didn't know how to build the fix. But I knew, in unusual detail, exactly what the fix needed to do — because I'd spent two decades watching the absence of it cost people money and sleep.

When I finally sat down to build, I wasn't starting from "what's technically interesting." I was starting from "I have watched this specific thing fail a thousand times and I know precisely what would have to be true to stop it." That turns out to be a much better place to start from than most.

Let me be precise about this, because the phrase has been cheapened and I don't want to be lumped in with what it's been cheapened into.

AI-augmented development, as I practise it, is not "ask a chatbot to write some code and paste it in." That's vibe-coding, and it produces exactly what you'd expect — plausible-looking software that falls apart under contact with production. What I built is a codified method: a disciplined way of working in which AI is a force multiplier on top of a rigorous engineering structure, not a replacement for the structure. The discipline is the thing that makes the AI useful. Without it, AI just helps you generate mess faster.

I'm not going to publish the method — that's the genuinely proprietary asset, and the whole point of a factory is that you sell what it makes, not the schematics for the machines. But I'll happily describe its shape, because the shape is the part that's instructive: it's the marriage of AI's leverage with an almost obsessive engineering discipline, and it's the discipline half that nobody expects from a self-taught salesperson and that actually did the work.

Here is the part I'm proud of, and it's not the AI. It's the rules I refused to break.

Manifest-driven everything. Nothing that a machine can generate is written by hand. The infrastructure, the routes, the database schema, the service wiring, the generated files — all of it derives from manifests as a single source of truth. You change the manifest and regenerate; you never hand-edit the output. This is the discipline that lets one person hold a sixteen-service system in their head, because there isn't sixteen services' worth of hand-written sprawl to hold — there's a set of manifests and a generator.

No stubs, no placeholders, no mocks. If something isn't implemented, it isn't faked to look implemented. It's either built properly or it throws, loudly. The single fastest way a solo-built system rots is a thousand little "I'll come back to this" stubs that quietly become load-bearing. I don't allow them.

No commented-out code, and production only. Dead code gets deleted, not parked. There are no dev-only shortcuts, no "we'll harden it later" endpoints — everything is built to ship. When you're the only person, the temptation to leave yourself convenient messes is enormous, and every one of them is a debt your future self pays with interest.

None of that is glamorous. None of it is the AI. It's the boring, ruthless discipline that most people assume a non-engineer wouldn't have — and it's precisely what separated this from a demo that impresses for ten minutes and collapses in week two. The AI gave me leverage. The discipline made the leverage compound instead of accumulate as risk.

I'll keep this to outcomes, because the point isn't to itemise and brag — it's to establish that "production-grade" is a literal claim, not a flattering adjective.

Inferrex is a platform of sixteen independently-scaling microservices on Kubernetes, generated from manifests, that points at any API, infers its schema, classifies every field by business meaning, builds a golden record, and repairs itself when a provider changes. It reads seven API protocols. It runs across four deployment modes from multi-tenant cloud to fully air-gapped, on its own AI models. It has a real billing system, real access control, real audit logging, real compliance handling — the unglamorous load-bearing parts that separate a product from a prototype. The current, live figures — service counts, codegen generators, lines of code, corpus size, model accuracy — are all published and dated at inferrex.com/claims, because I'd rather you check them than take my adjective for it.

That's not a weekend project that demos well. It's infrastructure, built by one person, that other companies are preparing to embed in their own products.

Here's the part that's bigger than me, and the reason I think this story is worth telling at all.

For the whole history of software, there was a hard floor on how much one person could build, set by how much code a human can write and hold in their head. A platform like this sat far above that floor — it required a team, because it required more hands than one person has. That floor has moved. AI didn't remove the need for engineering judgement, discipline, and taste — if anything it raised the premium on those, because they're now the scarce inputs. What it removed was the need for a team's worth of typing to express that judgement. One person with deep domain knowledge, a rigorous method, and AI leverage can now occupy a space that used to need ten.

That's the thesis, and notice what it does and doesn't claim. It does not say "anyone can build anything now" — most of what makes this work is the eighteen years of knowing what breaks and the refusal to cut corners, neither of which AI supplies. It says the binding constraint changed. It used to be hands. Now it's judgement and discipline. The people who win in this new regime aren't the ones who can prompt a model fastest; they're the ones who pair real domain depth with the discipline to make AI's leverage compound rather than collapse.

If the binding constraint on building software has shifted from team size to judgement and discipline, a lot follows.

It means deep domain knowledge — the unglamorous, hard-won understanding of a specific problem — becomes more valuable, not less, because it's the input AI can't fake. It means small, sharp operators can credibly take on problems that used to be the exclusive territory of large, well-funded teams. And it means the moat moves: it's no longer "we have more engineers than you," because engineer-count is a weaker advantage when one disciplined person with leverage can match a team's output. The moat becomes the method and the domain depth — which is exactly why I keep the method proprietary and sell what it produces.

I'm aware of how this sounds coming from a sample size of one. Maybe I'm an outlier. But I don't think the underlying shift is in doubt, even if my particular instance of it is. The floor has moved. The only real question is who notices, and who keeps assuming the old constraints still bind.

I built Inferrex the way I did partly out of necessity — I was one person — and partly out of conviction, because I'd spent eighteen years watching fragile, hand-built, undocumented systems quietly break and quietly get people blamed. The discipline isn't a personality quirk. It's the whole point: I'm building the opposite of the systems I watched fail, in the way I work as much as in the product.

The product is the doctrine made executable. And the fact that one person could make it executable at all is, I think, the most interesting thing about the whole exercise — more interesting than any feature.