Running a Product Solo With AI: What Actually Broke
In short
I run a small software product on my own, and an AI agent does most of the typing. The public result is qvib.pro: roughly 1,500 URLs in the sitemap — 136 English guides, 571 English reference cards, a Russian mirror of both, a news feed, a paid engine, an affiliate layer and billing. No team, no contractors.
What that setup actually needs is not better prompts. It needs a verification habit, because the agent's failure mode is rarely bad code. It is plausible code that was never run. The five things that broke on me were a hot-deploy path that dies the moment a new npm dependency appears, two parallel sessions editing the same prerender script, URL slugs that stopped matching filenames once the site went bilingual, inline HTML that silently ate a markdown block, and a project-id collision that pointed one install at another install's data.
Every one of them passed the agent's own "done." None of them passed a script.
What got built, and what it actually is
Concrete, because vague claims about solo AI productivity are the whole problem with this genre.
The site is a React single-page app with a prerender step, a Node backend, Postgres, and Docker Compose on one VPS. On top sit the parts that make it a product rather than a blog: a packaged agent engine you can buy and install, a licence and install flow, a referral system with per-partner commission, coupons, comments and reactions, a scheduled news pipeline, and a bilingual content tree.
The scale is real but boring: about 1,500 indexable URLs, most of them reference cards generated against one JSON schema. That is exactly the shape of work an agent is good at. Nothing here is a distributed system. If your product is a trading engine or a multi-tenant data plane, discount most of what follows.
Cost, as of July 2026: a Claude Max plan starts at $100/month and Pro is $20/month on the official pricing page, plus a VPS. That is the entire infrastructure line. The expensive resource is my attention, not tokens.
What the AI did well
Three categories, honestly ranked.
Volume with a fixed shape. Producing 571 reference cards against a schema, then re-validating all of them after the schema changed, is the single highest-leverage thing an agent does. Non-interactive runs make this cheap: claude -p "..." --output-format json in a loop over a file list, which Anthropic documents under non-interactive mode.
Reading code I did not write, or wrote and forgot. Asking the agent to explain my own prerender logic before changing it was consistently faster than reading it myself.
Wide mechanical migrations. Going bilingual touched routing, sitemaps, hreflang, schema markup and every content loader — a hundred small edits with one rule. An agent does that in an afternoon and I do it in a week.
Where it was mediocre: anything where the correct answer depended on something not in the repo. Pricing behaviour, what a customer actually meant, why a design decision was made two months ago. It will produce an answer. The answer will be well-argued and wrong.
What broke, with specifics
| What broke | Symptom in production | Why the agent called it done | The fix that stuck |
|---|---|---|---|
| Hot-deploy path vs. new dependencies | Backend crash-looped after a deploy that added one npm package | The bind-mounted dist updated fine and the local build passed; the container's node_modules never got the new package |
Any diff touching package.json is routed to a full rebuild, enforced by a pre-deploy check rather than a note in the docs |
| Two sessions, one file | Half the English pages shipped as empty shells and got indexed that way | Two parallel runs both "improved" the prerender generator; the second overwrote the first's route table, and each session's own tests passed | One writer per file per run; parallel sessions get separate git worktrees |
| Slug drift after going bilingual | Internal links returned 404 on live pages that looked correct in the repo | English URLs are derived from English titles, but the files on disk keep their original names — the agent wrote links from filenames | A link checker that curls every internal URL and fails the build on any non-200 |
| Multi-line inline HTML in markdown | An infographic rendered as escaped tags, and the rest of the article vanished | The renderer closes the HTML block at the first blank line; the agent's check was "the file exists and parses as markdown" | Inline HTML must be a single line; the content validator rejects anything else |
| Project-id collision on install | Two installs on the same host shared state, and one bundle URL was written without its /api prefix |
The id was derived from the folder name, which reviewed as sensible and passed every unit test | Random suffix plus an install-time assertion that the id is unused |
The near-miss worth naming: an agent cleaning a build directory composed a path that resolved to the repository root and ran rm -rf against it. Nothing was lost — a PreToolUse hook denies destructive rm on relative roots before the command runs. That is the argument for enforced guardrails over advisory ones: a written instruction to be careful had already failed to stop it.
The rules that stopped it breaking again
- Every task ends in a command, not a claim. Anthropic's own guidance names this failure the "trust-then-verify gap" and puts it plainly: give Claude a check it can run — tests, a build exit code, a screenshot diff. If I cannot name the command that proves the task is done, the task is not specified yet.
- Anything that must hold every time is a hook, not an instruction. Hooks are deterministic; CLAUDE.md is advisory and gets diluted as the file grows. Destructive commands, secret scanning and the deploy gate are hooks.
- Two or three parallel sessions, not ten. Beyond that I hit rate limits, and more importantly I stop being able to review what came back. Parallelism is capped by my reading speed, not the tooling.
- A reviewer that never saw the plan. A fresh subagent reading only the diff catches things the implementing session is structurally blind to. The tradeoff is real: a reviewer told to find gaps will find some even in sound work, so it gets told to report correctness gaps only. More on that split in multi-angle review.
- The production deploy is gated by a human, because the blast radius is the one thing the agent cannot estimate.
- Loops are bounded. An agent told to "keep fixing until it's clean" will iterate forever on a check it cannot satisfy. Cycles get an explicit exit condition and a cap — the pattern I use is in bounded agent cycles.
The part nobody warns you about
Building is no longer the bottleneck. Distribution still is, and AI does not touch it.
Roughly 1,500 pages are live. Organic search sends about two dozen visits a month. Yandex's site quality index for the domain reads zero. Technical SEO — schema, prerendering, Core Web Vitals, internal linking — was fixable in a couple of weekends with an agent, and I fixed it. Domain authority was not, and will not be: it is a function of other people linking to you over time.
So the honest version of the story is: the agent removes a bottleneck you probably did not have. If your plan is "publish a lot, get traffic," you will publish a lot. That is a different outcome from getting traffic, and finding it out at 1,500 pages is more expensive than finding it out at 30.
What I would not hand to an agent
- Pricing, refunds, and anything that moves money. Not a capability question. It is a question of who is accountable when it is wrong, and the answer is never the model.
- Irreversible operations without a dry run. Migrations, bulk deletes, mail-outs. The agent writes them; I read the plan and run them.
- The public claim. If a page says a feature works, I check that it works.
- The auth boundary. Agents write plausible authorization code with a subtly wrong default. Every change touching sessions or permissions gets read line by line.
- Deciding what not to build. The agent builds whatever I name, which makes the naming the actual job. Most of the value I added this year was in tasks I deleted.
FAQ
Can one person really run a software product with AI agents?
Yes, for a certain shape of product: content-heavy, lightly multi-tenant, with a small surface of irreversible operations. The agent handles breadth well. What does not scale down to one person is anything requiring accountability — compliance sign-off, on-call for a customer's integration, a decision that costs money if it is wrong. That is where the ceiling shows up first.
What actually breaks when you run a product solo with AI?
Not algorithms. Boundaries. In my case: deployment paths that behave differently in production, two sessions writing the same file, and identifiers derived from something environment-specific. All five failures shared one property — the code was correct in isolation and wrong in context, which is exactly the class of error an agent's self-check does not cover.
How much does it cost to run a product solo with AI?
For my setup, as of July 2026: a Claude subscription (Pro at $20/month, Max from $100/month) plus a single VPS. API-metered usage costs more than a subscription if you run agents heavily; Anthropic documents the tradeoff under managing costs. The line item that surprised people I have talked to is not tokens — it is the time spent verifying output.
Do I still need to know how to code?
You need to be able to read code and, more importantly, to know what "working" means for your system and how to check it. I have not typed most of this codebase, but every failure in the table above was caught by a human noticing that a claim and a behaviour did not match. If you cannot form that judgement, you are not running a product solo — you are hoping.
How many agents should I run in parallel?
Two or three, in separate worktrees, on tasks that do not touch the same files. The limit is not the tool. It is that unreviewed agent output accumulates faster than you can read it, and the merge conflicts between parallel sessions are worse than the ones between people, because neither session knows the other exists.