Write the problem before the prompt
Name one user, one repeated job, one visible result, and at least three non-goals. If the complete demo takes more than two minutes, cut scope.
Role guide
AI coding agents for solo builders
A solo builder can move fast because one person owns the problem, the repository, and the release. The same setup concentrates every failure on one person. Use the agent for code volume while keeping requirements, review, dependencies, tests, release evidence, and recovery under your control.
From idea to release
Make the first version small enough to finish
Write three stories and one ugly case
Use acceptance criteria a person can observe. Empty input, a missing field, or a duplicate belongs in the requirements before code exists.
Compare two architectures
Make the agent show components, files, dependencies, boundaries, and data flow. Require a reason for every framework, database, worker, or hosted service.
Turn the plan into stopping points
Each stage should end with a running project, one visible improvement, and a small check. Write the condition that sends you back to the last known-good state.
Build and map the tests
Run the agent loop one stage at a time. Every accepted test should point to a requirement written before the implementation.
Review the supply chain
Inspect each direct dependency, lockfile change, install script, and secret boundary. Give every dependency an accept, replace, or remove verdict.
Release for a stranger
Replay every README command in a fresh copy, record the known-good commit, prove rollback, and show the core job plus one ugly case in a short demo.
Worked example
A weekly CSV report formatter
The course’s small-app kit includes a report formatter problem card. It is useful because the input and output stay visible, the first release needs no accounts or network service, and an ugly case can be forced without risking real data.
| Artifact | Decision for this app | Proof |
|---|---|---|
| Problem | One person turns a weekly CSV export into a readable Markdown summary. | A report file appears from a fixture input. |
| Non-goals | No accounts, sync, web interface, database, background job, or model call. | The architecture and dependency list contain none of them. |
| Story 1 | A valid CSV produces totals and grouped rows. | A test maps to the written acceptance criterion. |
| Story 2 | The output includes the source filename and run date. | The fixture result contains both fields. |
| Ugly case | A missing required column produces a clear error and no partial report. | The failure test checks the message and confirms no output file exists. |
| Release | A command-line app with a replayed README and a release card. | A fresh copy runs, the demo shows the ugly case, and rollback returns to the recorded commit. |
Add a model only when the contract needs one
A later version might summarize free-text notes through a hosted connection. Build that as a separate model application with a clear input cap, validated output, visible timeout and cancellation behavior, bounded state, privacy-safe usage logs, failure doubles, and a provider boundary covered by contract tests.
Maintenance
Run a change system, even when the team is one person
Requirements
Make new work earn a line
New behavior gets an acceptance criterion. New ideas during a release move to the next version.
Regression
Turn failures into checks
Add a production bug or broken output to the test or eval set before closing the fix.
State
Leave yourself a handoff
Keep plan, progress, decisions, and next action outside the chat transcript so a fresh session can resume.
Cost and latency
Set job budgets
Cap inputs, outputs, turns, and wall-clock time. Make degraded and failed outcomes visible.
Safety
Keep dangerous actions narrow
Validate outputs and require approval for money, secrets, deletion, publishing, and other irreversible effects.
Recovery
Practice the way back
Keep a known-good version, a stop method, a rollback command, and evidence that restored service behaves correctly.
Common failure points
Where solo speed creates debt
| Failure | What it looks like | Correction |
|---|---|---|
| Scope re-inflation | The working app keeps collecting features outside the written release. | Return to the non-goals and finish the current version. |
| Test theater | Many green tests check what the code already does while a promised behavior has no evidence. | Map each accepted test to a requirement and add the ugly cases. |
| Unread dependencies | A small change brings new packages, scripts, and transitive code nobody reviewed. | Inspect direct dependencies and the lockfile before release. |
| README fiction | Setup works only on the machine where the app was built. | Replay every command in a fresh copy and correct the file from the result. |
| Permanent almost-done | The app runs but has no release state, rollback proof, or known limitation. | Record the release card, demo the ugly case, and state the limitation. |
Questions and answers
Solo-builder questions, answered
What is a good first app for a solo builder?
Choose one user, one repeated job, one visible result, and at least three non-goals. A local file organizer, CSV report formatter, or command-line checklist is small enough to review and release.
Should the first app include an AI model?
The course’s first complete app does not. It isolates the construction skills first: requirements, design, staged changes, mapped tests, dependency review, release, and rollback. A streamed model application comes after the API module.
How does a solo builder keep agent-written code maintainable?
Keep changes small, require a plain explanation, map tests to requirements written before the code, review direct dependencies, replay the README in a fresh copy, and commit only known-good states.
What changes when the app becomes a recurring service?
Add bounded state, privacy-safe logs, evals, cost and latency budgets, explicit failures, narrow permissions, notifications, and a rehearsed recovery path. Scheduled work also needs an overlap policy and a kill switch.
Keep building
Build one real release, then make it operable
The course gives the small-app build its own module before adding raw APIs, a streamed model application, a provider adapter, data systems, agents, evals, reliability, safety, a local lane, and a capstone.