The Solo Loop.
Zero budget. Zero team. Zero backing. One maintainer. The instruments that let a hobby project answer its users like a small company — and the method that makes that claim checkable instead of aspirational.
This article is for the person who built something at night because they wanted it to exist, and then discovered the part nobody warns you about: users. They arrive with questions, environments you have never seen, and needs that are not on your roadmap. There is no budget, no support contract, no team, no on-call rotation — just you, a hobby, and the quiet guilt of an unanswered inbox. This is the practical, engineering version of the answer to that situation, drawn from a real ecosystem (this one) that operates that way: no funding, no staff, and a product line that nonetheless gives every report a first reading within ten minutes and every user a public, checkable answer. What follows is what the AI era actually changed, what it didn't, and how to turn the possibility into instruments you can build in weeks.
TL;DR — the argument in six findings
- FactThe binding constraints were never money. For a solo project the scarce resources are attention (one person's hours), continuity (memory that outlives a bad week), and legitimacy (why a stranger should trust your binary). Funding would buy help with all three — but only method can build them.
- FactFour staffed roles now exist as instruments. Triage analyst, release engineer, documentation writer and support desk can run on a cron with a human holding the verdicts: a recorded triage session in this ecosystem cost $0.0036; value-tier inference runs at roughly $0.14–$0.27 per million tokens.
- FactThe proof is running. One maintainer, 75 days: 435 commits, 67 SDD version rows, 22 machine-readable constraints, tests 262 → 1,299, releases v1.0.0 → v1.18.1 — and a support chain built in four slices in three days.
- InferenceThe maintainer's job compresses to two verbs. Decide what gets built and merge what passed the gate. Everything upstream — reading, classifying, answering, proposing patches, testing them — can run unattended, because the verdict on "does it count" stays human.
- InferenceHobby projects die of friction and guilt, not of technical failure. Instruments absorb the friction; checkable answers retire the guilt. The initial joy survives not by protecting it from users, but by not making the maintainer carry every message.
- ThesisImagination is the bet; method is the receipt. "Belief" is what makes you build the second loop before the first one pays off — but each loop must start as the smallest testable proof. Believe in the loop you can verify, and let the receipts compound.
Scarcity, restated honestly
"No money, no team" is the premise. The question is what those absences actually cost you.
Write the three constraints down as engineering requirements rather than moods. It is the difference between "I'm exhausted" and "my attention budget is 6 hours a week; what must it buy?"
| Constraint | What it really is | What it costs when unmanaged |
|---|---|---|
| No team | Attention: one person's hours, shared with a day job and a life | An inbox becomes a backlog; backlog becomes guilt; guilt kills the hobby |
| No funding | Continuity: no paid infrastructure, no contractor to take over, no budget for a bad month | Knowledge and operations live in one head; a bad week becomes an abandoned project |
| No backing | Legitimacy: no brand, no certificate, no legal entity behind the download | Users can't tell a careful project from an abandoned one; trust is spent on every update |
Notice what is not on the list: capability. A motivated solo maintainer has always been able to write the software. What they could never staff was the service around it — the reading, the answering, the verifying, the documenting, the releasing — which is exactly the hourly work that a support desk, a QA engineer and a release manager used to be paid to do. That gap is what the AI era moved.
The realistic goal for a solo project is not "become a company". It is: the service level of a small company, staffed by instruments, with one human holding judgment. Everything in this article is about building that sentence instead of admiring it.
The AI era changed four jobs — and none of the verdicts
Separate the hype from the actual shift. The shift is specific and it is enough.
What genuinely changed is not "AI writes code". It is that four roles which used to require patience and hours now run as scheduled instruments: the reader (turns a report into evidence), the answerer (drafts a checkable reply), the implementer (proposes a tested change), and the documenter (keeps the contract in sync). None of them need to be trusted. Each has a defined output contract and a gate — and that is precisely why they can be delegated without a team.
| Role | Yesterday | As an instrument | Gate that makes it safe |
|---|---|---|---|
| Reader / triage analyst | A maintainer's evening, days of latency | Reads a redacted diagnostics bundle, classifies it, cites raw log lines | Conservative rules; an un-answered report never closes |
| Answerer / support desk | Email by email, from memory | Renders a public answer card: symptom, diagnosis, your move, status | Publishing is default-deny; privacy filter; no user data |
| Implementer | Only when the maintainer has a free weekend | Read-only model proposes a unified-diff patch on an isolated branch | Guards, ≤8 files, full test suite, main untouched, human merge |
| Documenter / release engineer | The task that always slips | Version rows, changelogs, manifests and checks driven by the same commit | Consistency tests; artifacts verified by size and SHA-256 |
This is the division of work the thesis page states — agents run the loop; humans hold intent, boundaries and judgment — applied to a project with exactly one accountable human. The split is by accountability, not task size: instruments carry execution, not accountability (roles).
The economics make this real rather than theoretical. Inference for daily work sits in a value tier — roughly $0.14–$0.27 per million tokens in the pricing this ecosystem measures — and a recorded triage-style session in this project's own logs came to $0.0036 (137 input, 1,229 output, 349,824 cache reads). Read that number against the alternative cost, which is not money but the maintainer's evening: the instrument's job is to spend three-tenths of a cent so that no human spends forty minutes before deciding.
Judgment, responsibility, taste, safety, and the question "does it count". The control period proves the point: before this method existed, the same operator ran 185 agent sessions and 37,202 turns — and the knowledge left no trace. Model capability was never the missing piece; a carrier for judgment was. The ledger article measures both eras.
One answer per constraint
Attention becomes loops. Continuity becomes contract. Legitimacy becomes evidence.
Attention → loops
The maintainer stops being the relay for every message. A ten-minute cron reads new reports; a triage pass classifies them; environment problems close themselves with a published answer; defects auto-schedule; features wait for a single decision. The human's week is spent on two verbs — decide and merge — plus the non-delegable work: safety, hardware, and the roadmap.
Continuity → contract
A living document with one version row per episode (signal, evidence, decision, boundary) is memory that survives sessions, illnesses and interruptions. A constraint registry turns the project's scars into pre-edit refusals, so the same mistake cannot quietly return while the maintainer is away. The project's ability to continue stops depending on anyone remembering.
Legitimacy → evidence
No one can trust a solo project because of its brand, so trust is manufactured: answers that cite raw log lines, download artifacts checked by SHA-256, a public board that shows what was closed and what is still waiting, and limitations written down before a user discovers them. Every checkable claim is a deposit; every surprise is a withdrawal.
The order matters. Loops without a contract produce fast noise; a contract without evidence is a private diary; evidence without loops cannot be produced at solo scale. The three are one system — the same three axes described in The Three Axes, viewed from the maintainer's chair rather than the project's architecture.
The solo maintainer's stack: nine instruments
Everything below is in production in this ecosystem today. Nothing requires a budget line.
| # | Instrument | Job |
|---|---|---|
| 1 | One repository | The single carrier for code, contract and history; agents and humans read the same tree |
| 2 | One living contract (SDD) | Requirements with targets and methods; version rows as the project's learning ledger |
| 3 | One constraint registry | Lessons as machine-readable refusals, checked in the path of every edit |
| 4 | One inbox | A self-hosted, stdlib-only receiver for redacted diagnostics bundles — no SaaS, no data leaving your control |
| 5 | One triage cron | Every ten minutes: fetch, summarize, classify, cite, draft |
| 6 | One answers page | Public, searchable, line-cited: the answer is the documentation of last resort |
| 7 | One board | Public queue where classification dispatches: closed / scheduled / waiting / rejected with reasons |
| 8 | One implementer | Unattended, single-flight, guarded, isolated branch, full-suite gate; never touches main |
| 9 | One evidence ledger | Numbers with dates and boundaries — the only place comparable claims are allowed to live |
The three promises (your SLA without on-call)
Every report gets a first reading — within minutes
Not a human first reading: a scheduled, conservative machine reading with cited evidence. The promise is not "we will be awake"; it is "nothing you send will sit unread".
Every answer is checkable — and honest when it isn't
Cards cite raw log lines and end in an action the user can take. When the material is insufficient, the card says need more information instead of guessing. An honest "I don't know yet" is a service, not a failure.
Every accepted fix is tested and reversible
Fixes land behind a test gate, on an isolated branch when unattended, with rollback paths verified for releases. The user is never the test environment.
The attention budget
| Only the human does | Instruments do |
|---|---|
| The verdict on what counts as done; merging the branch | Reading, summarizing, classifying, drafting, rendering, publishing the safe classes |
| Scheduling features (one note per item); rejecting with a reason | Auto-scheduling defects; closing environment noise; keeping the queue ordered |
| Safety decisions — transmit, radio authority, physical hardware | Enforcing the gates that make those decisions hard to violate by accident |
| The relationship with users: the apology, the thanks, the roadmap | Making sure there is no queue of things to apologize for |
The startup sequence (what to build first)
| When | Build | Why in this order |
|---|---|---|
| Week 1 | Diagnostics bundle + receiver + answers page | Converts your inbox of vague reports into measurements you can read in minutes; the answer page removes the second question |
| Week 2 | Constraint registry from the incidents you already know | Your scar tissue is the cheapest, highest-value automation you will ever write; start with 5–10 rules you can reproduce |
| Weeks 3–4 | Triage cron with publish-safe classes + public board | Removes the daily relay; makes the queue visible and honest; noise closes itself |
| Month 2+ | Unattended implementer (read-only proposal, isolated branch, test gate) | Only worth building once the queue is classified and the test suite is trustworthy — otherwise you are automating chaos |
This ecosystem built exactly this stack around a real product line (MRRC Modern): the support chain shipped in four slices in three days, and the first answers were published the day the first bundles arrived. The mechanism is documented in the mechanism volume and journaled in The Support Loop.
Imagination is an engineering material
Someone has to see the loop before it exists. The discipline is what happens next.
Every instrument in §04 was imagined before it was built: a support queue imagined as a sensor network; a user's report imagined as a remote measurement; the product's own backlog imagined as a loop that runs while the maintainer sleeps; a chat log imagined as a document that could have survived. None of that is in a model's default output. It is design work — and for a solo maintainer it is the highest-leverage work there is, because one good loop replaces a hundred evenings.
This is where "belief" earns its place. The honest version of believe in the power of belief is not a mindset slogan; it is an economic statement about sequencing. The first loop is always built before it pays off: the bundle before the first triage, the registry before the incident it prevents, the answers page before the user who needs it. You are betting your hobby hours on a future where the loop returns them. That bet requires imagination — and it deserves receipts.
Do not believe in the hype; believe in the loop. The way through the uncertainty is to make each loop start as the smallest testable proof: one reproduced incident blocked by one constraint, one bundle answered by one card, one branch passing one suite. Each proof buys a little more delegation — and the compounding of those receipts is what eventually feels like faith. That is also the umbrella's testable form — incident → ruling → constraint → block (thesis).
What belief must not do is equally concrete: do not bet on a model brand (the main force changed within a week in the ledger's measurements), do not bet on unbounded delegation (the merge stays human), and do not bet on volume (more automated output is not more value). Bet on the shape of the loop and on the gate at its end.
How solo projects actually die — and the guard for each
Not "the code breaks": the maintainer does. Guard the maintainer.
| Failure mode | How it looks | Guard |
|---|---|---|
| Attention collapse | The inbox grows; the maintainer avoids opening it; the hobby becomes a debt | The triage cron and the answers page — nothing piles up unanswered, and the safe classes close without the maintainer |
| Silent failure | An instrument dies quietly (a runner stopped, a page stopped updating) and nobody notices for days | Instrument observability: name your own failures in logs; byte-check public artifacts; the loop must explain its own silence (this ecosystem learned it from a cron runner that died with SIGABRT — and from a test fixture that briefly reached a production board) |
| Scope creep | Every "wouldn't it be nice" becomes a promise; the roadmap becomes a threat | Features wait for the human by policy; the roadmap grows from repeated signatures in real reports, not from enthusiasm on a good evening |
| Trust debt | A user finds an issue your release notes didn't mention; the next update is installed reluctantly | Honest boundaries, visible known issues, no automatic promotion between maturity states, rollback targets that exist |
| Bus factor of one | The project is only operable by the person who built it; a month away is fatal | Memory in the repo: contract rows, constraint registry, source-of-truth map, documented recovery paths — written for the stranger who will run this next |
| Belief without receipts | Piling up automation that was never verified; a "system" nobody can check | Every loop ships with its gate and its evidence; if it cannot fail loudly, it is not finished |
What money still buys — and the method cannot
The point of freeing attention is to spend it where only a human with resources can act.
- Hardware truth. A bench, reference instruments, spare radios, and the hours to run acceptance tests. No loop fabricates physical verification; this ecosystem's answer is to keep unverified models behind a transmit gate and say so, rather than pretend.
- Other people's time. A second maintainer, a translator, a lawyer, an accountant. The method reduces the coordination cost of adding a person — the contract is the onboarding — but it cannot substitute for one.
- Legal and financial substance. An entity, a trademark, a paid support agreement, insurance. A hobby project can be excellent without them; it cannot be a vendor without them.
- Guarantees. A corporation can promise an SLA and back it with a contract. A solo project can only promise instruments and honesty — which, done well, is surprisingly close to what users actually need.
The method does not turn one person into a company, and it is not meant to. It turns one person's attention into a system whose reach exceeds their hours — so that the hours can go to the things only they can do: judgment, taste, safety, and the reasons they started.
From "believing it's possible" to running it
A concrete starting order for a solo project with an existing codebase and users.
Days 1–2 · Make reports measurable
Ship a diagnostics bundle (redacted config, environment snapshot, log tails, an auto health summary) and a receiver. Keep it stdlib-simple and self-hosted. From now on, a report arrives as a scene, not a story.
Days 3–5 · Publish the answers page
One page, searchable by report ID, with a fixed card structure: symptom / diagnosis with raw evidence / your move / status. Publish the first three answers by hand if you must — the page is what makes the promise visible.
Week 2 · Write the registry you already earned
List your last ten incidents; write 5–10 machine-readable constraints with reproduction notes; wire the check into your pre-edit path. This is the highest-return week of the project.
Week 3 · Triage on a cron
Fetch → summarize → classify → draft. Keep publishing default-deny until you trust the drafts; keep "need more info" as a first-class outcome. Add the public board when the first classification feels wrong — you will want the visible queue.
Week 4 · Close the loop, carefully
Only now add the unattended implementer: read-only proposal, guards, isolated branch, full test suite, no unattended
main. The human merge is not a bottleneck; it is the trust anchor.Always · Keep the ledger and the boundaries
One dated place for comparable numbers; one written list of what is not done and why. The ledger is how you prove progress to yourself; the boundaries are how you keep the trust you have earned.
Instrument the friction, contract the memory, evidence the trust — and spend your own hours only on the judgment no instrument can hold. The hobby does not survive by being small; it survives by being looped.
Go deeper: The Three Axes (the method end to end) · The Support Loop (the instruments in action) · the field loop mechanism · the evidence ledger. If you are building this for your own project and want to compare notes, the contact page is the door.