There's a category of engagement we hear about constantly in first calls: the six-figure AI strategy project that produced a beautiful 80-page deck, a maturity assessment, a prioritized use-case matrix — and zero running software. Twelve months later, the client is exactly where they started, minus the fee.
We're not going to pretend all consultancies work this way. The big firms employ genuinely strong engineers. But the traditional consulting model — how the work is scoped, staffed, and billed — pushes toward outcomes we think are wrong for AI. Here's the difference, concretely.
What you're buying: hours vs systems
Traditional firms bill for time and materials or fixed-fee phases, where the deliverable of phase one is a document that justifies phase two. The economic engine is utilization: keep consultants billable, extend engagements, land bigger follow-ons. None of that is scandalous — it's just optimized for selling analysis, because analysis scales across a leveraged pyramid of junior staff better than engineering does.
Our engagements are scoped around a running system:
- Pilot (4–6 weeks): one use case, deployed against your real data, with an eval suite and a go/no-go metric agreed in week one.
- Co-Build (3–6 months): we build the production version alongside your engineers, in your repos, on your infrastructure.
- Scale (ongoing): we operate and extend what's live — model updates, new use cases, cost optimization — with SLOs, not status decks.
If the engagement ends and nothing is in production, we consider it a failure regardless of how insightful the analysis was. That's what production-or-nothing means as a scoping rule, not a slogan: we decline work that can't plausibly reach deployment in the engagement window.
The staffing difference
Look at who actually shows up. A typical consulting AI engagement is staffed with one senior architect who splits time across four clients, plus analysts who are learning the technology on your dime. The deck is polished because deck-making is the firm's core competency.
Our teams are two to four senior engineers who write code every day. No leverage pyramid, no partner who appears at steering committees and nowhere else. This makes us structurally worse at some things — we can't parachute forty people into a global transformation program — and structurally better at the thing that matters early: getting a system to work.
A useful diligence question for any AI partner: "Of the people on my engagement, how many have merged code into a production LLM system in the last 90 days?" The answer sorts vendors fast.
Where the models diverge most: after the demo
Almost anyone can build an impressive demo now. Frontier models are good enough that a slick prototype takes days. The hard 80% of the work is everything a demo doesn't need:
- Evals. A versioned test suite that catches regressions when models, prompts, or data change. We won't ship an agent without one, because "it seemed fine in the demo" is not a deployment criterion.
- Observability. Tracing on every LLM call, cost and latency dashboards, drift alerts. When output quality degrades in month three — and it will — someone needs to see it before your customers do.
- Data quality. Most "model problems" are pipeline problems. Contract tests and freshness checks on inputs are unglamorous and non-optional.
- Failure handling. Escalation paths, human-in-the-loop checkpoints, graceful degradation when the model is uncertain. This is where compliance and legal actually engage, and where strategy decks are silent.
Traditional engagements frequently end at the demo, with a "productionization roadmap" handed to a client team that wasn't in the room when the design decisions were made. That handoff is where most enterprise AI initiatives quietly die.
Where traditional firms genuinely win
Fair is fair. Choose a large consultancy over us when:
- The problem is organizational, not technical. Operating-model redesign, change management across 20,000 employees, board-level AI governance frameworks — that's their home turf, not ours.
- You need massive parallel capacity. A global rollout across 14 countries with regulatory workstreams in each is a body-of-work problem that rewards scale.
- Procurement requires it. Some enterprises can only buy from firms already on a master services agreement. We understand; we've also watched this constraint select for incumbents over outcomes.
And plenty of clients use both: a big firm for governance and change management, us for the systems that have to actually work. That division of labor is sound.
Incentives, stated plainly
Ask what makes each party more money. A time-and-materials consultancy earns more when the problem takes longer. We earn follow-on work only when the pilot ships and the metrics hold — our Scale revenue depends entirely on systems surviving in production, because nobody pays to operate a system that doesn't exist.
Whatever partner you choose, put a production milestone in the contract with an objective metric attached. Any vendor who resists committing to one is telling you what they plan to deliver.
The test we'd apply to ourselves, and invite you to apply to anyone: at the end of the first engagement, what runs? Who can operate it? What does the eval dashboard say this week versus week one?
If the answers are "nothing, nobody, and there is no dashboard" — you bought slideware. We don't sell it.