When Is an AI Project Actually Done?

Traditional software had clear endings. AI projects don't.

Every AI project I work on follows the same pattern.

We deploy something. It delivers value. The client is happy.

Then they find one more thing. Just this one crucial feature. Without it, they can’t really go live.

We add it. Deploy again. More value delivered.

Then another crucial thing appears.

And another.

When does it end?

The Old World Had Clear Endings

Decades ago, software arrived on discs in its final form. Companies invested heavily in QA to ensure the product burned onto that disc (for younger readers: “burning” meant using a laser to physically etch data onto a CD—yes, we really did this) was as close to bug-free as possible.

You couldn’t patch it later. What shipped was what customers got.

Then the internet arrived, and with it, SaaS. Software could be updated periodically online. Version 2.3.1 would ship with new features, pushed to millions of users simultaneously. But those releases were still “done.” The version was finished, tested, and deployed. There was a clear line between version 2.3.1 and version 2.4.0.

Each release had a beginning and an end.

AI Broke the Model

AI solutions don’t work like that.

We deploy continuously. Not just updates to the same software for millions of users, but improvements tailored to each customer’s specific workflow. Every deployment teaches us something new. Every improvement reveals the next bottleneck.

The feedback loop needs to be short. Deploy, learn, improve, deploy again. Sometimes daily. Often weekly. The value accumulates with each iteration.

But when do you stop?

The Problem Nobody Talks About

Here’s what actually happens on AI projects.

Clients don’t fully understand their own processes until we start automating them. They think they know how approvals flow through their organization. Then we build the first version and discover three edge cases they forgot about. And a manual step nobody documented. And a decision that actually requires human judgment but they thought was automatic.

As we automate, they learn. As they learn, the scope changes.

This isn’t feature creep. It’s discovery.

But it creates a real problem: when can you declare the project complete?

We could say it’s done when we’ve implemented everything from the initial scope. But we often don’t know what the scope is when we start. This isn’t traditional software development where you spec everything upfront.

We could say it’s done when the client stops asking for improvements. But they rarely do. There’s always another insight, another workflow to optimize, another integration that would add value.

We could measure ROI and stop when we hit a threshold. But ROI is hard to measure when value is diffuse across many people, the baseline is unclear, and improvements are continuous.

What We’ve Learned So Far

At Lleverage, we push for deployment as soon as possible. Get something live that delivers real value, then iterate on it. No waiting for perfection.

We set expectations explicitly at the start: this will be a process of continuous improvement, not a one-time delivery.

Then we look for value thresholds. Have we automated the most painful 80% of the workflow? Have we eliminated the biggest bottleneck? Can the client see measurable time savings?

We also have to be honest about capacity. We work on multiple projects. An AI solution can always be improved, but we can’t stay embedded forever.

The real goal is to get the client to a point where they can make improvements themselves. When they understand their own agents well enough to adjust prompts, add examples, or refine rules without needing an FDE embedded in their team.

That might be the new definition of “done”: when the client can own their own improvements.

We Need New Frameworks

This is probably the first time in software history where every customer shapes how their solution looks and behaves.

You didn’t get to choose how Microsoft Word would work for you in the 2000s. Everyone got the same version. Even custom software development followed a pattern: spec, build, deliver, done.

AI solutions don’t work that way. Not because we’re building custom software for each client—we’re not a traditional dev agency. But because AI agents and automation require this continuous shaping and refinement.

Traditional project management frameworks assume you can define success criteria upfront. Traditional software development assumes you can test for “done.”

Neither applies here.

We’re still figuring this out. Value thresholds help. Capacity constraints force decisions. Client ownership provides an exit.

But I suspect we need entirely new frameworks for thinking about AI project completion.

Here’s what every FDE knows: you could probably improve every solution you’ve ever shipped. There’s always another edge case to handle, another workflow to optimize, another integration to add.

The question isn’t whether you can add more value. It’s whether you should.

Maybe “done” isn’t about the solution being complete. Maybe it’s about the solution being valuable enough and the client being capable enough.

We’re learning to declare victory and move on, even when more improvements are possible.

But I don’t think we’ve solved this yet.

What are you seeing? How do you decide when an AI project is done?