For most of the history of small business, "build or buy" was a question with one answer. You bought. Building meant hiring a developer, and few owners with twelve employees had that money or that patience. AI models changed the arithmetic. An owner who can describe a job clearly can now get a working tool for it, sometimes in an afternoon.
So the question has three honest answers now, and each is right some of the time. You can build, you can buy, or you can pay someone to help with the part that's genuinely hard. The decision is finally yours to make, which also means the mistakes are.
Why bought software fits everyone a little
Prebuilt software is designed for the average of a thousand businesses. That's how it gets to a price anyone can pay. The vendor studies what most of its customers need, builds that, and adds settings for the common variations.
If your business sits near that average, the fit is good and you should buy. If it doesn't, you spend your days working around the product. A lawn crew's scheduling app that assumes every job takes the same time each week. A bakery's ordering system with no field for the wholesale customer who pays on a different cycle. A small law office using a practice manager built for firms ten times its size, clicking through screens it will never need.
Owners usually blame themselves for this friction. They shouldn't. The software was built for someone else's average, and the vendor made a sensible choice when it did.
When building fits
Building from your own written description fits for a simple reason. You defined it, so it does what you described and nothing else.
The tools that come out well tend to share three traits. The job is specific to how you work. A mistake is cheap and easy to spot. And you can write the job down in a page or less. A retail shop that wants a weekly report of which items sold out before Saturday fits all three. So does a dental office that wants new-patient intake answers turned into a one-paragraph summary for the hygienist. If the summary comes out wrong, someone notices before the patient sits down.
The writing is most of the work. A model builds from your description, so a vague description gets you a vague tool. Defining what you actually want before you hand it over matters more here than anywhere.
Building has a cost owners forget, and it's upkeep. Somebody has to fix the tool when a supplier changes its file format or the tax rate moves. Count that before you start. A tool nobody maintains is a tool you'll stop trusting by spring.
When buying is right
Buy the commodity. Card processing, payroll, email, and the phone system work the same for a dental office and a hardware store, and vendors have spent years getting the edge cases right. Owning that plumbing is a poor use of your attention.
The test I'd apply before signing is short. If you left this product tomorrow, what could you take with you? Your customer list, your transaction history, and your records belong to you, and a product that makes them hard to export is charging you for something besides the software. Knowing which parts are commodity and which are core is the data-ownership side of this same decision, and it's worth reading next to this one.
When to get help with the hard part
The third answer is the one people skip, usually because it costs money they can see.
Some jobs are high-stakes, hard to check, or regulated. A mistake there is quiet and expensive. A therapy practice that wants AI to summarize session notes is handling health records, which brings federal privacy rules into it. A law office drafting with AI has duties of client confidentiality that don't relax because the tool is convenient. The post on HIPAA and AI for regulated offices walks through what those rules ask, and they ask a lot.
In those cases, getting help is the responsible move. Building it yourself is possible, and that's exactly the trap. The tool will appear to work. What you can't see on your own is whether the data went somewhere it shouldn't, or whether the agreement with the vendor covers what you think it covers. You're paying for someone who knows where those failures hide.
Help can be narrow. Often an expert sets up the part with the risk in it and you run the rest.
The calculus, in order
Here's the sequence I'd run on any job before deciding.
- Write the problem down. One page, plain language. If you can't, stop here, because none of the three options will go well yet.
- Ask whether it's commodity. If every business your size does this the same way, buy.
- Ask what a mistake costs. If the answer involves regulators, lawsuits, or someone's safety, get help.
- Weigh time, effort, and risk for what's left. Time to build, effort to maintain, and risk if it breaks.
Most jobs fall out at step two. A few fall out at step three. The ones that make it to step four are where building starts to pay, because they're the jobs that fit your business and no one else's.
| Answer | Fits when | Example from this post |
|---|---|---|
| Build | The job is specific to how you work, a mistake is cheap to spot, and it fits on a page | A weekly report of which items sold out before Saturday |
| Buy | The job works the same for every business | Card processing, payroll, and email |
| Get help | A mistake would be expensive, hard to see, or regulated | AI summaries of a therapy practice's session notes |
Whose decision this is
For a long time a vendor's sales team, a consultant, or the limits of your budget made this choice for you. That's no longer true, and I think that is a bigger change than any single tool. The owner who writes the problem down gets to decide.
I'll admit the framework has a soft spot at step four. Owners tend to underestimate upkeep, and I'm not sure anyone has a good rule for guessing it in advance. If you want a second opinion on where a particular job falls, that's the kind of question our services are built around.