A VP of engineering at a mid-sized manufacturer asked me last spring whether he should sign a six-month statement of work or put us on a monthly retainer. Fair question. The wrong one to start with.
He’d already decided the shape of the engagement before he’d decided the shape of the work. That happens constantly. People reach for the contract structure they’re comfortable with — a fixed project because procurement understands fixed projects, or an open-ended retainer because the last vendor relationship felt too transactional — and then they try to bend the actual work to fit. It’s backwards. The contract should be the last thing you choose, not the first.
The real question is simpler and harder: does this work have a finish line, or doesn’t it? Some AI work genuinely ends. You build the thing, it works, you hand over the keys, and the team that owns it forward doesn’t need you in the room every week. Other AI work never ends in any honest sense, because the thing you’re building is a moving target that gets more valuable the longer you keep refining it. Confuse the two and you either pay for a standing capability you don’t need yet, or you box a living system into a one-time deliverable and watch it rot the day after sign-off.
That distinction is the whole reason we run two different engagement models — Ryshe Forge and Ryshe Labs. This is how we figure out which one a piece of work belongs in, and what to do when the answer is “both, eventually.”
The honest test: does this have a finish line?
Before anything else, ask whether you can write down what “done” looks like in a sentence a stakeholder would accept.
“Done” means a real acceptance condition. A working integration that passes a defined test suite. A migrated platform serving production traffic. A research question answered with a yes, a no, or a number. If you can articulate that and it’s stable — meaning the definition won’t quietly mutate three weeks in — you probably have a project.
If you can’t, that’s not a planning failure. It’s a signal. A lot of the most valuable AI work resists a fixed definition of done because the target keeps moving in ways you actually want. Your data changes. Your users learn. The model you’re leaning on gets cheaper or smarter and opens up something that wasn’t worth doing last quarter. Work like that isn’t underspecified. It’s genuinely continuous, and trying to nail it to a fixed scope just means you’ll renegotiate the scope every month and resent the paperwork.
Here’s the tell I trust most: imagine the work is “finished” and you walk away for six months. If the value holds, it was a project. If the value decays — quietly, predictably, because the world moved and nothing kept pace — it was always continuous, and you just hadn’t admitted it.
When continuous fits: Ryshe Forge
Continuous delivery is the right call when the work is a roadmap, not a deliverable. The defining feature is that priorities shift faster than any contract could be rewritten, and the cost of stopping is higher than the cost of the work itself.
A few patterns where this is almost always the answer:
- An evolving roadmap. You don’t have one feature; you have a backlog that reorders itself every two weeks as you learn what your users actually do. Locking that into a fixed scope means renegotiating constantly. Better to run a steady cadence and let the priorities float.
- Integration into a living system. AI features that sit inside a product you’re already shipping inherit that product’s release rhythm, its on-call rotation, its dependencies. They can’t be “delivered and forgotten” because the ground underneath them moves with every deploy.
- Ongoing optimization. Retrieval quality, prompt behavior, model selection, latency, cost-per-call — these don’t have a final answer. They have a current-best answer that drifts. Someone has to watch the drift and correct it, week over week.
- Anything load-bearing in production. The moment real users depend on an AI feature, you’ve signed up for maintenance whether you planned for it or not. Models get deprecated. Inputs shift. A retrieval system that was sharp in January quietly goes dull by summer as the underlying documents change out from under it.
The thing people underestimate is that AI systems decay differently than ordinary software. A normal service that you stop touching mostly keeps working. An AI feature that you stop touching degrades, because its quality is a function of data and model behavior that won’t sit still. That’s not a maintenance contract in the boring sense. It’s the actual work. Forge exists for exactly that — a standing engineering relationship that treats the system as something you tend, not something you hand off and hope about.
When a project fits: Ryshe Labs
A dedicated, fixed-scope build is the right call when the work has a clear edge and a clean handoff. You know roughly what you want, you can define what good looks like, and once it exists, a team that isn’t us can own it.
Some honest examples:
- A net-new product or feature. You’re building something that doesn’t exist yet, with a defined shape. There’s a real beginning, middle, and end. Concentrated focus gets you there faster than a thin slice of attention spread across months.
- A replatform or migration. Moving from one stack to another, consolidating systems, lifting a workload into a new environment. The destination is known. The work is getting there cleanly without breaking what’s running.
- A fixed-scope build with a deadline. A pilot for a board demo. A capability you need live before a trade show or a customer commitment. The constraint is real, the scope is bounded, and the value of hitting the date is concrete.
- R&D and feasibility. “Can we even do this?” That’s a question, not a roadmap. You want a focused investigation that comes back with a defensible answer — yes, no, or here’s what it would actually take — so you can decide whether to invest further. Open-ended budget is the wrong tool for a question that wants closure.
The common thread is the clean handoff. When the build is done, your team can run it, or it slots into an existing system that someone already owns. You don’t need a permanent relationship to keep the lights on, because the work genuinely concluded. That’s not a lesser engagement. For the right problem it’s the more disciplined one, because a finish line forces decisions that an open-ended cadence lets you defer forever.
Labs is where that focused, bounded work lives. A team pointed at a defined outcome, working to an edge, then getting out of the way.
A quick gut-check
If you’re still unsure, run the work through three questions:
- Can you write “done” in one sentence a stakeholder would sign off on? Yes leans project. No leans continuous.
- Does walking away for six months destroy the value? Yes leans continuous. No leans project.
- Who owns it the day after we finish? A clear internal owner leans project. “Honestly, still you” leans continuous.
None of these is a hard rule. Two out of three pointing the same direction is usually enough to stop debating and start the work.
How they hand off to each other
The part most decision guides miss: this isn’t a fork in the road where you pick a path and never see the other one. The two modes feed each other, and the strongest engagements move between them deliberately.
The common direction is Labs, then Forge. You build a net-new AI feature as a focused project — clear scope, real deadline, clean delivery. It ships. And then reality arrives: the feature is now load-bearing, it needs to keep pace with your product, the model under it will be deprecated inside a year, and the retrieval quality needs tending as your data grows. The project succeeded, and its very success created continuous work that didn’t exist before. That’s not scope creep. That’s a system graduating from “built” to “alive,” and pretending otherwise is how good launches quietly degrade by the next quarter.
It runs the other way too. Inside an ongoing Forge relationship, something big and bounded shows up — a replatform, a major new capability, a migration that needs concentrated effort rather than a steady trickle. Carving that out as a defined Labs project, with its own edge and its own acceptance criteria, is cleaner than letting it sprawl across the continuous cadence and blur every other priority for two months.
The practical move is to name the transition out loud. When a project is wrapping, we say plainly which parts are genuinely finished and which parts just became continuous. When a continuous engagement spawns something with a real finish line, we pull it out and scope it as its own thing. The failure mode in both directions is silence — letting continuous work hide inside a project that was supposed to end, or letting a bounded build dissolve into an open-ended retainer where nothing ever quite closes.
The takeaway
Don’t start with the contract. Start with the work, and be honest about whether it ends.
If you can write down what “done” means and a clear owner can carry it forward, you want a project — focused, bounded, delivered, and handed off. If the value lives or dies on continuous tending, stop pretending a fixed scope will hold and run it as the standing capability it actually is. And keep an eye on the seam between them, because most real engagements cross it at least once.
That diagnosis is most of the value, and you can do a lot of it yourself with the three questions above. If you want a second read on a specific piece of work — which mode it belongs in, and whether it’s the kind of thing that’ll graduate from one to the other — that’s a good use of a 30-minute call. We’ll tell you which way we’d run it and why, including the cases where the answer is “this doesn’t need us yet.” Scope and capacity get set on that call; we don’t pretend to price work we haven’t understood.
The shape of the work decides the shape of the engagement. Get that order right and most of the hard calls make themselves.
