There is a SaaS tool for every AI use you can name. AI receptionist, AI inbox, AI quoting, AI for your CRM. Each one costs $99 to $499 a month, each has a slick demo, and each promises to be running by Friday. Meanwhile someone told you custom software is now cheap and fast because of AI coding tools, and a consultant wants to build the same thing for you.
The build vs buy AI decision is not about which is better. It is about which fits the specific job, how much of your business it will touch, and what happens in two years when you want to change something. Get it wrong one way and you own software you cannot maintain. Get it wrong the other way and you rent a tool that owns your data and your process.
This article gives you the decision rules, the lock-in traps to check for before you sign, and the middle path most businesses should take.
What this actually is
“Buy” means subscribing to a finished product someone else runs: you configure it, you do not control it, and you pay monthly per seat or per usage. “Build” means having software written for your business that runs in accounts you own: you control it, you are responsible for it, and you pay once to build it and a little to run it. Between them sits a third option that did not really exist five years ago: assembling a system from open, well-supported components (an automation platform like n8n, a database like Postgres, a model provider’s API, a small web app) so that most of the parts are standard and only the glue is yours.
The analogy is a company vehicle. Buying a SaaS tool is leasing a car with a locked hood: cheap to start, no surprises, but you drive what they give you and the lease never ends. A full custom build is having a vehicle made to your spec: exactly right, and yours, but you had better have someone who can service it. The middle path is buying a standard chassis and fitting it out: standard parts anyone can service, custom where it matters. In our view that is where most businesses of 5 to 200 people belong, and the rest of this article explains how to tell.
The build vs buy AI decision rules
1. Buy when the job is generic and the tool is the whole job
If what you need is the same thing ten thousand other businesses need, in the same shape, a good SaaS product will do it better and cheaper than anything built for you. Meeting transcription and summaries. A chat assistant seat for each employee. Basic appointment reminders. Grammar and drafting help. These are commodity jobs, the vendors compete hard, and the product improves monthly without you lifting a finger.
The test is whether the tool does the whole job on its own without needing to know anything specific about your business. If it does, buy. Do not have a developer rebuild a commodity.
2. Build when the job depends on your data, your rules, or your systems
The moment the job needs your price list, your policy exceptions, your order history, or a connection into your job management or accounting system, generic tools start to strain. They connect to the big-name systems through pre-built integrations and treat everything else as an afterthought. Your rule that “repeat customers over $5k get a callback from the owner” is not a checkbox in anyone’s product.
Built systems are the right answer here because the value is precisely in the specifics. The classifier that knows your categories. The quote drafter that uses your margins. The agent that checks your inventory before it promises a date. A generic tool can approximate these and will always be slightly wrong in ways your staff learn to work around, which is how you end up paying for a tool and still doing the work by hand. Start with How to Add AI to Existing Software Without Breaking It if you already have a system to extend.
3. Buy to learn, build to keep
A useful pattern: subscribe to a SaaS tool for three months as a paid experiment. You learn what the job really involves, what the edge cases are, what your staff actually use, and whether the volume justifies anything more. Then decide. If the tool is good enough, keep it. If it is close but not right, you now have a precise specification for what to build, which is worth more than any discovery workshop.
The trap is forgetting to decide. Month four becomes month forty, the tool has your data, and your process has bent itself around the tool’s limits. Put a review date in the calendar when you sign up.
4. Check the four lock-in traps before you sign anything
Lock-in is what makes a cheap subscription expensive later. Four questions expose it. First, can you export everything (conversations, documents, configurations, logs) in a usable format, today, without asking? Second, who owns the prompts and the knowledge base you build inside the tool, and can you take them with you? Third, does the price scale by seat or by usage in a way that punishes growth, and are your automations charged per seat even though no person uses them? Fourth, if the vendor is acquired or shuts down, what do you have left?
Read the terms for training clauses too. Some tools reserve the right to use your data to improve their product, which in practice means your customer conversations become someone else’s training material. AI Data Privacy for Business, What Happens to Customer Data lists the exact clauses to look for.
5. Do not buy the demo
Every AI SaaS demo runs on clean data and friendly questions. Before you subscribe, run it on your ugliest real example: the angry email, the scanned invoice with coffee on it, the customer who asks three things at once. Ask what happens when it does not know. Ask to see the log of a failed interaction. A vendor who has a good answer to “show me it failing” has a real product.
6. Understand what changed about building
Custom software used to mean six-figure quotes and a year of meetings, and that reputation is why owners still flinch at “build.” That is no longer the situation. Agentic coding tools (software that plans and writes software under an engineer’s direction, such as Claude Code, Cursor, and similar) have collapsed the cost of the ordinary parts of a system: the forms, the database tables, the integrations, the admin screens. A system that took three months now takes weeks, and a competent scope is measured in days of work rather than quarters.
What did not get cheaper is judgment: deciding what to build, designing the guardrails, integrating with systems that have no clean interface, and taking responsibility for the thing in production. That is what you are paying for now, and it is a much smaller number than it was. The Cost of Custom Software in 2026 After Agentic Coding goes through this properly.
7. Take the middle path when you can
Most systems we build are mostly not custom. The automation runs on n8n, which is open source and can be hosted anywhere. The data sits in Postgres, which every developer on earth can work with. The model is called through a provider’s standard API, and the code is written so the provider can be swapped. The web app is a plain framework that any competent developer can pick up. Only the parts that are genuinely yours (the prompts, the rules, the specific integrations, the review screens) are written from scratch.
This gets you the fit of a build with most of the maintainability of a buy. If the person who built it disappears, the next developer opens familiar tools. If a component gets a better alternative, you swap it. The practical trade-off is that someone has to run it, which is why the platform choice in n8n vs Make vs Zapier for a Business Without a Developer matters.
8. Whatever you choose, keep it in accounts you own
This is the rule that saves businesses. The provider API key, the automation platform account, the server, the domain, the database: all registered to your company, with your billing details, with the builder or vendor added as a user you can remove. If a vendor insists on running your automation inside their account, that is a rental with a hostage clause, whatever the contract says. If a developer sets things up under their own accounts “for convenience,” ask them to move it before launch.
Picture a business like this one
The business below is a composite of the kind of company that writes to us, not a client. The numbers describe the shape of the problem, not a case study.
Picture a business like this one: a specialty distributor with 28 staff, 900 active accounts, and a sales team that spends a third of its time producing quotes from a price book with customer-specific discounts and stock that changes daily. The owner has trialled two AI quoting SaaS tools. Both produced beautiful quotes with the wrong prices, because neither could read the discount matrix or the live stock feed, and the sales team went back to spreadsheets.
Applying the build vs buy AI rules: the job depends entirely on the business’s own data and rules (rule 2), the trial has already produced a precise specification (rule 3), and both tools failed the ugly-example test (rule 5). This is a build, on the middle path.
What gets built:
- A small web app, in a standard framework, that holds the price book, the discount matrix, and a nightly import from the inventory system.
- An inbox step on n8n that spots quote requests, extracts the items and quantities with a model, and creates a draft quote in the app with live prices and stock.
- A review screen where a salesperson checks the draft, adjusts, and sends, with every change logged.
- Everything in the company’s own accounts: the server, the model API key, the n8n instance, the domain.
What changes is that quotes go out in minutes with the right prices, the sales team’s time goes to customers, and the discount rules live in one place that the owner can see and change. Meanwhile the team keeps its bought tools for the commodity jobs: meeting notes and a chat seat each.
What it costs to run
For the distributor above, the running cost is the middle path’s usual shape. A small server for the app and n8n, $15 to $30 a month. Model usage for extracting a few hundred quote requests a month, single-digit dollars. A database on the same server, $0, or a managed Postgres for $15 to $25 a month if you prefer not to run it. Backups a few dollars. Total tooling under $75 a month, with the exact figures on the current pricing pages. The bought tools alongside it, meeting notes and chat seats, run $20 to $30 per person per month. Then the upkeep: a few hours a month from whoever maintains the system, and the sales manager’s time reviewing drafts, which is time they were already spending on quotes. Compare that to the two SaaS quoting tools at $200 to $400 a month each that did not work.
The mistakes we see most
- Building a commodity. Paying a developer to rebuild meeting transcription or a grammar checker. Buy those.
- Buying a specialty. Subscribing to a generic tool for a job that lives in your data and rules, then paying staff to work around it.
- Never ending the trial. The three-month experiment that becomes a permanent, unexamined line item.
- Signing without checking export, ownership, and training clauses. Lock-in is only discovered on the way out.
- Letting the build run in someone else’s accounts. A system you cannot log into is a system you do not own.
- Fully custom when standard parts would do. A bespoke database and a bespoke automation engine, when Postgres and n8n exist, is a maintenance bill with no upside.
When to bring in help
An owner can handle the buy side alone: trial the tool on real examples, read the terms, set a review date. An owner with a little patience can also run a simple middle-path system on a no-code platform for low-stakes jobs.
Help is worth paying for when the job is specific to your business, touches your real systems, or has money or customer trust riding on it. A good builder will tell you which of your ideas should be bought, which should be built, and which should wait, and will put the whole thing in your accounts. The questions to ask them are in How to Hire an AI Consultant Without Getting Burned.
Levelbrook builds on the middle path for businesses: standard open components, custom only where it is yours, fixed price from a written scope, everything in accounts you own, and a plain handover so any developer can maintain it. If you are weighing a build against a subscription, the form below is a good place to describe the job.