The Short Answer
Buy the software that every business needs and nobody competes on. Build the software that runs the workflow only you have, and only once the subscription bill or the bad fit is costing real money.
Most small businesses should do both. The two expensive mistakes sit at the extremes: paying per seat, forever, for a tool the team works around with spreadsheets, or commissioning a custom system to replace a $30-a-month product that already fits.
This guide is the decision, not the sales pitch. It gives you five tests, a side-by-side comparison, a worked three-year example using a real vendor's published prices, and a plain list of the cases where buying wins. If you're pricing a specific tool, our guide to how much a CRM costs has the vendor list prices; this page is about how to decide.
What "Build" Means Now
The build-versus-buy question got its reputation when building meant a long, open-ended project. Clutch's pricing data, drawn from verified client reviews, still shows that: the average reviewed software project costs $132,480 and runs about 13 months, though most projects on the platform land between $10,000 and $49,999.
Two things have changed for the small-business version of that decision.
First, the price model. Serious builders now quote a fixed price for a defined scope, not an hourly estimate that drifts. A focused system, such as a booking flow, a quoting tool, or a CRM around one pipeline, is a fraction of the multi-department average above. We quote after a free consultation and don't publish a single number because a two-stage pipeline and a three-branch job management system aren't the same build.
Second, the pace. AI-accelerated development with human review has moved a small system from months to weeks. That's how our custom business software work runs today: a usable core first, then extensions while the system is already in use.
What hasn't changed is the hard part. To build something, you have to know your process well enough to describe it. If you can't say what happens between a lead arriving and an invoice being paid, buy something and learn your process on it first.
Five Tests That Decide It
Run each one honestly. The answers usually point the same way.
1. Is the tool a commodity or a differentiator?
Accounting, payroll, email, calendars, card processing, file storage, password management. Every business needs these, none of them makes you better than a competitor, and several are regulated. Buy them. The candidates for building are the tools that encode how your business quotes, schedules, follows up, and gets paid, because a generic product can only approximate that.
2. What will the seat count be in year three?
Per-seat pricing is designed to grow with headcount, not with the work the software does. Count the people who need a login at the size you expect to be, not the size you are, and multiply. The three-year CRM math shows the same five people spending anywhere from $7,020 to $35,100 depending on plan, and adding three staff raising a bill by thousands a year for no extra function. If year three's number makes you wince, keep reading. If it's a few hundred dollars, buy.
3. How much of the tool do you use, and how much do you work around it?
The tell is side spreadsheets. If your team exports from the tool to a spreadsheet to do the real work, re-enters data in a second system, or has a "don't use that screen" rule, the fit is bad and you're paying full price for a partial solution. If the team lives inside the product without workarounds, the fit is good and the subscription is well spent, whatever the seat price.
4. How many tools are stitched together?
A single tool is rarely worth replacing. A stack is. When the booking tool, the CRM, the invoicing app, the form builder, and the client portal add-on each cost $20-$150 a month and hand data to each other through integrations that break, the case for one system replacing four subscriptions is much stronger than the case for replacing any one of them. Count the whole stack before you decide.
5. How stable is the process?
Building freezes a process into code. If your business model is still shifting, or you'd be automating a workflow you expect to change in six months, wait. Subscriptions are the right tool for a process you're still figuring out. Build when the process is settled and the tool is the thing holding it back.
Side by Side: Buy vs. Build
| Buy (subscribe) | Build (own) | |
|---|---|---|
| Upfront cost | Low: first month, sometimes an onboarding fee | The build fee, fixed if quoted properly |
| Ongoing cost | Per seat or per tier, billed monthly or annually | Hosting, support and changes, priced by usage |
| Cost when you hire | Rises with every login | Unchanged; a login is a role, not a billing line |
| Time to live | Days, plus configuration | Weeks for a focused system |
| Fit to your process | You adapt to the product | The product is your process |
| Changes | Wait for the vendor's roadmap, or buy an add-on | Request them; ours ship the way website automation changes do, described in text or voice |
| Ownership and data | You own the data contractually; exports are usually flat spreadsheets | You own the code and the database outright |
| Vendor risk | Repricing at renewal, discontinued plans, acquisitions | The builder disappearing, mitigated by owning the code |
| Ecosystem | Hundreds of integrations and features you may never use | Exactly the integrations you specify, and nothing else |
| Best when | Small teams, standard workflows, unsettled processes | Growing teams, specific workflows, multi-tool stacks |
The pricing pressure on the "buy" column is not a small-business phenomenon. Zylo's 2026 SaaS Management Index, which tracks large organizations, found average SaaS spend rose 8% year over year while the number of applications stayed flat, and 78% of IT leaders reported unexpected charges tied to AI features or consumption-based pricing. The growth is coming from how software is priced, not from buying more of it. Small businesses see the same thing at renewal, with less leverage to negotiate.
A Worked Example: A Field Service Stack
Take a service business with six people who need logins, using Jobber for scheduling, quoting and invoicing. At the time of writing, Jobber's Grow plan lists at $199 a month with no commitment, includes one user, and charges $29 a month for each additional user. (Jobber discounts committed plans; the no-commitment rate is used here because it's the one you can leave.)
| Team size | Monthly | Yearly |
|---|---|---|
| 6 users ($199 + 5 × $29) | $344 | $4,128 |
| 10 users ($199 + 9 × $29) | $460 | $5,520 |
If the team is six people in year one and ten in years two and three, the three-year total is $15,168, before card processing (which costs about the same either way) or add-ons. Four extra hires added $1,392 a year to the software bill without changing what the software does.
Now the build side. Suppose a custom scheduling-quoting-invoicing system runs on a $99-a-month plan after launch. The break-even formula is the same one from the CRM guide:
Break-even months = build fee ÷ (monthly subscription spend − monthly cost of running the custom system)
At ten users, the gap is $361 a month, so every $1,000 of build fee pays back in about 2.8 months. A build priced at one year of the subscription it replaces pays for itself well inside the second year, and the gap widens with every hire after that.
At two users, the same business pays $228 a month. The gap shrinks to $129, so every $1,000 takes almost eight months to recover, and a system that was still growing into its plan would likely never justify the build. That two-person business should stay on Jobber. So should the six-person one if it uses the whole product without workarounds. The numbers only tip toward building when the seat count is growing or the fit test in section 3 fails.
When Buying Is the Right Call
- You have one to three users and a standard workflow. A free tier or a low seat price beats any build fee.
- The product genuinely fits. No side spreadsheets, no double entry, no screens the team avoids.
- You need the ecosystem. If you rely on a vendor's marketing automation, call center, app marketplace, or hundreds of prebuilt integrations, those are expensive to replicate and cheap to rent.
- The process is still changing. Configure a subscription now; consider building once it settles.
- The tool is a commodity. Accounting, payroll, email, payments, storage. Building these is a liability, not an advantage.
When Building Wins
- Five or more seats and you plan to hire, especially on plans where the per-seat charge is most of the bill.
- Your work revolves around records generic tools handle badly: vehicles, properties, job sites, treatments, multi-branch permissions. People keep spreadsheets anyway.
- You're paying for three or more tools that don't talk to each other, and the integrations between them are where things break.
- Customers should be able to serve themselves. A client portal that shows job status, documents and invoices replaces both a subscription add-on and the front-desk calls it was meant to save.
- You want to own the system. Not as a principle, but because renewal pricing is set by vendors who know your history is inside their product, and ownership removes that lever. The benefits of a custom CRM go beyond price, and this is the one that compounds.
The Usual Answer: Buy the Commodity, Build the Workflow
In practice, the decision for most small businesses isn't build or buy. It's which layer gets which.
Keep the accounting software, the payment processor, the email and calendar. They're cheap, they're regulated or standardized, and every builder can integrate with them. Build the layer that sits between them and encodes how you work: the booking flow that shows only genuinely free slots and takes a deposit, the quoting tool that turns an inquiry into a numbered invoice with a pay link, the portal where customers check status instead of calling. That's the layer where a generic product costs you the most in fit, and where per-seat pricing costs you the most in growth.
It's also how the systems we run in production are shaped. A cleaning company's booking platform takes deposits through the owner's own Stripe account and syncs availability with the calendar they already used; it replaced a scheduling tool, a payments page and an invoicing app, not the accounting software behind them. A custom CRM built around a repair group's job pipeline still hands invoices to the books. The commodities stayed. The workflow got built.
Ongoing cost for a built system works the way our pricing model describes: a flat build fee, then a plan priced by what the system actually consumes, never by how many people log in.
Questions to Put in Writing First
Whichever way you lean, get these answered before money moves.
For a vendor:
- What does this cost at the headcount we expect in year three, including required onboarding fees and the add-ons we'll actually need?
- What's the renewal policy? Locked, capped, or open?
- How do we export our data, and does relationship and history come with it?
For a builder:
- Is the quote fixed, and what exactly is in scope?
- Who owns the code and the database, and what happens if we stop paying for support?
- How are changes handled after launch, and what do they cost?
- What's the first usable milestone, and when does it ship?
If you want a second opinion on your own numbers, bring your subscription list and headcount to a free consultation. We'll run the break-even with you. If the answer is "keep buying," that's what we'll say.