Every week I talk with an owner who has been pitched a custom AI build by a developer, a vendor or a well-meaning nephew. The pitch always sounds the same: you will own it, it will fit your business perfectly, and it will be cheaper than paying a subscription forever. Sometimes that is true. Usually it is a spreadsheet that forgot about year two. Here is how I walk owners through the decision when money is on the table.
Why do most build decisions go wrong?
Because they are made on the first cost, not the full cost. A build quote covers the work to produce version one. It does not cover the person who keeps version one alive when the model provider changes its API, when a key employee leaves, when the security questionnaire arrives from your biggest client, or when the tool quietly stops working and nobody notices for three weeks. A vendor spreads all of that across hundreds of customers. You would be carrying it alone.
The second reason is pride. Owning a tool feels like an asset. In practice, a custom tool with one maintainer is a liability with a nice name, and the day that maintainer gives notice you find out how much of your operation depended on their memory. The question is never whether you could build it. It is whether building it is the best use of the two scarce things a mid-market company has: cash and leadership attention.
What is the three-question test?
Before any quote, answer these three questions in writing. If the answer to all three is no, buy and move on.
1. Is this work specific to how we make money?
Answering the phone, booking appointments, drafting a first version of a proposal, summarizing a meeting, chasing an invoice: these are the same in your company as in ten thousand others. Buy. Pricing a complex job the way your best estimator does, matching clients to advisors using 15 years of your own records, or producing the specific deliverable your customers pay you for: that is where a build can create something a competitor cannot buy.
2. Does a credible vendor already serve companies like ours?
Not a vendor who says they can. A vendor with reference customers your size, in your industry, who will put you on the phone with two of them. If that vendor exists, you are not choosing between build and buy. You are choosing between a proven product and a science project. The vendor test I use is the same one I described in the four-question test from 15 years of evaluating platforms on live TV: what does it do for a real person with a real problem, and can you verify it yourself?
3. Does the data need to stay inside our walls?
For most companies the honest answer is that a reputable vendor with the right contract terms protects data at least as well as you would. For a few, regulated data, trade secrets, or a client who contractually forbids third-party processing changes the answer. If that is you, a build on top of a major model through an API, with your data staying in your own systems, is often the only option, and the cost is simply the cost of being in your business.
What goes in the three-year cost model?
Build a simple table with two columns, buy and build, and seven rows. Fill in year one, year two and year three for each. Most owners have never seen the build column with all seven rows filled in, and it changes the conversation.
| Cost line | Buy | Build |
|---|---|---|
| License or usage fees | Subscription plus per-seat or per-use charges, which rise with volume | Model and API fees, hosting, monitoring tools |
| People | An internal owner at perhaps 10 percent of one role | At least one person at a fully loaded rate, plus backup, for as long as the tool exists |
| Integration | Connectors to your CRM, phone, calendar, accounting; often one-time, sometimes a fee | Everything, built and maintained by you |
| Data preparation | Cleaning and exporting what the vendor needs | The same, plus storage, access control and retention rules |
| Security and compliance | Review the vendor's documentation and contract | Your own review, testing, policies and client questionnaires |
| Training and adoption | Vendor onboarding plus your team's time | Your team's time, plus writing the documentation yourself |
| Exit | Data export, migration time, overlap of two subscriptions | The sunk cost of the whole thing if it is abandoned |
Two rules for filling it in. Count internal time at a fully loaded rate, salary plus benefits plus the work that person is not doing instead. And put a real number on the exit row for both columns, because the vendor that is cheap today will raise prices once you depend on it, and the build that looks permanent today will need to be replaced the moment the underlying model generation changes.
When the table is done, the build column is usually two to four times the buy column over three years for a general-purpose use case. That gap is the price of owning something. Sometimes it is worth paying. It should never be paid by accident.
How should you structure a first purchase?
Like a trial, with money on it. Ask for a 90-day paid pilot with three success metrics agreed in writing before you start: a time saved, a revenue number, or a response-time target. Follow it with a one-year term, never longer, and a cap on the renewal price increase. Get the data-use terms in writing, specifically whether your inputs are used to train the vendor's models, and insist on export in a format you could hand to a competitor the day you leave.
Then run the premortem I recommend for any spend, which I laid out in the post on premortem-first marketing. Picture the pilot failing at day 90 and write down why. Nobody on the team used it. It did not connect to the phone system. The vendor's support disappeared after the sale. Each of those has a cheap fix on day one and an expensive fix on day 91.
When is a build worth it?
When the three-question test says yes, the three-year table has been filled in honestly, and the following are true. The first version is small enough to ship in weeks, not quarters, and it produces one measurable result. It sits on top of a major model through an API rather than training anything yourself, because the model companies will improve the underlying capability faster than you can and you want to inherit that for free. There is a named owner and a named backup, with maintenance in the budget as a recurring line, not a one-time project. And the tool is close enough to how you make money that a competitor could not simply buy the same thing next quarter.
That last point is where builds earn their cost. When I helped a five-person team generate $32 million in revenue with AI-driven systems, the parts that mattered were not the parts you could buy. They were the specific ways we connected the tools to how that business found, qualified and closed customers. The tools were ordinary. The system around them was the asset, and it is the system, not the software, that I would encourage an owner to think of as something they build. That is the same idea behind what I call a revenue engine.
What should an owner do this week?
List every AI purchase or build currently being discussed in the company. Run each through the three questions. For anything that fails all three, pick the two best vendors, ask each for two reference customers your size, and set up a 90-day paid pilot with one of them. For anything that passes, build the three-year table before you take a single quote, and show it to your accountant and your most skeptical manager before you sign anything.
If you want that analysis done for you, with an audit of where AI pays in your specific business, deployment recommendations with ROI models, and a 90-day plan, that is what the AI Clarity Sprint is for. The details are on the engagements and FAQ page. The prompts and procedures your team will use once the decision is made are in ChatGPT for Profit, Volumes 1 and 2.
Frequently asked questions
- Is it cheaper to build or buy AI tools for a mid-market company?
Buying is almost always cheaper for the first two years, and usually for the third. A build looks cheaper on a spreadsheet because the spreadsheet forgets the people who maintain it, the model and API costs that move every quarter, and the security and compliance work that a vendor spreads across hundreds of customers. Compare total cost over three years, including internal salaries at a fully loaded rate, and the answer is clear for most use cases.
- When should a company build its own AI tool instead of buying one?
When the work is specific to how your company makes money and no vendor serves it well, when the data involved is sensitive enough that you need it to stay inside your walls, or when the tool is itself part of what you sell. Even then, build on top of a major model through an API rather than training anything yourself, start with the smallest version that produces a measurable result, and budget for maintenance from day one.
- What hidden costs should be in an AI build-versus-buy analysis?
Integration with the systems you already run, the staff time to clean and prepare data, training and change management for the team, security review, ongoing maintenance and model updates, usage-based fees that scale with volume, and the cost of switching if the vendor raises prices or shuts down. On the build side, add the fully loaded cost of the people who own the tool, including the risk that one of them leaves.
- How long should the first AI vendor contract be?
As short as the vendor will allow, ideally a 90-day paid pilot with defined success metrics, followed by a one-year term with a price cap on renewal. Avoid multi-year commitments until the tool has produced a measured result in your business. Insist on data export in a usable format, and get the terms on how your data is used in writing.
- Should AI tools be budgeted as operating or capital expense?
Most purchased AI tools are subscriptions and sit in operating expense. Some internal builds can be capitalized as software development. The accounting treatment depends on your situation and your accountant should make that call. This post is general education on the business decision, not accounting, tax or financial advice.
Want the build-or-buy call made with real numbers?
The AI Clarity Sprint gives mid-market companies, law firms, wealth managers and insurance agencies an AI audit, deployment recommendations with ROI models, and a 90-day plan in three weeks.