The One-Person Company: Kubernetes' Ideal Blueprint and Real-World Trade-offs

Perfect is the enemy of good. — Voltaire

A preface: this is the second post in the “One-Person Technology Company” series. The OPC (One Person Company) idea is all the rage right now, so I thought I’d try it on for size — to see what could actually come of spending my weekends seriously on the kinds of things only a real technology company could pull off. This doesn’t mean I’m going full-time founder; I consider myself a perpetual entrepreneur, and a nine-to-five has never been my cage. Through this process I want to learn the boundaries of AI — and my own.

The series will document the whole journey 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; it’s a field journal with the thinking left in.

The previous post sorted out the most basic security architecture. This one gets hands-on: the story of how reality beat my ideals senseless while I was building infrastructure for my imaginary “one-person company.”

I. Prologue: A Shelved Design Document

Every engineer who has touched infrastructure has a “perfect architect” living inside them.

When I decided to spend weekend after weekend building the foundational software stack of a “one-person company” driven by AI, my first instinct was to stand up an EKS cluster and manage resources with ACK/KRO. Readers unfamiliar with ACK/KRO can go run a Gemini deep research on it themselves.

So on the morning of Saturday, January 31st, I spent two hours with Claude Code’s help banging out an extremely detailed infrastructure design document. Four layers of architecture, service mesh, GitOps, custom resource orchestration, observability — the works. The document ran to hundreds of lines, from VPC subnet partitioning to custom Kubernetes CRD abstractions, nothing left out. Honestly, without Claude Code this document would have taken two or three weeks to write; now it took a few days. That itself planted a seed: AI makes “design” extraordinarily efficient — and makes “deferring implementation” all the more rational.

Then, after repeatedly discussing cost and extreme money-saving options with Claude Code, I dropped it into a directory called specs/future.

Yes. future. Not current, not active — future. The most dignified way a programmer has ever said “I flaked; you do you.”

Behind that decision there were technical considerations and economic ones: it wasn’t worth a hundred-plus dollars a month just to run an experiment. In this post I want to lay out that “ideal blueprint” in full and look at it with you: what it designed, why it got shelved, and what that whole episode taught me.

Imagine: if you started an independent company tomorrow and had to build infrastructure for your product, what would you choose? Go all-in on big-company standards from day one, or take a lightweight path and get moving first?

There’s no standard answer to that question, but I can share my agonizing.

II. The Ideal Blueprint: An Enterprise-Grade Four-Layer Architecture

Let me unfold that design document first and show you what “the ideal state” actually looks like.

The Four-Layer Model

The whole architecture uses a classic four-layer design, from bottom to top:

• Layer 1 is the foundation: VPC, Kubernetes cluster, IAM, DNS, TLS, encryption keys, all managed directly by Pulumi.
• Layer 2 is the middleware layer: Istio service mesh, ArgoCD GitOps, DNS/secret automation, several AWS resource controllers (ACK), Grafana observability.
• Layer 3 is the abstract building blocks: custom resource definitions that encapsulate databases, storage, functions, and API gateways — a few lines of YAML pulls up every dependency automatically.
• Layer 4 is the “golden path”: assembling the Layer 3 blocks into one-click deployments of a complete container service or serverless endpoint.

The core philosophy is three words: declarative, self-service, least privilege.

A Quick Example

Suppose I need to deploy a backend service with a database. Under this system, I only need to provide two short YAML declarations.

The first declares a PostgreSQL database:

apiVersion: example.io/v1alpha1
kind: AppDb
spec:
  name: my-database
  engine: postgres
  instanceClass: db.t4g.micro
  storageGb: 20
  version: "16"

The second declares a containerized service that references the database above:

apiVersion: example.io/v1alpha1
kind: AppService
spec:
  name: my-api
  image: my-registry/my-api:v1.0.0
  port: 8080
  replicas: 2
  resources:
    cpu: "250m"
    memory: "512Mi"
  healthCheck:
    path: /health
  ingress:
    hostname: my-api.example.io
  env:
    DB_HOST: { secretRef: my-database-credentials, key: host }

Behind the scenes the platform handles a dozen things automatically: creating the database instance, configuring security groups, generating credentials, deploying the application, setting up routing and DNS. Exactly the same playbook as a big company’s internal platform. And yes — AWS EKS today not only provides full Kubernetes cluster management, but ships with resource controllers (ACK controllers) that automatically manage all manner of AWS resources.