The One-Person Company: Infrastructure

A journey of a thousand miles begins beneath one’s feet. — Laozi, Tao Te Ching

Author’s note: This is the first installment in the “One-Person Tech Company” series. The concept of OPC (One Person Company) is all the rage right now, so I thought I’d give it a try too — to see what can really be built if you seriously use your weekends to do the kind of work that normally takes a whole tech company. This doesn’t mean I’m going into full-time entrepreneurship; I consider myself a founder who’s always on the journey — a nine-to-five has never been my shackle. Through this process, I want to understand the boundaries of AI, and my own boundaries as well.

The whole series will chronicle my full process of building a complete technology stack from scratch — from infrastructure, to networking and runtime, to the core framework, to application services. This is not a tutorial, but a field journal complete with the thinking process.

Let me start with a fact that even I find hard to believe: the entire tech stack you’re about to read about — a core framework of 20,000 lines of Rust, several thousand lines of TypeScript infrastructure definitions, a complete security and audit architecture — was coaxed out of Claude Code in a single weekend. It includes the foundational infra definitions, a serverless framework, private repositories for Rust and TypeScript, and a PPT tool that’s still being refined.

Three years ago, this would have taken a team of 3–5 people several months. Now: one person, one cup of coffee, one AI coding buddy — start Friday night, wrap up Sunday night. This isn’t cost reduction or efficiency gains; it’s a leap across dimensions.

If you’re still on the fence about whether AI coding is actually reliable, this essay is my answer sheet.

1. Why the First Line of Code Shouldn’t Be Product Code

Have you ever had this experience: you excitedly start a new project, can’t wait to write the first line of business logic, and then a few months later realize you’ve fallen into a deep pit — secrets scattered everywhere, environments bleeding into each other, a monthly bill that makes your heart sink, and when something goes wrong, you can’t trace it at all?

This is the indie developer’s classic “board the train first, buy the ticket later” mindset. When you’re doing everything alone, the instinct is to go straight for the point — just ship the product first. Infrastructure? Deal with it once you have users. Security? I’m just one person — who’d bother attacking me? Auditing? That’s a concern for the big companies.

And yet, precisely because you’re one person, infrastructure matters even more.

Big companies have dedicated SRE teams, security teams, and FinOps teams, each minding their own patch. In a one-person company, if infrastructure isn’t planned properly from the start, then every single day afterwards you’re paying down technical debt — and you have no teammates to share the burden.

Going one level deeper: good infrastructure is a force multiplier. It lets you confidently hand more and more work to AI and automated pipelines without fear that one slip of the hand will blow up the entire system. This is especially critical in the age of AI coding — Claude Code helps you produce code at ten times the speed, but without reliable security boundaries and an audit system, you can crash and burn at ten times the speed too.

So the first thing I did was not write product code, but concentrate my energy on laying the foundation for the entire technology stack. With an AI partner like Claude Code, this process is far faster than you’d imagine — but only if you know what you want, rather than just letting the AI build whatever it feels like.

2. Starting from First Principles: What an Indie Developer Needs

Back to the most fundamental question. When one person uses AI to sustain a tech company, what exactly does the infrastructure layer need to solve?

Strip away all the fancy jargon, and the core requirements come down to four:

First, a security boundary. A single slip or one leaked secret must not destroy everything I have. I need a safety net so that even if I make a mistake, the blast radius stays within a small circle.

Second, traceability. When something goes wrong, I need to know what happened, who did it, and when. When you’re one person, “who” might just be yourself and the CI/CD pipeline — but precisely for that reason, traceability matters even more. You can’t possibly remember every command you typed three months ago.

Third, controllable costs. Indie developers don’t have VC money as a backstop; every cent must be spent where it counts. But “saving money” isn’t the same as “being stingy” — spending what should be spent is about saving ten times the time and energy down the road.

Fourth, the ability to grow. Today it’s one person; tomorrow it might be two, or five. Infrastructure can’t be locked into “single-machine mode.” When new people join, you just add a user, assign a permission group, and you’re done — rather than tearing down the entire security system and rebuilding it.

These four requirements were the starting point for my entire infrastructure design.

3. Security Architecture: Designing Permissions Like Designing a Vault

Starting with a Counterintuitive Decision

“You’re just one person — why build such a complicated permission system? Why not just use the root account and be done with it?”

This is the complaint I heard most often while doing this. At first glance it sounds reasonable — you’re one person, so separating roles is just making trouble for yourself, no?

But consider this scenario: your CI/CD pipeline, due to a bug, executes an unexpected delete operation. If the pipeline runs with admin privileges, it can delete everything — including your audit logs, your infrastructure state files, even your security configuration. But if the pipeline only has deployment permissions for a specific environment, then even if it blows up, it only blows up that one small patch.

The essence of permission design isn’t defending against “bad actors” — it’s defending against “slips of the hand.” And in the era of AI coding, “slips of the hand” are more likely than ever before — you ask Claude Code to write deployment scripts, modify config files, run database migrations, and every execution has some probability of going off the rails. The more capable the AI, the more you need a safety net.

A Tiered Permission Model

I designed a three-tier permission model. The bottom layer is the Permission Boundary, like a high wall that can’t be scaled no matter what, restricting the range that everyone (including admins) can touch. The middle layer is the Role — different roles have different operational permissions. The top layer is the Group, which determines which roles you can switch into.

There are several key ideas behind this design:

A bare user has no permissions. The user themselves can only perform the most basic self-service operations — changing credentials, setting up MFA. To do any real work, they must first switch to a specific role. This way, every operation carries an explicit “identity declaration”: this is what I’m doing, and in what role I’m doing it.