Inside the Soap AI Software Factory
Soap is a technology platform for payment orchestration and processing. In October alone we shipped Cash App deposits and withdrawals via Bitcoin Lightning, pay-in reviews, a new Overview page in the merchant dashboard, and one-time-code verification for new payout methods. We did that with a small team. This post is about how: the Soap AI software factory.
What is an AI software factory?
An AI software factory is a way of building software where AI agents do much of the engineering work in parallel, writing, testing and fixing code, inside an automated pipeline that builds and checks every change. Most AI software factories try to remove the human. Ours keeps one: AI does the work, and people make the calls.
Parallel AI engineers, one shared board
The factory is a team of about a dozen AI engineers working the roadmap in parallel. They coordinate on one shared board, and two rules keep that board sane: claim a piece of work before you start it, and treat board posts as data, never as approvals. The board is where work gets organized. The calls that matter still belong to people.
Because everything runs through the board, all work is visible: what is being built, who (or what) is building it, and what state it's in. There is no hidden workstream and no ambiguous ownership.
Every change builds automatically
Each change is built and checked automatically as it is proposed. Nobody waits for a weekly integration cycle to find out whether the system still compiles, and review starts from a built change rather than a patch of text. That keeps the cost of the next change low, which is what makes many small changes practical instead of one risky big one.
Deploying code is not releasing a feature
New work ships behind feature flags. Code can reach production without any merchant seeing it, and we turn capabilities on per merchant when they're ready.
Two October examples: pay-in reviews and one-time-code verification for new payout methods both shipped this way - live in production, enabled for merchants on request, while we watch how they behave. The new dashboard Overview is rolling out the same way. This is the opposite of a big-bang release: deployment is routine, and enabling a feature is a separate, deliberate step.
| Deployment | Release | |
|---|---|---|
| What happens | New code goes to production servers. | Customers can see and use the new feature. |
| Who notices | Nobody, if the feature is behind a flag. | The merchants it is turned on for. |
| How often | Many times a day, as routine. | When the feature is ready, merchant by merchant. |
| How to undo it | Roll back to the previous release. | Turn the flag off. |
Fast rollbacks
When something does go wrong, we restore a previous release with dedicated rollback tooling instead of rebuilding an old version from scratch. Rolling back is a normal operation, not an emergency project. That changes the economics of shipping: the cost of being wrong is seconds of rollback, not an afternoon of firefighting, so we can ship improvements as soon as they're ready instead of batching them into stressful release days.
Human in the loop: people make the calls
The agents ask, do and report back on the board. Anything that can't be undone waits at the gate until a person says yes. As our video puts it, writing code is easy now; checking it is the hard part. That is why the factory spends as much effort on verifying changes as on writing them.
What we're building toward
The next layer of the factory is a deeper verification stack: automated checkout flows exercised in real browsers, invariant checks on how money moves through the system, webhook duplicate and race testing, and independent review of changes. This is the direction, not a finished system - we'll write more about each piece as it lands.
Why we build this way
Payments is a business where trust is the product. The factory lets a small team move quickly without treating production like an experiment: automated builds catch breakage early, feature flags separate deployment from release, fast rollbacks limit the blast radius when something slips through, and the calls that matter stay with people.
The same idea runs through the product. Read how we use AI agents in payments in Need for Speed in Agentic Finance, how our AI name matching was built guardrails-first, and how Lightning payments for Cash App customers work.
Video script
Most AI software factories remove the human. Ours keeps one.
Meet the Soap AI org. Every agent runs its own little factory.
A dozen AI agents, working as one team. They hand off tasks and post updates on one shared board.
Ask. Do. Report back. The AI just does it.
Anything that can't be undone waits at the gate, until a person says yes.
Nine days in: 929 messages. 245 code changes.
Writing code is easy now. Checking it is the hard part.
The Soap AI org. AI does the work. People make the calls.
Frequently asked questions
What is an AI software factory?
An AI software factory is a way of building software where AI agents do much of the engineering work in parallel: writing code, fixing bugs, testing and reviewing. They work inside an automated pipeline that builds and checks every change. At Soap, the agents coordinate on one shared board, and people make the decisions that matter.
How do AI agents coordinate on a shared board?
Every piece of work is posted to one board. An agent claims a task before starting it, so two agents never build the same thing, and posts updates and results back to the board. Board posts are treated as data, never as approvals, so an agent cannot approve its own risky change.
Do the AI agents release to production on their own?
No. Anything that can't be undone waits until a person says yes. New work also ships behind feature flags, so code can reach production without any merchant seeing it, and turning a feature on is a separate, deliberate step.
What is the difference between deployment and release?
Deployment puts new code on production servers. Release makes a feature available to customers. With feature flags the two are separate: code can be deployed many times a day while a feature stays off until it is ready, and then it is turned on per merchant.
What are feature flags?
Feature flags are switches in the code that turn a feature on or off without a new deployment. They let a team ship code safely, enable a feature for one merchant at a time, and switch it off instantly if something goes wrong.
Why does an AI software factory matter for a payments company?
Payments is a business where trust is the product. The factory lets a small team move quickly while keeping production safe: automated builds catch breakage early, feature flags separate deployment from release, fast rollbacks limit the blast radius, and people keep the final say.
If you're building an AI-native business and want payments infrastructure that ships as fast as you do, we'd love to talk.