# Your prototype works. Changing it is the hard part. CodeHerder does not build an app from a prompt. See when a prompt-to-app builder fits better, and what CodeHerder needs from your repository. Source: https://codeherder.com/prototype-to-production/ For builders with a working prototype CodeHerder does not build an app from a prompt. It picks up once you have a repository, and something real to protect while you change it. [Request access →](https://codeherder.com/get-started/#request-access) [See what you need first →](https://codeherder.com/prototype-to-production/#what-you-need) Which tool fits which moment ## Three moments, three different tools Match the tool to where your idea actually is right now. - You have no code yet A prompt-to-app builder gets you to a first working version fastest. Use one for this step. Come back here once that version needs a repository behind it. - You have a prototype, and changing it feels risky This is where CodeHerder starts: with a repository that already exists. File the next change as a task. An agent plans it, builds it, then opens a pull request. - You already have engineers shipping code Your team likely runs a coding agent day to day already. See [/compare](https://codeherder.com/compare) for how CodeHerder coordinates many agents across many tasks, instead of speeding up one session. Where the wall is ## A prototype stops being easy to change at a specific point Three moments where a single prompt stops being enough, and the gate that catches each one. - The change is too big for one prompt Before any code exists, an agent writes out what it plans to do and why. Read the plan and send it back with a note, the same way you'd redirect a teammate. See [/how-it-works](https://codeherder.com/how-it-works) for the full pipeline. - A fix breaks two other screens A separate review stage checks the code before it merges, so the agent that wrote the change never grades its own work. See [/verification](https://codeherder.com/verification) for every gate a task passes through. - A diff nobody reads Verify confirms the merged change does what the task asked for, then hands you a plain-language summary. See [/when-agents-get-it-wrong](https://codeherder.com/when-agents-get-it-wrong) for what happens the moment an agent takes a wrong turn. What CodeHerder needs from your prototype ## Three things, before day one - A git repository you own Wherever your prototype's code already lives. CodeHerder never becomes a host for it; agents work against your existing repository, in their own isolated copy. - A branch to work on An agent commits its work to a branch, then opens a pull request back to your default branch. - An authenticated git-host CLI on the device `gh` for GitHub, `glab` for GitLab, signed in on the machine that runs your agents. See [/where-agents-run](https://codeherder.com/where-agents-run) for every way to connect that device. No repository yet? Build your first version elsewhere. Come back once it exists. See [/will-it-work](https://codeherder.com/will-it-work) for the full fit check. Weighing a freelancer instead? Read [freelancer or agents](https://codeherder.com/freelancer-or-agents). Start with one small change ## File one small, checkable change first Pick something bounded enough to check when it's done. These three are ready to copy and file as they are. - A control that is cut off on a phone File the button or menu that gets clipped on a narrow screen, and get it fixed. Real cost, start to finish: $20.87. [Read the full brief →](https://codeherder.com/starter-briefs/control-cut-off-on-phone/) - Add a field to a form we already have Name the field, where it should live on an existing form, and get a working save-and-show for it. No real task in examples.ts matches this brief's exact shape yet. What's real is the mechanism: an agent extends a form and its saved record together, in the same change, so the new field works end to end rather than only on screen. [Read the full brief →](https://codeherder.com/starter-briefs/add-a-field-to-a-form/) - Add a filter to a list we already have Name the list and what you want to narrow it by, and get a working filter control for it. No real task in examples.ts matches this brief's exact shape yet. What's real is the mechanism: an agent adds a filter through the same query the list already uses. Paging and sorting keep working, instead of drifting out of sync with a client-side hide. [Read the full brief →](https://codeherder.com/starter-briefs/add-a-filter-to-a-list/) More ready-to-file briefs at [/starter-briefs](https://codeherder.com/starter-briefs). Already have your own wording? Run it past the [brief checker](https://codeherder.com/brief-checker) first. FAQ ## Questions people ask about a prototype's first repository task Will CodeHerder build my app from scratch? No. CodeHerder works on a repository that already exists. Build your first version with a prompt-to-app builder or a developer, then bring the repository here for what comes after. What does CodeHerder need before it can help? Three things: a git repository you own, a branch to work on, and an authenticated git-host CLI on the device that runs your agents. See /will-it-work for the full list. My prototype has no tests and no real structure. Does that matter? Not for a first task. An agent reads the code as it stands and plans around it. Pick one small, checkable change first. Review and verification catch what a plan missed. Can I start with something small? Yes. File one change, such as a cut-off button or a missing field, and watch it become a task, then a merged pull request. /starter-briefs has ready-to-file examples. What if I don't have a repository yet? Build your first version elsewhere, with a prompt-to-app builder or a developer, then come back. CodeHerder needs a real repository to start from.