Build vs Buy: How to Decide for a Small Business
A practical build-vs-buy framework for small businesses: when off-the-shelf software wins, when custom development is worth it, and the hidden costs on both sides most owners miss. From a team that builds custom software and still says "buy" most of the time.
The default answer is buy
We build custom software for a living, so weigh this accordingly: most of the time, you should buy. SaaS has eaten the commodity layer of business software. Accounting, email, CRM, payroll, scheduling, e-commerce. Mature vendors have spent decades on those problems, and a subscription gets you all of that work for less than one week of custom development costs.
Most "we should build our own" instincts fail the same way. They compare the subscription price to the build quote and stop there. The real comparison is the five-year cost of each path, including everything below the surface, and we'll get to that. So custom should be the exception. The catch is that when the exception applies, it applies hard, and telling the difference is worth real money.
When building beats buying
- Your workflow genuinely doesn't fit any vendor's data model, and you've actually gone looking.
- The software runs the operation that makes your business what it is, not some commodity function around it.
- You need integrations that off-the-shelf tools don't offer.
- You're paying enterprise prices for a product and using a tenth of it.
- Vendor risk is real for you. A price hike or a sunset notice would hit a process you depend on daily.
A real example: when the workflow is the business
Our client Bagel Nosh, a regional bagel shop chain, ran weekly warehouse ordering on paper. Printed order sheets, faxed to a central warehouse, picked with handwritten margin notes, filed in a binder. On paper, and we mean that literally, this looks like a buy problem. Inventory software is a crowded category.
But their operation is specific in ways generic tools don't model. A central warehouse supplying their own retail stores. Partial fulfillment, where "short two cases" needs to land on a specific line item instead of in a margin. Orders drafted by retail employees that wait for a store manager's sign-off. Warehouse-only raw ingredients that must never ship to a store. Production runs that pull recipe ingredients out of stock automatically. To a generic inventory product, those are edge cases. To this business, they're Tuesday.
So we built it. The platform mirrored the paper form the staff already knew, which meant training took almost nothing, and it went from proof of concept to production in about four and a half months. Every store order now runs through it with a full audit trail. The deciding factor wasn't that off-the-shelf inventory software is bad. It's that this workflow was the core of the operation, and forcing the business into a vendor's data model would have meant giving up the way they actually work.
When buying beats building
- It's a standard business function. CRM, accounting, HR, email marketing. Your version won't be better, just more expensive.
- You're not an expert in the domain. Payroll tax rules and card-payment compliance are someone else's full-time job for good reason.
- You need it live this week, not this quarter.
- Nobody in your company can own software long-term. Custom code without an owner rots.
The hidden costs on both sides
What buying really costs
- Per-seat pricing that grows with your headcount, forever.
- The add-on tax. The feature you need always seems to live one plan up.
- Workarounds. Staff time spent bending your process to fit the tool, which nobody measures until you add it up.
- Switching costs if the vendor raises prices or changes direction. Data export is rarely clean.
What building really costs
- Maintenance, forever. Security patches, dependency updates, hosting. Software is a pet, not a rock.
- Feature requests from your own team once they see what's possible.
- Key-person risk if one developer holds all the knowledge. Insist on documentation and code ownership.
- Your own attention while the build is underway, which is worth more than the invoice.
A vendor who tells you both of those lists is advising you. A vendor who only tells you one is pitching you.
The decision framework
- Is this a commodity function? Buy it and move on.
- Is this workflow something a competitor can't copy by buying the same subscription? Lean toward building.
- Can you pilot with off-the-shelf first? Usually yes, and even a failed pilot teaches you your real requirements cheaply.
- What does each path cost over five years? Subscriptions, seats, and workaround labor on one side. Build cost plus maintenance on the other.
The hybrid answer most businesses should land on
In practice, the businesses that get this right run a hybrid. SaaS for every commodity function. Custom software for the one or two workflows that make the business what it is. Integrations connecting the two. Buy your accounting system. Build the thing that's actually yours.
If you're staring at this decision right now, do one thing before you talk to any vendor, including us: write the workflow down as a one-page problem statement. What happens, who does it, where it breaks. That single page makes every quote comparable and every demo easier to judge. And if you want a second opinion with no build attached, that's exactly what our consulting engagements are for.
Frequently asked questions
Over a five-year horizon, buying is almost always cheaper for commodity functions. Building wins only when the software is a real competitive differentiator and you stay disciplined about scope.
Need help with a real project?
Free 30-minute discovery call. We’ll tell you honestly whether your project is one we can help with.