Off-the-shelf AI is the right buy when a product already does the job. Custom software is the right build when the job is special to how your business works and no product covers it. We start there because owners usually start at the other end. They hear that serious firms build, or they hear that nobody should build. Both speeches skip the one question that matters. Does a product already do this job, with a person you can name checking the output? If yes, buy it. If the job depends on your records, your exceptions, and your checker, a product will not make those up for you. That is the custom case, and it is rarer than the sales talk suggests.
- Cited in this note
- 58%
The studio takes the work that products do not cover. The consultant note covers what to ask before you pick either path. The agency comparison covers who to hire once you know you are building. It also helps if you know you should not be. We would rather lose a build than make a custom frame for a job that a sealed box already does. The box is not an insult. The box is how a small firm stays small instead of becoming a software company by accident.
What the surveys count
The Chamber’s 2025 report says 58% of small businesses use generative AI, up from 40% in 2024 and 23% in 2023.1 That is a claim about use. It is not a claim that those firms built their own software. Use can mean a tab someone opened, or a draft written inside a product they already pay for. The rise over those years says owners are trying the tools. It does not say they hired anyone to build something new. When a pitch borrows the 58% and then offers you a custom build, it has quietly changed the subject. The subject was use, but the bill is for a build, and those are two different purchases.

Salesforce asked 3,350 leaders at firms with 200 employees or fewer.2 In that survey, 75% were at least trying out AI, and 83% of growing small and midsize businesses said the same. Among firms already using AI, 91% said it boosts revenue. The survey does not say whether those tools were bought or built. Read that last sentence twice before you let a revenue line pick your plan. “At least trying out” is a very wide door. A revenue boost among people already using AI does not name a vendor. It does not name a pile of code you will have to feed, either. We have heard that revenue line used as a reason to build, but the line has no idea what was bought.
If a bought product covers the job, buy it. If the job depends on your records, your exceptions, and your checker, the product will not make those up, and that is the custom case. Records means the files you really keep, not the files a demo pretended you had. Exceptions means the customer you treat differently and the job you turn down. The checker means a named person who can say the output is wrong. If you miss any one of the three, you do not have a custom case. You have a wish that someone will design your business while they design the software.

A worked example
Take a shop whose reorder list already lives in the register. This is a walkthrough, not a result. The owner gets a flag when a staple item runs low, and the Saturday clerk trusts that flag enough to pull a box. The bookkeeper does not need a second opinion unless the flag is about a special order. A cousin in another trade told the owner to “build something with AI” after seeing a demo. Building here would mean a second list that drifts away from the register. It would also mean a login the clerk will not open on a busy Saturday. And the new list still could not tell a staple from a special order any better than the flag can. So keep the product you have, and spend your time on the one exception the flag gets wrong. Write down who decides that exception, and you are done. It might be a setting, or it might be a sentence on the wall, but it is not a custom build.
A trades desk is where we stop saying buy so quickly. A quote starts as a voicemail. Then it becomes a site note, picks up photos from the lead tech’s phone, and waits for the owner to set a price. The office manager sends it only after the price is there. No product they already pay for holds that whole stack. The accounting tool holds the invoice after the customer says yes, and the inbox holds the mess before that. A bought AI assistant can draft a friendly note and still lose the measurement. Custom, in this room, means a path that keeps the measurement, the photo, and the price gap together until the owner fills the gap. The price stays a gap on purpose, because we will not build a system that makes up a price. If a vendor says their shelf product already does the whole path, make them run yesterday’s quote in front of you. If they can, buy it. If they redraw your job until it fits their screens, you are back in the custom case. Or you are in the case where you change your job to fit a product. Changing the job is allowed. Pretending you did not change it is how the build gets blamed later.
A clinic usually looks like the shop until someone describes intake. Plain reminders are a product, and many booking tools already send them. Do not order a reminder engine just so the waiting room can say you built something. The custom candidate is the odd part of intake. That might be the practitioner’s rules about which visits are in scope, or the note that billing needs. It might be the patient who must be called instead of messaged. If those rules live only in the practitioner’s head, a product will not make them up. A custom build would only lock in a bad guess. Write the rules down first, and then see whether a product has a place to put them. Only the leftover is a build. We have watched clinics jump to the leftover and then find that the booking tool had a field for it all along. The field is not glamorous, and glamour is a poor reason to hire a developer.
How we’d run it
First, write the job as one sentence with a person on the output. The clerk acts on the reorder flag. The owner sets the price after the note is complete. The front desk sends the reminder after reading it. If the sentence has no person in it, you do not yet know what you are buying or building. You are really just shopping for a good feeling.
Second, list the products you already pay for and ask, in writing, whether any of them do that sentence. Ask the person who uses the product, not only the person who gets the bill. The bookkeeper knows whether late invoices are already flagged. The clerk knows whether the reorder flag tells the truth. The front desk knows whether reminders already go out. A consultant helps here when the owner is too close to the demo to see the product they already have.
Third, try the shelf product on yesterday’s real job before you talk to a builder. Do not use a sample record. Use the awkward one from yesterday, like the special order, the quote with the missing measurement, or the patient who has to be called. If the product handles the awkward one with a person checking it, stop there, because you have your answer. Custom work that starts before this trial is how you end up paying to find a checkbox.
Fourth, if the product fails, write down the exact miss. It might be “it cannot hold the site photo with the measurement.” It might be “it has no place for the practitioner’s scope rule.” That sentence becomes your spec. A builder who will not repeat the sentence back to you is about to build a different job, one their tools happen to like. The agency comparison only matters once that sentence exists. Before it, an agency is just a team making a guess.
Fifth, name the checker for the thing you buy and for the thing you build. A shelf tool with nobody checking it is still a risk. A custom tool with nobody checking it is a costlier risk, because you now own the repairs. The revenue line in the Salesforce survey is not a stand-in for that name. A boost among people already using AI does not tell you who presses send.
Sixth, decide what you will not maintain. Custom software is a long relationship with your own exceptions. If nobody on the desk can describe an exception a year from now, do not put it in code. Leave it as a human step. The cheapest system is the one that refuses to swallow a judgment call. We like that kind of cheap because it keeps the owner in the business they meant to run.
Common mistakes
One mistake is hearing “most small businesses use AI” and turning it into “most small businesses built their own.” The Chamber figure feeds that mistake all the time. The 58% counts use, and use went up over the years in that report. Use can be a login, a draft, or a feature inside something you already rent. We have had to say this in rooms where a relative had already told the owner that renting was naive. Renting a product that does the job is the grown-up move. Building a second copy of the register is the naive one, even though it wears a very serious face.
Another mistake is letting a revenue line pick your plan. Of firms already using AI, 91% said it boosts revenue. That is a report about users, not a promise about your custom build. It does not split bought tools from built ones. A shop can see a lift from a better reminder inside a tool it already has. A trades desk can see nothing from a custom portal that the office manager dislikes, and the survey cannot see that dislike. You can. The numbers 75% and 83% mean a lot of people are trying things, but trying is not a blueprint.
A third mistake is building a solved job because custom feels like owning something. That is how small firms end up with a second business they never wanted. Code you have no time to feed is a cost that looks like an asset in the proposal. The proposal shows a tidy system. The Tuesday after launch shows a clerk who still uses the register, and a new system that pings you when a field is empty. You will end up fixing both, and the cousin who suggested the build will not help.
A fourth mistake is skipping yesterday’s awkward job, which makes the trial lie. Teams test the easy path, and the easy path fits every product. Your business lives in the exceptions, like the refund you allow, the visit you refuse, and the price you will not put in an email. If the trial never touches those, you learned nothing. You watched a demo with your logo placed near it. Ask for the awkward one. If a seller will not run it, believe them, because they just told you the product does not cover the job.
A fifth mistake is freezing unwritten rules into custom software, and it feels a lot like progress. The practitioner’s scope rules are not on any page, so the builder asks about them for an hour and codes up that hour. Next month a case shows up that the hour never covered. Now the software is confidently wrong, and fixing it is a whole project. A product with a blank field would have been more honest. Write the rule until a new hire could follow it, and then decide whether it needs software at all.
What we’d do
We would buy first, and we would be stubborn about it. That is our opinion. For a shop, a clinic, and most trades desks, the default is the product that already does the sentence, with a named person checking the output. Custom is the leftover, not a personality. We do not think building is a sign of ambition. We think building is what you do when the leftover is real and you can point at it without waving your hands.
We would make any builder repeat the miss before they give a price. We would make any shelf vendor handle yesterday’s awkward job. We would keep the price, the clinic’s scope, and the exception for a regular customer in human hands. The one exception is a product with a clear place to hold the rule, and a person who still checks the result. We would not let 58% or a revenue number choose for us. Those figures count use and reported boosts. They do not count your records.
If you are staring at a proposal this week, put it down and open the tool you already pay for. Try the job once, on purpose, with the person who will live with the result sitting next to you. If it works, you are finished, and finished is a good outcome. If it fails, you will have the sentence that any custom work has to honor. Either way, you will not have bought a custom frame just to impress a chart.
Questions
When should you buy off the shelf?
When a product already does the job and you can name who checks the output. A custom build for a solved job wastes the budget.
When is custom software the right path?
When the job depends on records and exceptions a product does not cover, and you can still name the checker.
Does generative AI use mean firms built their own tools?
No. The Chamber’s 2025 figure, 58%, counts use. It does not count custom builds.
Sources
- Empowering Small Business Report 2025. U.S. Chamber of Commerce.
- New research reveals SMBs with AI adoption see stronger revenue growth. Salesforce. 2024-12-04.
All notes
- AI Agents for Business: When to Use One
- AI Agents vs Agentic AI: A Plain Split
- AI Automation Agency vs Consultant: Who to Hire
- AI Automation for Small Business: Which Job First
- AI Consultant for Small Business: What to Ask
- AI for Small Business: What the Surveys Still Say
- An AI Implementation Framework in Five Stages
- AI Readiness Assessment Questionnaire: The Themes
- AI Readiness Assessment: What It Measures and How to Score
- AI Readiness Checklist Before You Buy a Tool
- An AI Readiness Framework an Owner Can Score
- AI-Ready Data: What a Small Business Needs First
- AI Strategy for Small Business: Start With the Job
- Answer Engine Optimization: What Google Still Requires
- Business Process Automation With AI: Write the Job
- Generative Engine Optimization vs SEO
- How Can AI Help a Small Business? What Surveys Count
- How to Show Up in ChatGPT and AI Overviews
- How to Use AI in Your Business: Twelve Jobs
- Is My Business Ready for AI? Signs to Read First
- What Is an AI Agent? A Plain Answer for Owners
- What Is llms.txt, and Who Actually Reads It
- Why AI Pilots Stall After the Demo



