For software agencies
Client tickets, worked to a pull request.You decide twice.
An agent takes a maintenance ticket from Jira, finds the cause in your client’s code and opens a pull request on GitHub. It asks you before it changes a line, and again before the ticket is done.
Editing locked
Order confirmation email shows the total before the discount
1. The template prints the subtotal.
Refutedemails/orderConfirmation.tsx:41value={money(order.total)}
2. The email job gets the order from before the discount.
Confirmedorders/checkout.ts:88queue.send("order-confirmation", { order })
At a glance
- Jira, or typed on the board
- GitHub pull requests
- Two: the plan, the result
- None
- Never
- That client’s workspace
- “not priced”, never $0
- By invitation
01 One ticket
Follow one ticket from Jira to done.
The agent’s work runs by itself, in grey. Blue means a person is needed. In this walkthrough, the person is you.
- To doTo do
- TriageTriage
- Confirm planConfirm plan (a person decides)
- DevelopmentDevelopment
- AcceptanceAcceptance (a person decides)
- DoneDone
The ticket is on the board
The agent reads the ticket and the client’s code. It may not change a line until it can show why the bug happens. Then it stops and asks you.
- AgentWrites two explanations and tests each one against the code
- YouApprove the plan, or send it back with a note
- AgentUnlocks the editor, fixes, and proves it with a failing then passing check
- YouAccept the result, or send it back
02 Safeguards
Three things it will not do with a client’s code.
An agency is trusted with code that is not its own. These are the rules that let an agent work inside that trust, and what enforces each one.
It does not edit before it can explain the bug.
Triage must offer at least two explanations, each with a check that could prove it wrong. Only one that survives its check, with the line quoted, unlocks the editor.
- Each explanation names the file and line where it would show
- The fix comes with a check that fails on the old code and passes on the new
- A second container re-runs that check on a fresh checkout. It can raise a doubt; it cannot approve
It does not let one client see another’s code.
Each client is a workspace with its own tickets, repositories, search index, GitHub token and model key. The database enforces the separation, so two clients who compete never see each other.
- Row-level security forced on every table, with a second policy per workspace
- Each run in a throwaway container with no route to the database and no platform credentials
- Outbound traffic limited to GitHub and package registries; anything else is refused and logged
- People can be limited to the workspaces they work on
It does not decide for you.
A person approves the plan and accepts the result. The agent opens pull requests from its own branch; it does not push to your main branch and does not merge.
- Approve, send back with a note, steer a fix in progress, or take the ticket over by hand
- A history on every ticket of who decided what, and why
- Cost for every run, and an optional spend cap that stops new runs, never one in progress
03 Fit
Built for the maintenance work agencies carry.
RapidBuild is for the steady stream of small, well-described tickets across your clients’ applications. Some work should stay with your engineers, and the agent is not offered it.
Give it
- Defects someone can reproduce
- Small changes to how an existing feature behaves
- Missing or weak regression tests
- Fixes that span two or three of a client’s repositories
Keep it with your team
- New applications and open-ended redesigns
- Migrations across many services
- Payments, security and permission changes
- Destructive database work
- Production emergencies
04 Fits what you use
Works inside Jira and GitHub. Replaces neither.
- Jira
- Tickets arrive on the board every five minutes, or on demand. RapidBuild reads Jira and does not write to it.
- GitHub
- Pull requests on your clients’ repositories, one for each repository a ticket touches, kept current with the base branch.
- Slack
- A message when a ticket is waiting for a person.
- Models
- The platform’s model by default, or a workspace’s own Anthropic, OpenAI or OpenAI-compatible key, stored encrypted. A key that fails stops the run with an error; it never switches models quietly.
- Previews
- Boot a branch and look at it, on an origin kept apart from the board. Share it with a client by a link that expires.
- Sign-in
- GitHub, Google (which can be limited to your domain) or a one-time email link. No passwords. Access is by invitation.
05 Questions
What agencies ask first.
Which model does the agent use?
By default, the model the platform runs. A workspace can use its own Anthropic, OpenAI or OpenAI-compatible key instead. The key is encrypted at rest, and a key that fails stops the run with an error rather than quietly using another model.
Where does the agent run, and what can it reach?
Each run is a throwaway container with its Linux capabilities dropped and a read-only root. It has no route to RapidBuild’s database or internal services and holds no platform credentials. It can reach GitHub, with the workspace’s own token, and package registries. Everything else is refused and logged.
Can it merge, or push to main?
No. It opens pull requests from its own branch. A project can choose to have Accept also merge the pull request, which is still a person’s click.
What happens when it cannot find the cause?
It does not guess its way into an edit. The ticket can come back to you with questions, be marked as needing information, or be taken over by a person, with what the agent found kept on the ticket.
How do I know what a ticket cost?
Every run is recorded with its cost. A run whose model has no price on record is shown as not priced, and a total that includes one says “at least”. A project can have a spend cap, which stops new runs and never one in progress.
Does it work with Linear, GitLab or Azure DevOps?
Not today. RapidBuild works with Jira and GitHub. Tickets can also be written directly on its board.
Is there a free trial or a self-serve plan?
No. Access is by invitation, and every pilot is set up with the agency running it. Request one below.
06 Pilot
Start with a 30-day pilot on your own tickets.
There is no self-serve sign-up. Each pilot is set up with the agency running it, on real client work, and judged against how that work usually goes.
Set up
A workspace for each client you choose, connected to its Jira project and its GitHub repositories. Set up with you, by hand.
Work real tickets
Your team picks tickets that fit and makes the two decisions on each. Nothing reaches a client’s main branch without your review.
Measure
Compare accepted tickets, and the time your people spent, with how the same work usually goes. The answer is in your own numbers, not ours.
Bring a few of your clients’ tickets.
A pilot suits an agency with client applications in maintenance, already working in Jira and GitHub. Send a few details and a person will reply.
Already invited? Sign in to RapidBuild.