Liquid SaaS and Customer Driven Development

Liquid SaaS is software that changes when its customers ask. A customer asks for a change in the chat on your site. AI teammates build it for that one account, test it, and ship it when you say yes. When a change works for that account, it goes to every customer.

Customer Driven Development (CDD) is the method under it. This page tells what the two words mean, why they are possible now, and how Troopy keeps your product whole while it changes.

Liquid SaaS in short

Liquid does not mean loose. You keep one codebase and one product. A change lives behind a flag, gets a code review and a run of your tests, and waits for your yes. See How Troopy keeps one product whole.

Liquid SaaS is in early access. Some parts work today, and some come next. See What works today and what comes next.

Why software can be liquid now

Code is now cheap. An agent can write a feature in minutes, so building is not the slow part anymore. The slow part is the founder: read each ticket, watch each replay, decide what to do, and review each change. A small team cannot do that for each customer.

Most customers do not want to build software. They want the software that they use to work their way. Many customers already talk to the chat of a product as if it can do the work. They ask it to do a task, or they ask for a feature. Each of those messages is a request for a change.

So the gap is not "can an agent build it". The gap is how to ship a change for one account, keep the product safe, and send what works to everyone.

Customer Driven Development

In test driven development, you write a test first, and the code must pass it. In Customer Driven Development, the customer gives the spec. The spec is what the customer asks for, and what the customer does in your product.

CDD has two loops. The first loop starts with a request. The second loop starts with a signal that a customer does not say.

Loop 1: a request becomes a change for one account

This loop comes next. When it ships, it works like this:

1. A customer asks for a change in the chat on your site, in plain words.
2. If your product can do it already, the Support agent shows the way or does it.
3. If your product cannot do it, Troopy saves the request for that account, in the words of the customer.
4. Agents build the change behind a flag that is on for that account only.
5. The change passes your tests and a code review.
6. You approve it. The account gets the change, and the customer hears it in the chat.
7. Troopy watches how the account uses the change.
8. When the change works, you roll it out to everyone. A change that does not work goes away.

Each account is an experiment. Your customers find the changes that are good, and you decide which ones stay.

Loop 2: signals become fixes for every customer

Most customers do not ask. They struggle, or they leave. The second loop finds those problems. Troopy does parts of this loop today, and joins them into one loop next.

1. Sense. Troopy reads your billing, your support chats, your session replays, your surveys and your errors.
2. Rank. Troopy groups the signals into problems, and ranks each problem by the revenue at risk.
3. Build. An agent writes the fix and opens a pull request.
4. Verify. After the release, Troopy watches the signal and the accounts that hit the problem.
5. Close the loop. The customers who hit the problem get a note that it is fixed.

Rank by revenue, not by count. On another product that we run, fixes from session replays alone did not change retention. Fixes from failed payments and cancel reasons did. Session replays show where customers struggle. They do not show why customers leave.

The two loops feed each other. A request in the chat is also a signal, and a fix for everyone can start as a change for one account.

Done means the problem is gone

In CDD, a merged pull request is not the end. A closed ticket is not the end. A change is done when the signal stops in production:

Check each group of customers on its own. A total can stay flat while each new group of customers stays longer.

How Troopy keeps one product whole

The hard part of liquid software is not to write the change. The hard part is to keep one product safe and whole while each customer changes it. Troopy uses these rules:

A teammate never merges code by itself. A person presses Release, or an owner or admin gives a grant with limits. See Engineering and Stay in control of your troop.

From in the loop to on the loop

Today a founder is in the loop: the founder does each step. With CDD, the founder is on the loop. The founder sets the goals, the taste and the limits, and approves the result. Today you approve each change. Next, trust grows in steps:

Customers drive the floor of the roadmap: bugs, friction and the reasons that they leave. You drive its ceiling: the work that no customer can ask for.

What works today and what comes next

Liquid SaaS is in early access. Join the waitlist on troopy.ai to get it first.

See Customer support, Customers, Sessions and Engineering for the parts that work today.

Where the words come from

In 2026, founders began to write about software that changes when its users ask. Patrick Collison added a box to his own apps where a user types an improvement, and an agent builds it. He called this liquid software. He also asked if such software stays maintainable, secure and reliable. Other founders use the words "polymorphic SaaS" or "custom software as a service".

Troopy uses the words Liquid SaaS for the product, and Customer Driven Development for the method. The flags, the tests, your yes and the check after the release are the answers to those three questions.