From business idea to running operation. Enterprise-grade risk control at startup effort.

An AI can build you an application in an afternoon. Everything after that is what costs you.

Creating an application is maybe 1% of the cost. The other 99% is change, maintenance and operations. That is where AI projects fail: features disappear, one change breaks three others, nobody knows why something was built the way it was, and the knowledge sits in the chat history of a single tool.

One continuous path, from idea to feedback from production.

1. Write down the goal. Every change starts with a written business goal: what it should achieve, what must never happen, and how you'll know it's done. A person approves it before anything is built.
2. Test what's unclear first. Where it is still open what's actually needed, we clarify it with a throwaway prototype (DEAD), kept separate from the real system.
3. Build against the specification. Human or AI, the implementation must meet the agreed goals, rules and acceptance criteria. Tests check what was agreed, not whatever the code happens to do.
4. Release under control. Every change passes through the same pipeline: build, test, deploy. Exactly the version that was tested goes live. The previous version stays ready, and if the production check fails, the system switches back automatically.
5. Learn from production. What happens in operation, and every bug, feeds the next specification. A bug is fixed only once it's clear which rule applies.

The rules ACD builds in.

• People stay accountable. Goals, rules and approvals belong to your people. An AI may read documents and draft proposals, but never decide on its own what counts.
• No AI approves itself. Whoever writes a change cannot promote it to production. The pipeline decides on release, and its verdict is final.
• Red means stop. While the pipeline reports a failure, only repairs are allowed, nothing new.
• Nobody needs production access. Changes reach production only through the pipeline.
• All knowledge lives in the repository. Goals, rules, code, checks and deployment are recorded there. You can switch AI tools at any time without losing knowledge, and any person or AI can pick up the work.
• The way back is rehearsed. During setup we break the pipeline on purpose and restore it. You rely on recovery only once it's proven to work.

The base version is up and running in one day.

You don't need a Kubernetes estate or a DevOps team. To start, a computer, a repository and a target environment, such as a small server, are enough.

What's in place at the end of the day:

• Workspace, repository and target environment are set up and documented, so you can rebuild them at any time.
• A pipeline takes changes to your production in three stages, build, test, deploy, and switches back automatically on failure.
• The emergency is rehearsed: pipeline broken on purpose and restored.
• A first small feature has gone from written goal to production.

This works even if nobody on your team has ever developed software. ACD works with any AI tool and any tech stack.

Our own production release on 31 October 2026

Placeholder: anonymised screenshot of the pipeline run

• 3 min 14 s from start to completed production release
• Mandatory staging gate: no production without a successful staging run (staging run: 1 min 16 s)
• Same version: verifiably the exact image that was tested went live
• 9,809 of 9,809 requests succeeded during the update, 0 failures
• Longest interruption 810 ms, against a 2,000 ms budget
• Automatic rollback on standby

This isn't a demo system but . The code examples in the ACD book come from Michael Küsters' own production repository.

Where the method comes from: Michael Küsters has worked with Continuous Delivery for more than a decade and has been developing ACD since 2023. In late 2025 he published the ACD manifesto with Bryan Finster on MinimumCD.org. The book "Agentic Continuous Delivery – Make change work. In minutes." is forthcoming on Leanpub. You can read the ACD practice guide free on MinimumCD.org today and apply it yourself. With us, the base is running after one day, and we stand behind the result.

The goal is that you run ACD yourselves afterwards: knowing what you change, why it's acceptable, and leaving the system ready for the next change.

Is ACD only for development teams? No. ACD is built precisely for founders, business teams and small teams who build their own solutions with AI and don't want to fall into the maintenance trap. For experienced developers, it closes the gaps that AI agents tear into proven practice.

What do we need for the setup day? A computer, an AI tool of your choice, a repository and a target environment, for example a small server with admin access. If your IT can't provide that environment, that is already an important finding, and we discuss it upfront.

Will you also build our software? If it's needed, yes, up to and including the complete development. Not as a service provider, but to get things moving. Either way, ACD sets up the path on which your team, with or without AI, then builds and releases safely on its own. Product decisions stay with you.

We already have an application. Does this still work?

For companies: is there a default configuration? Yes, for commercial use we provide a default configuration.

One day. After that, every change reaches production under control.