A VP of engineering at a mid-market manufacturer called me last spring with a problem that sounded like a win. His team had shipped a document-extraction tool that pulled spec data off supplier PDFs. It worked. It saved his estimators real hours. And then, six weeks after the contractor’s final invoice cleared, a supplier changed their PDF template and the whole thing quietly started returning garbage. Nobody noticed for nine days. By then the estimators had stopped trusting it, and they’d gone back to copy-paste.
The build was fine. The procurement was wrong. He’d bought a one-time project for something that was never going to sit still — and the moment the engagement ended, so did the maintenance, the monitoring, and the institutional memory of how the thing actually worked.
That’s the question nobody frames clearly when they go shopping for AI help. People obsess over which model, which vendor, which framework. The decision that actually determines whether you get value is more boring and more consequential: how you buy the work. Subscription? Fixed project? Staff augmentation? Each one quietly shapes what you can ask for, who carries the risk, and what happens after launch.
This is a buyer’s guide to that decision. No model comparisons, no tooling religion. Just the three procurement models, where each one earns its keep, and the hybrid most teams actually need.
The three ways to buy AI work
Strip away the labels and there are three structures. Everything else is a variation on these.
Fixed-scope project. You define a deliverable, agree on what “done” means, and pay for that thing. A contract-review pipeline. A demand-forecasting model. A RAG system over your engineering standards. Scope is the unit of exchange.
Subscription / continuous capacity. You retain ongoing capability — a team that shows up week over week to build, fix, extend, and respond. You’re not buying a deliverable; you’re buying momentum and the ability to keep moving as the ground shifts.
Staff augmentation. You rent people. They join your standups, take direction from your leads, and work inside your stack under your management. You own the plan, the priorities, and the outcome. They bring hands and skills.
These aren’t ranked. A team that only sells one of them will tell you that one solves everything. It doesn’t. The fit depends on three things about your situation: how well-defined the work is, how much the problem will move after launch, and how much of the work your own team can absorb and own.
Fixed-scope projects: when the destination is clear
Projects are the right call when you can describe the finish line with a straight face. The problem is bounded, the inputs are stable, and you’ll know success when you see it.
Good fits:
- A discrete capability with a clear input and output — “classify these warranty claims,” “extract these fields,” “generate these reports.”
- A proof of concept to settle an argument before you invest further.
- A migration or integration with a definable end state.
- Work where the underlying data and process won’t change much for a while.
What you get is accountability. Scope is written down, so there’s a shared definition of done and a clean line for what you owe and what they owe. Budgeting is predictable. For the right problem, this is the most efficient way to buy.
The failure mode is the one my manufacturer hit. Projects end. The problem often doesn’t. Anything touching live data, changing source formats, drifting model behavior, or evolving user expectations will degrade after the team walks away. A fixed project draws a hard boundary around something that, in reality, needs tending. You also pay a tax on every change request — re-scoping, re-contracting, re-mobilizing a team that has since moved on and lost the context in their heads.
And there’s a subtler cost. Fixed scope quietly discourages the most valuable thing that happens during AI work: discovering that the problem you wrote down isn’t the problem worth solving. When the contract rewards delivering the agreed spec, nobody’s incentivized to tell you the spec is wrong.
Subscription capacity: when the problem keeps moving
Subscription — continuous capacity — fits when the work won’t hold still long enough to fit in a box. You’re not buying one thing. You’re buying the ability to keep shipping as the situation changes.
This is the right model more often than buyers expect, because most AI work is not “build it and you’re done.” It’s “build it, watch it, and adjust as reality pushes back.” Models drift. Source documents change format. Users find edge cases you never imagined. Regulations shift. A subscription keeps a team in the loop who already holds the context, so a supplier changing a PDF template is a Tuesday, not a fire drill nine days late.
Where it earns its keep:
- Systems running against live, changing data where quiet degradation is expensive.
- Roadmaps where you know the direction but not every stop — you’ll learn what to build next by shipping.
- Organizations that want to build internal capability over time, not just receive a handoff.
- Anything where the cost of the system silently breaking is higher than the cost of the capacity.
The structural advantage is continuity. The team that built it is the team that maintains it, so context compounds instead of evaporating. Reprioritizing is a conversation, not a change order. And because nobody’s defending a frozen spec, you get the honest version: “We could finish what we scoped, but we’ve learned something — here’s what we’d actually do.”
The honest downside: a subscription requires you to trust that capacity is being spent well, because you’re not buying a fixed deliverable. That trust has to be earned with visibility — what got shipped, what’s in flight, what’s next. A subscription without transparency is just a recurring invoice. If a vendor can’t show you where the capacity went, the model isn’t the problem; the vendor is.
This is the model behind Ryshe Forge: a standing team building and maintaining AI systems continuously, so the work keeps pace with the problem instead of ending at a milestone. It’s not the right answer for every engagement — but for live systems that need to keep working, it usually is.
Staff augmentation: when you own the plan
Staff aug is the right structure when the constraint is bandwidth, not direction. You know exactly what you’re building and how. You have a competent team and a clear plan. You’re simply short a couple of people with specific skills.
Good fits:
- A strong internal team that needs to scale up for a defined stretch.
- Specialized skills you need temporarily and don’t want to hire permanently.
- Work where keeping ownership and IP fully in-house is non-negotiable.
The advantages are control and knowledge retention. The work happens inside your walls, your people stay close to it, and nothing important leaves when the contract ends.
The catch is that staff aug only works if your own bench is strong. You’re providing the architecture, the direction, and the quality bar — the augmented staff execute against it. If your team doesn’t actually know how to build the AI system, renting hands doesn’t fix that; it just adds coordination overhead to a plan that was already shaky. Augmented engineers do their best work against clear direction. Hand them ambiguity and you’ve paid for people to wait on you for answers you don’t have. Staff aug scales a team that knows what it’s doing. It cannot substitute for one that doesn’t.
The hybrid most teams actually need
Here’s what I tell most buyers: the question usually isn’t which one. It’s in what order.
The pattern that works for a lot of mid-market and engineering-driven organizations looks like this. Start with continuous capacity to find your footing — figure out what’s worth building, ship the first real systems, and learn how AI actually behaves against your messy data. Then, once a particular need is genuinely well-defined and bounded, run it as a tight fixed-scope project. And where your internal team is ready to own a piece, fold in augmentation so capability stays in-house.
Think of it as a default mode plus exceptions. Subscription is the steady state that keeps systems alive and momentum intact. Projects are how you carve out a clearly-bounded, fund-and-forget deliverable when one genuinely exists. Staff aug is how you transfer ownership inward as your team grows into it.
A typical 200-person engineering firm might run a subscription that keeps three production AI systems healthy and explores the next two, while spinning out one sharply-defined integration as a fixed project and embedding an engineer alongside their internal lead. None of those three is “the” model. Together they match how the work actually arrives.
Two questions that route the decision
When you’re not sure which structure a given piece of work wants, ask:
- Will this problem hold still after launch? If yes, a project can put a clean box around it. If it touches live data or changing inputs, it needs continuity — buy capacity, not a deliverable.
- Can my team own this, or just direct it? If your bench can own it, augmentation keeps it in-house. If you need a team that both builds and carries the thinking, that’s not staff aug — that’s capacity.
This is also where the line between Ryshe Forge and Ryshe Labs comes from. Forge is the continuous capacity — the standing team for systems that need to keep working. Labs is for the bounded, exploratory build: a defined experiment, a proof of concept, a settle-the-argument prototype. Same people, different shape, matched to what the work needs rather than what’s easiest to sell.
What this actually comes down to
The mistake my manufacturer made wasn’t technical. The build was good. He bought a one-time project for a living system, and the structure of the purchase guaranteed the outcome long before the PDF template ever changed. The procurement model is a decision about who carries the risk after launch — and that decision deserves more thought than which vendor has the slickest demo.
So before you compare proposals, get clear on three things: how well you can define the work, how much it’ll move once it’s live, and how much your own team can truly own. Those answers point to the structure. The structure points to the vendor — not the other way around.
If you’re weighing a specific piece of work and genuinely can’t tell which shape it wants, that’s a thirty-minute conversation, not a research project. We don’t publish scope or capacity as a menu because it depends entirely on what you’re actually trying to do — so a short call is usually the fastest way to figure out whether your problem wants a project, a subscription, or a couple of good engineers sitting next to your team. Whatever the answer, get the structure right first. The rest is just execution.
