There’s a moment I’ve seen too many times. The project is “done.” The model works in the demo, the dashboard loads, the stakeholders nod. We hand over the repo, write the closeout doc, schedule the knowledge-transfer call. Everyone shakes hands. And then, about six weeks later, I get a quiet email from someone on the client’s team asking if we can hop on a call, because the thing that worked in March doesn’t quite work the same way in May, and nobody internally is sure why.
The model didn’t break. The world moved. A vendor changed an API. A new data source came online and nobody wired it in. The one engineer who understood the pipeline took a job somewhere else. The classifier that hit 94% on last quarter’s data is quietly drifting on this quarter’s. None of these are dramatic failures. They’re the ordinary entropy of any system that touches real data and real operations. But a project that ended in March has no mechanism to absorb them.
For years I treated this as a scoping problem. Write a better handover. Add a maintenance retainer. Train the internal team harder. None of it fixed the underlying issue, because the underlying issue isn’t about any single project. It’s about the shape of the engagement itself. A project has an end. AI work doesn’t.
So we changed the model. This is the case for why.
The roadmap is where AI succeeds or stalls
Here’s the thing most AI pitches get wrong. They sell the build. The model, the integration, the deployment — the part that’s legible, that fits in a statement of work, that has a clear deliverable you can point at.
But in almost every engagement I’ve worked, the build was never the hard part. The hard part was everything that came after the first version shipped. The second data source you didn’t know existed during scoping. The edge case that only shows up at quarter-end. The realization, three weeks in, that the workflow you were automating was actually two workflows that needed to be split apart. The model that worked fine until the business changed how it categorized its own jobs.
AI doesn’t succeed at the moment of deployment. It succeeds, or stalls, over the roadmap that follows — the steady sequence of “now that it works, what’s the next thing it should do, and what just broke that we need to fix.” That roadmap is where the actual value lives. And a fixed-scope project, by design, ends right at the point where the roadmap begins.
When you sell a project, you’re implicitly telling the client: the valuable part is the build, and the rest is your problem. I no longer believe that’s honest. For the kind of work we do — engineering firms, manufacturers, aerospace suppliers with messy real-world data — the build is maybe 30% of where value gets created. The other 70% lives in the months after, in the iteration nobody scoped because nobody could have.
What “done” actually costs you
Let me be concrete about the failure mode, because it’s specific and it’s expensive.
Take a typical 200-person engineering firm that just deployed a document-extraction system to pull structured data off incoming project specs. It works. It saves a couple of people a real chunk of their week. Genuine win.
Then the project ends. And here’s what happens over the next two quarters:
- A major client starts sending specs in a slightly different format. Extraction accuracy drops. Nobody notices for a while because the failures are silent — the system just returns less.
- Someone on the ops team has a great idea for extending it to a second document type. There’s no one to build it, so it goes on a wish list that never gets prioritized.
- The internal champion who sponsored the project moves teams. Institutional memory of why it was built the way it was starts to evaporate.
- A dependency gets a breaking update. The fix is small, but there’s no one whose job it is to make it, so the system sits half-degraded for a month.
None of these are catastrophes. That’s exactly the problem. They’re small enough to tolerate and frequent enough to compound. We’ve seen teams quietly lose most of the value of a working system inside a year, not because the system failed, but because nothing was carrying it forward. The asset depreciated because no one owned its trajectory.
A project gave them a thing. What they needed was momentum.
What we do instead
So we stopped selling projects and started delivering continuously. We call the offering Ryshe Forge, and the idea behind it is deliberately unglamorous: instead of a build with an end date, you get a named team and reserved capacity that keeps shipping against your roadmap, week over week.
A few things change in practice.
A named pod, not a rotating cast
You work with the same small group of engineers — people who learn your data, your domain, your weird internal vocabulary, and your actual constraints. This is not a ticket queue routed to whoever’s free. The compounding value of continuous delivery comes almost entirely from the team not having to relearn your business every engagement. The second month is more productive than the first. The sixth is more productive than the second. That curve only exists if the people stay the same.
Reserved capacity against a living roadmap
You hold a block of capacity, and we work the roadmap together — reprioritizing as reality changes, because it will. The thing you thought was urgent in week one is often not the thing that matters in week eight, and a continuous model lets you act on that instead of being locked to a spec written before anyone understood the problem.
Outcomes you accept, not deliverables we declare
Each cycle of work lands as something you actually sign off on — a working improvement, an accepted outcome, not a status update with a green checkmark. The unit of progress is “this now does something useful it didn’t do before,” confirmed by you, not by us.
Ownership stays with you
This matters and I want to be unambiguous about it: the code, the models, the pipelines, the documentation — they’re yours. Continuous delivery is not a hostage situation where the system only runs as long as you keep paying. We build so that you could walk away and run it yourself. The reason clients don’t is that the roadmap keeps producing value, not because they’re locked in. If we ever stop earning the next cycle, you should leave. That constraint keeps us honest, and I want it there.
For the larger, more ambitious builds — the ones that are genuinely new rather than iterative — we run those through Ryshe Labs. Forge keeps your existing systems moving and improving; Labs is where we take on the bigger, riskier, net-new work. Most clients end up using both: Labs builds the next big capability, Forge carries it forward once it’s real.
The honest tradeoffs
I’d be doing exactly the thing I criticize other vendors for if I pretended this model is free of downsides. It isn’t, and you should weigh them.
It asks for commitment before certainty. A project lets you buy a defined thing for a defined price and walk away. Continuous delivery asks you to commit to a relationship before you can see every outcome it’ll produce. That’s a real ask. We try to de-risk it by keeping ownership with you and earning each cycle, but I won’t pretend the shape of the commitment is the same as a one-off.
It’s the wrong fit for genuinely bounded work. If you have a single, well-understood, truly one-time task — migrate this data once, build this one report, and you will never touch it again — you don’t need continuous anything. Buy the project. I’ll tell you that on the call, and I have. Continuous delivery earns its keep when there’s a roadmap with a future. When there isn’t, it’s overhead.
It requires you to engage. Reserved capacity is only worth it if someone on your side helps steer it. The model assumes a real partnership — someone who can answer questions, make calls on priorities, and accept outcomes. If you want to fully outsource the thinking and check back in a year, this isn’t that. Honestly, nothing good is that.
Value shows up as a curve, not a spike. The big visible deliverable of a project has a certain satisfying drama to it. Continuous delivery is quieter — steady, compounding, sometimes unglamorous. The payoff is larger over time, but it doesn’t photograph as well in a launch meeting.
Where this leaves us
I didn’t change our model because continuous delivery is a trend. I changed it because I got tired of watching good work stall for reasons that had nothing to do with the quality of the work — and everything to do with the fact that the engagement ended right when the system needed someone to carry it.
AI isn’t a thing you install. It’s a capability you operate, and operating it well is an ongoing act. The roadmap is where it pays off, and a roadmap needs someone walking it with you. That’s the whole argument. Everything else is implementation detail.
If you’re sitting on a system that worked once and isn’t quite working now, or you’re about to start something and you already suspect the build is the easy part, that’s the conversation worth having. We keep it to 30 minutes, and scope and capacity get set there — no pricing theater, no pretending we can quote your roadmap before we understand it. If it’s a fit, you’ll know. If it isn’t, I’ll tell you that too. You can book a 30-minute call, and if you want to see how the continuous model actually works, Ryshe Forge lays it out.
Either way: don’t let the next good thing you build quietly depreciate the day someone declares it done.
