The question we get asked most often by service business founders right now: "should we just use [packaged AI tool], or do we need something custom?"
The honest answer is, sometimes packaged, often not. This post is the longer version of how we think about that decision.
What "packaged" actually means
Packaged AI is the category of products that takes a single, well-defined task (chat with my knowledge base, schedule meetings via email, generate first-draft proposals) and ships a SaaS wrapper around it. There are a hundred of them. Some are very good at the specific narrow thing they do.
The defining feature of packaged AI is that the interface, the data model, and the behaviour are all decided by the vendor. You configure parameters. You point it at your data. You do not change how it makes decisions.
That's not a criticism. It's the right product shape for problems that genuinely are average. Sometimes your problem really is "I need a chatbot that answers FAQs from my docs." Buy the chatbot.
When packaged is fine
Three conditions usually predict that packaged AI is the right call:
- The problem is generic. Lots of businesses have the same problem in roughly the same shape. Email scheduling. Meeting transcription. Knowledge base search.
- The cost of being wrong is low. A misrouted email is annoying. A misrouted million-pound contract is bad. The further up the consequence ladder, the more configuration and discretion you need.
- You don't need to change the behaviour later. If today's solution will still be today's solution in 18 months, the vendor's pace of change is good enough.
If all three are true, buy packaged. Skip everything else in this post.
When packaged isn't fine
The pattern we see in service businesses isn't any of the above. It's:
- The problem is specific to your business. The way you intake leads, the way your team triages, the way your operations interact, none of it looks like another company in the same industry. Especially if you've been in business more than a year or two.
- The cost of being wrong is high. Sales operations, qualification, fulfilment surfaces. The agent is making decisions that affect revenue.
- The behaviour needs to evolve. You will add nuance. You will need to ship a new policy. You will need to add a new tool.
When those are true, packaged AI does one of two things:
- It almost-but-not-quite fits, and you spend most of your time hacking around its limitations. (The most common outcome.)
- It fits well enough to be a productivity win, but you discover six months later that the vendor changed the product in a way that broke your use case, and you have no recourse.
What custom means in practice
Custom does not mean writing a model from scratch. It does not mean training an LLM. It is rare that you need to do either of those things.
It means building an agent system: a layer of code, designed around your specific business logic, that uses LLMs as one ingredient alongside your tools, your data, your rules, and your fallback policies.
A real agent system has:
- A typed tool layer. Functions the agent can call, defined in code, validated, observable. Not a free-form prompt asking the model to "use my CRM."
- An orchestration layer. Code that decides which agent (or non-agent process) handles what. The "router" in front of the system. Designed against your org chart, not against the tutorial.
- Eval coverage. Test cases for every behaviour you care about. When you ship a change, you know what breaks before users do.
- Monitoring. Every call, every tool invocation, every retry, logged and reviewable. You can answer "what did the agent do at 3pm on Tuesday" with confidence.
- Fallback policies. Explicit rules for what happens when the model is wrong. Real software treats failure as the default state. So does a real agent system.
This isn't conceptually new. It's how you'd build any revenue-critical software. The difference from packaged AI is that you control all of the above, instead of inheriting it from the vendor.
The build-vs-buy heuristic we actually use
When we're scoping for a client, the question we ask is: "is the value of this workflow coming from the prompt, or from the integration with your specific business?"
If the value is in the prompt, clever generation, smart summarization, good extraction, packaged AI is often fine. The vendor has someone doing prompt engineering full-time, and their version is probably better than yours.
If the value is in the integration, the way it reads from your CRM, writes back to your ops system, knows your business rules, follows your escalation logic, custom is the right call. Because the value is in the parts the vendor doesn't have.
About 70% of the "should we use AI?" conversations we have land in the second category. Service businesses don't have prompt problems. They have integration problems.
A worked example
Take a common surface: lead intake and qualification.
Packaged version: a SaaS tool reads inbound forms, parses them with an LLM, scores them on a generic rubric, and routes them.
Custom version: an agent reads inbound forms and checks them against your CRM (have we talked to this company before?), and looks up the lead's company against your client list (existing client adjacent? referral risk?), and applies your specific qualification rubric (which weighs your top 3 markers, not generic ones), and writes a one-paragraph briefing for the closer that includes the relevant context from past conversations, and schedules the meeting with appropriate buffer, and logs everything to your CRM in a structured way you'll be able to query later.
The packaged version saves you 30 seconds per lead.
The custom version replaces 20 minutes of an ops person's day per lead and produces a better-prepared sales call as a side effect.
The build cost of the custom version is real. Meaningful four-figure to low five-figure money. The break-even, for a business doing 50 qualified leads a week, is usually inside a month.
What this isn't an argument for
It is not an argument that everything should be custom. It's an argument that "we just need an AI tool" is almost never an accurate framing for a service business. Sometimes the right answer is no AI. Sometimes the right answer is one packaged tool. Sometimes the right answer is a small custom system. Sometimes, for the businesses where automation is genuinely transformative, the right answer is a multi-agent system that costs more than a junior hire and produces more value than a senior one.
The way to know which is which is to run an actual audit. That's the entire point of our AI Infrastructure engagement. The audit comes first, and we'll tell you honestly when the answer is "buy the packaged tool" or "don't automate this at all."
If you want to talk about your specific surfaces, the audit call is here. 45 minutes, scoping conversation, no obligation. If the answer is packaged-and-don't-overthink-it, we'll tell you.