Most articles about artificial intelligence assume you should be using it. We are an SI studio, and we start most engagements from the opposite premise: assume you should not, and let the evidence overturn that assumption. It is a strange way for a vendor to open a conversation, but it has saved our clients real money and saved us the reputational cost of shipping something that quietly fails six months after launch.
This is the framework we walk through before quoting a single line of work. It has three gates. A project has to pass all three before custom SI is the right call. If it stalls at any gate, the honest recommendation is usually a vendor product, a rules-based system, or nothing at all.
Gate one: is the problem actually an SI problem?
The most expensive mistake in this field is reaching for a language model when a deterministic system would be cheaper, faster, and more predictable. SI earns its complexity when the input is genuinely ambiguous: unstructured text, images, messy human language, or decisions with no clean rule you could write down. When the rule does exist, write the rule.
We ask one question to test this. Could a competent new hire write down the exact steps to solve this in an afternoon? If yes, you want software, not a model. A regex, a lookup table, and a few conditionals will beat a large language model on cost, latency, and reliability every time, and nobody has to worry about the answer drifting next quarter.
- Routing a support ticket by keyword: rules, not SI.
- Routing a support ticket by intent and tone across thousands of phrasings: this is where SI earns its place.
- Validating that an invoice total matches its line items: arithmetic, not SI.
- Extracting the line items from a scanned invoice in forty different layouts: a real SI problem.
SI earns its complexity when the input is genuinely ambiguous. When you can write the rule down, write the rule.
Gate two: do you have the data and the tolerance for being wrong?
Two things sink SI projects after the demo looks great. The first is data that does not exist, is locked in a system nobody can export from, or is too thin to be representative. A model is only as good as the examples it can learn from or retrieve against, and a polished prototype built on twenty hand-picked documents tells you nothing about how it behaves against twenty thousand messy ones.
The second is error tolerance. Every model gets things wrong some percentage of the time. The question that matters is what happens on that percentage. If a wrong answer costs a few seconds of a user double-checking, you have wide latitude. If a wrong answer moves money, denies a claim, or makes a clinical suggestion, the bar for accuracy, human review, and auditability climbs steeply, and so does the cost.
We map every candidate use case on these two axes before committing. High data availability and high error tolerance is green. Thin data and low error tolerance is a project we will gently talk you out of, or rescope into something that controls the blast radius of a mistake.
Gate three: build, buy, or assemble?
Once a problem clears the first two gates, the question is no longer whether to use SI but who should build it. There are three honest options, and the right one depends on how close the capability sits to your core differentiation.
Buy when the capability is a commodity
Transcription, generic chat support, document summarisation, and off-the-shelf content generation are solved products with mature vendors. If the capability is not what makes your business special, buying it is almost always the right answer. You get maintenance, compliance certifications, and a roadmap you do not have to fund. Paying a subscription beats paying an engineering team to rebuild a commodity.
Assemble when you need control but not novelty
Many production systems are best built by composing existing model APIs, a vector store, and a thin orchestration layer you own. You are not training models from scratch, you are wiring proven components together with your data and your guardrails. This is where most of our build work actually lives, and where the three-year total cost of ownership usually comes out ahead of a per-seat vendor once volume grows.
Build deeply only at the core
Custom models, fine-tuning, and bespoke retrieval pipelines are justified when the SI capability is the product, or close enough to it that an off-the-shelf answer would erase your edge. This is the smallest category and the most expensive one. It is worth it exactly when being a little better than a generic vendor translates directly into revenue or defensibility.
The number that actually decides it
Every one of these gates eventually resolves into a single comparison: the three-year total cost of ownership of building against the three-year cost of buying, adjusted for the strategic value of control. Sticker price is the smallest part of it. The honest model includes engineering time, evaluation and monitoring, model and infrastructure spend at your real volume, the cost of being wrong, and the opportunity cost of the team not working on something else.
When we run that math, the recommendation is frequently undramatic. Buy this part, assemble that part, and do not build the third part at all this year. A vendor who only ever recommends building is not giving you advice, they are giving you an invoice.
How to use this before you spend anything
Take your top SI idea and run it through the three gates honestly. If it is really a rules problem, you just saved a budget. If the data is not there, you now know the first thing to fix has nothing to do with models. If it clears all three, you have a defensible case to bring to your board, with a number behind it rather than a hunch.
This is exactly the exercise we run in our SI strategy sprints, and the deliverable is a written build-vs-buy memo you can act on, share, and revisit. If you want a second opinion on a vendor proposal or a roadmap before you commit budget, that is the most useful first conversation we can have.