The whole company is one person and one graphics card.
Thirteen projects in Linear. Three live products taking money, a fourth in production and posting daily for a paying customer. Every pull request reviewed, every deploy approved, every invoice sent from the same desk in Oakland. The workforce that makes this possible is software: agents that research, draft, publish, test, and audit while I sleep.
This is the ops reality of that arrangement. Not the vision-deck version. The version with the failure modes in it, because the failure modes are where all the actual lessons live.
Where this came from
I spent twenty-plus years in high-end audio, from a retail floor in Berkeley to running Sonus Faber for North America. The entire discipline of that industry is chasing a clean signal through a noisy chain. Somewhere around year eighteen I realized that was also a fair description of running a company, and that the noisy chain in my life was no longer analog.
So now I build software. Alone, in the org-chart sense. Not alone in any sense that matters at 3am, when the research agents are reading trade publications and the compose pipeline is drafting posts and the test suites are running against last night's merges.
The shape of the operation
The portfolio, plainly: a marketing engine for HiFi retailers, a real-time dashboard for traders and investors, an info hub for AI hardware that ships an automated daily brief, and a social-posting engine that drafts and publishes every day for a high-end audio dealer, customer #1, who pays real money and expects real posts.
All of it runs through one Windows workstation with a single RTX 5090, and one control plane I call the captain dashboard. Nineteen managed apps live under it: image generation, video generation, 3D, training, transcription, local LLM serving, the works. The dashboard knows what is running, what VRAM each process holds, and what is queued.
That last part matters more than it sounds like it should.
One GPU, many agents, one mutex
Here is the problem nobody warns you about: agents do not politely take turns. If three pipelines each decide they need the GPU at the same moment, you do not get three slow jobs. You get out-of-memory crashes, half-loaded models, and a card that reports full allocation with nothing useful running on it.
The fix was embarrassingly old-fashioned. A mutex. Any job tagged gpu-heavy has to acquire the lock before it touches the card, and everything else queues. My agents wait for VRAM the way engineers wait for the coffee machine: grumbling, in an orderly line, one at a time.
The second fix was hygiene. A force-killed process on Windows will happily die while its GPU allocation lives on as a ghost. So every session starts the same way: check the card, find the zombies, kill them by process path rather than by port, because a crashed process holds memory without listening on anything. It is the least glamorous ritual in the entire company and skipping it costs more time than any other single mistake I make.
What the agents actually do
The honest list, not the marketing list:
- Research. Every night, agents read the publications that matter to each product's audience and pull out what changed. For the posting engine that means the customer's industry gets watched while he sleeps.- Drafting. Posts, briefs, code, migrations. Drafts, plural, because most of them die in review and that is the system working as designed.- Testing and auditing. Suites run on merge. Beyond that, I have pointed an agent swarm at my own production SaaS as auditors, and they found real problems I could not see. That story deserves its own writeup, and it is getting one.- Publishing with verification. The posting engine does not trust itself. A successful API response is a receipt for the request, not proof the post exists, so a reconcile step checks the platform's actual state afterward.- Remembering. This one took me too long. Agents kept re-learning things other agents had already learned, so I built memsearch, a shared memory layer with semantic and keyword search over roughly 450 memory files. An agent that hits a known trap now finds the note the last agent left about it.## What the human keeps Three things do not get delegated, and the list is deliberate.
- Approvals. Nothing customer-facing goes live without my word. The posting engine drafts, but a human taps approve on every single post. This is not a limitation we apologize for, it is a design decision, and it is the one my paying customer cares about most.- Taste. An agent can tell you a draft is grammatical and grounded. It cannot tell you the draft is boring, or that it sounds like everyone else's feed. Taste is the moat, and taste does not batch.- Accountability. When something breaks, the customer emails a person, and the person answers. There is no tier-one support bot between customer #1 and me. If the pipeline drops his posts, he hears from me plainly, with the fix in the same breath.My stated operating rule for the whole company: consult one dashboard daily, handle only the items that genuinely require a human, and when I have an idea, fire it and have it driven to completion. Most days that holds. The days it does not hold are the next section. ## What it costs, honestly The free key incident. For a stretch of production time, the posting engine's LLM calls ran on a free-tier API key rate-limited to 5 requests per minute, while the paid organization account, credits loaded and ready, sat completely idle. The symptom was a storm of 429s that looked exactly like an architecture problem. I went looking for concurrency bugs and backpressure design flaws. The actual fix was checking which key production was holding. Lesson: when an agent workforce misbehaves, check the boring thing first, because the boring thing is not embarrassed to be the answer. The gate that rejected everything. The posting engine has a factual gate: drafts must ground their claims in a source before they earn the feed. At one point that gate was rejecting 100% of drafts. Not most. All. It turned out to be grading full captions against an 84-character headline, so any caption that actually said something failed, and the captions that said nothing scored best. A quality gate that rewards emptiness is worse than no gate. We fixed it the boring way: give the gate the full source text, not the teaser. The metric that survived. After enough incidents you stop trusting intermediate signals. Queues can look healthy while nothing ships. Dashboards can say cadence satisfied while zero posts land. The only number I fully believe anymore, for a billable account, is landed greater than zero. Did the thing actually appear on the platform today. Everything upstream of that answer is a hypothesis. The real bottleneck. People assume the constraint on a one-person software company is generation capacity. It is not, and it has not been for a while. Agents do not get tired. The bottleneck is review discipline: my ability to read what they produced with full attention, catch the subtle wrongness, and keep the approval step from decaying into a rubber stamp. The day approvals become reflexive is the day the whole model quietly fails, and no alarm fires for that one. ## If you are considering this
- Build the control plane before you build the workforce. One dashboard that answers what is running and what is stuck is worth more than the next three agents.- Serialize your scarce resource explicitly. One GPU means one mutex. Hoping the schedulers will not collide is not a strategy, it is a countdown.- Give the agents shared memory early. Every lesson learned by exactly one agent is a lesson your company will pay for again.- Instrument absence, not just failure. Errors page you. Silence does not, and silence is the expensive one.- Keep approvals, taste, and accountability human, and be suspicious of anyone who tells you the third one scales.None of this is a pitch. The products named here are just the systems being run, and the arrangement has cost me real production incidents, several days of chasing phantom architecture problems, and one deeply humbling conversation with a rate limiter. But the arrangement also works. One person, one GPU, thirteen projects, and a workforce that never asks for a standup. The fun part starts now.
Top comments (0)