AI SaaS company, services firm, or build it yourself?

Every quarter someone in a document-heavy back office asks this question in one of three forms: should we buy from an AI SaaS company, hire a firm to build and run it, or staff it ourselves? The answer turns on two things you can estimate in an afternoon — how much your version of the workflow differs from everyone else's, and who absorbs the cost when the output is wrong. We build and operate agents for a living, so we have a side. We also tell people to buy software when buying software is right, and this post says exactly when that is.

The three options, stated plainly

An AI SaaS company sells one codebase to many customers, priced per seat or per transaction. Its economics only work when the workflow is roughly the same across those customers. Every hour a SaaS engineer spends on your edge case is an hour not spent on the median customer, so the product management job is to say no to you. That is not vendor cynicism. It is the business model working as designed.

A services firm sells engineering time plus accountability. It will absorb your edge cases because you are paying for them. The risk is the opposite one: nothing compounds unless the firm reinvests what it learns, and you can end up owning a bespoke system with a single-vendor dependency and no roadmap.

Building in-house means you own everything, including the parts nobody talks about at the kickoff: the evaluation harness, the monitoring, the on-call rotation, and the person who still owns this in year three after the original engineer leaves.

Most organizations end up with all three. The mistake is not picking wrong. The mistake is routing a workflow to the wrong one of the three and then spending eighteen months proving it.

When AI SaaS clearly wins

SaaS wins when the work is genuinely common across organizations, the output is cheap to check, and being wrong is inexpensive. Transcription. Meeting notes. Document OCR. Translation. Code assistance. Support macro drafting. Email triage. In these cases the vendor has seen ten thousand instances of your problem and you have seen one, and their version will be better than anything you build for less than several hundred thousand dollars.

Here is a test that settles it fast. Pull fifty real cases from last month. For each one, ask whether an equivalent organization — same size, same regulator, same systems — would have handled it identically. If forty or more come back yes, you are looking at a commodity workflow and you should buy it. Negotiate hard on price and move on to something that actually differentiates you.

SaaS also wins when volume is low. If the workflow runs 150 times a month, the evaluation and monitoring work required to trust a custom agent costs more than the labor it replaces. Buy the generic tool, accept the mediocre fit, and put your engineering attention somewhere with more cases behind it.

And a third case people forget: SaaS wins when the alternative is nothing for two years. A tool that is 70% right and live next month beats a perfect agent that never leaves the pilot stage.

Why regulated document work resists pure SaaS

Prior authorization, denials and appeals, discovery review, transcript evaluation, aid verification. These share four properties that break the SaaS amortization math.

• Integration is the product, not a settings screen. Your EHR instance has custom fields nobody documented. Half your payers have no API and a portal that changes its DOM quarterly. Some of your intake still arrives by fax. A SaaS vendor builds to the standard interface because that is what scales; the last mile is where 80% of the engineering actually lives, and it is your last mile, not theirs.
• The accuracy number is from their documents, not yours. A vendor quoting 94% measured that on their test set. Run the same agent on an orthopedic group's clinical notes, or on one payer's idiosyncratic medical necessity criteria, and it can land twenty points lower. Ask any vendor to run their evaluation on 200 of your real historical cases, scored against the outcomes you already know. If they cannot or will not, treat the number as marketing.
• Liability does not transfer. When an appeal is filed on the wrong grounds, the regulator, the payer and the patient all come to you. Read the indemnity clause and the liability cap. Most SaaS agreements cap at twelve months of fees, which is not a meaningful backstop against a compliance finding. Ask where the decision log lives, whether it records the reasoning and the source documents, and whether you can export the whole thing if the relationship ends.
• Your long tail is the whole job. Twenty payers with twenty rule sets, or four state bar jurisdictions, or a transfer credit policy your provost rewrote last spring. The SaaS roadmap serves the median customer. In regulated work there is no median customer, only a distribution of exceptions.

None of this means SaaS is useless here. It means the commodity layer (extraction, classification, retrieval) is buyable and the judgment layer is not. We wrote up how that split works in practice on our methodology page, and applied to one workflow in detail under prior authorization automation.

The in-house build, honestly costed

Do the arithmetic yourself rather than trusting anyone's benchmark. Two engineers and a domain expert at half time, for six months, at whatever your fully loaded cost per head is. Then add the permanent owner — the person who investigates why accuracy dropped after the payer changed a form, retunes, and carries the pager. That second number never goes away, and it is the one that kills in-house projects in year two.

Against that, put the vendor's annual contract and an honest estimate of the integration work you would do anyway. In our experience the build usually looks cheaper on the six-month view and more expensive on the three-year view, because organizations forecast the build and forget the operate.

IDC's 2025 finding that 88% of AI proofs-of-concept never reach production is mostly a story about in-house builds. The demo works. Then someone asks what the accuracy is on last quarter's hard cases, nobody has an evaluation harness, and the project quietly becomes a slide.

Build in-house when three things are true at once: the workflow is a real competitive advantage rather than overhead, you already have a platform team shipping and operating production services, and you can name the person who owns it in 2029. If any one of those is missing, you are buying a maintenance obligation, not an asset.

Services then product is a sequence, not a cop-out

Vertical AI companies that start as services firms get accused of selling consulting with a product logo. Sometimes that is fair. More often it reflects something real about this category: you cannot know which 60% of a regulated workflow is common until you have shipped it inside four or five different organizations. Build the product first and you get a configuration-heavy system that fits nobody, plus a customer success team explaining why the roadmap does not include the customer's actual problem.

The sequence that works is the reverse. Deploy into real environments, keep an eval set per deployment, watch which components stay identical and which are always rewritten. The identical parts become product. The rewritten parts stay as configuration and integration work, priced as such. Anyone claiming there is no configuration layer in healthcare or legal document work has not deployed in either.

If you engage a services firm, the questions that matter are about ownership, not rate cards. Who owns the prompts, the evaluation harness, and the labeled data at the end? Can you run the agent yourself if you part ways? Is there a documented handover, or does the knowledge live in one senior engineer's head? Our answers are on the comparison page, including the cases where we recommend a SaaS product instead.

A decision rule you can run this week

Take a whiteboard and your five highest-hour document workflows. For each, write down four numbers: monthly case volume, how many of fifty sampled cases another organization would handle identically, the number of systems the agent must touch, and the dollar cost of a single wrong output that ships. Then route:

• High commonality, low error cost. Buy SaaS. Spend the negotiation energy on export rights and price, not features.
• High volume, low commonality, high error cost. This is where an operated agent earns its keep. Insist on shadow mode: the agent runs beside your team on live cases, producing output nobody acts on, until measured accuracy justifies cutover.
• Low volume, whatever else. Do not automate it. Fix the process or leave it alone.
• Nobody agrees how the work should be done. Do not automate it yet. If three reviewers handle the same case three ways and no one can say which is correct, you have no ground truth, no evaluation, and an agent that will encode the confusion at scale. Write the policy first.

That last one is the most common finding in our two-week AI Readiness Map, and it is the answer nobody wants: the blocker is not the model, it is that the decision rules were never written down. Sorting that out is cheaper than any of the three options above, and it is a prerequisite for all of them.