Build custom software or buy off the shelf?
TL;DR: Buy off-the-shelf software unless your process is a genuine competitive edge. Most owners who want custom builds actually need configuration. Custom is justified for the narrow slice customers pay you for. Everything else, run on SaaS and spend the saved money on the business.
Buy first. Build only the part that makes you money. After watching owners spend $25k to $250k on software, the pattern is consistent: most custom projects rebuild something they could have configured in a tool they already own. The build-vs-buy question is not about technology. It is about which parts of your business are special enough to deserve your own code, and which parts are plumbing.
When does off-the-shelf software win?
Off-the-shelf wins whenever your problem is one thousands of other companies also have. Accounting, scheduling, CRM, inventory, payroll: these are solved. QuickBooks, Salesforce, ServiceTitan, and NetSuite have absorbed millions of dollars of refinement you get for a monthly fee. Buying means you skip the build, skip the bugs, and start next week instead of next year.
The math is brutal in SaaS's favor for common needs. A subscription costs hundreds per month. A custom equivalent costs tens of thousands up front, then maintenance forever. If you run an HVAC shop, ServiceTitan already handles dispatch, invoicing, and call booking. I help owners check that fit on the HVAC software advisor side before anyone writes a line of code.
When is building custom software actually justified?
Custom is justified when the software is the thing customers pay for, or when no product on the market fits a workflow that is your real advantage. The test is narrow: would a competitor lose to you because of how this specific step works? If yes, build that slice. If no, you are paying to reinvent QuickBooks.
Even then, you rarely build the whole system. You build the 10% that is yours and buy the 90% that is not. A manufacturer might run NetSuite for ERP and finance, then build one custom module for a proprietary production-scheduling method. That is a defensible split. I work through these calls with operators on the manufacturing and distribution technology advisor page.
What are the hidden costs of building?
The build price is the down payment, not the total. Total cost of ownership includes hosting, security patches, the developer you keep on retainer, and the rewrite three years out when your one engineer leaves and nobody can read the code. Technical debt accrues quietly until a small change takes a month.
- Maintenance typically runs 15% to 25% of the original build cost every year, indefinitely.
- API integrations to QuickBooks, Stripe, or your supplier feeds break when those vendors change, and someone has to fix them.
- An MVP that "just needs a few features" tends to double in scope before launch.
- Knowledge lives in one or two people's heads. When they go, your software becomes a liability you cannot change.
What are the hidden costs of buying?
Buying trades build risk for dependence. You inherit the vendor's roadmap, their price hikes, and their decision to retire a feature you depend on. Seat-based pricing on Salesforce or NetSuite that felt cheap at ten users gets heavy at two hundred. You bend your process to fit their software instead of the reverse.
Vendor lock-in is the quiet one. Your data sits in their format, your team's habits form around their screens, and leaving means migrating years of records plus retraining everyone. You blunt this before signing: confirm you can export your data, confirm there is an API, and read the offboarding terms while you still have leverage. For property managers weighing platforms with deep lock-in, I pressure-test those contracts on the property management technology advisor page.
How do non-technical owners avoid the classic mistake?
The classic mistake is paying to build a feature that already shipped in a tool you own. An owner describes a "custom" need, and four times out of five it is a report, a workflow rule, or an integration that QuickBooks or ServiceTitan supports through configuration. Separate "the vendor cannot do this" from "nobody set it up yet."
Before you brief an agency, get someone on your side of the table to map what off-the-shelf already covers. That is the core of what I do on my advisory work: I have seen the same request land across accounting firms, HVAC shops, manufacturers, and property managers, so I can usually tell within a call whether you have a build or a setup. Accounting practices in particular over-build around software that configures cleanly, which is why I keep a dedicated accounting firm technology advisor view. You can compare your situation across industries or just book a free 20 minutes to gut-check the decision before you spend.
What does the build-vs-buy decision look like in practice?
In practice it is a sorting exercise, not a single yes or no. List every capability you think you need. Mark each one "commodity" or "edge." Commodity goes to SaaS without debate. Edge gets a second look, and even most edge cases turn out to be configuration once you push on them.
What survives the sort is small, and that is the point. You buy NetSuite or Salesforce for the bulk, build one narrow module for the part that wins business, and connect them with API integrations. That keeps your custom surface area, your maintenance bill, and your technical debt low.
Key takeaways
- Buy off-the-shelf for any problem thousands of companies share: accounting, CRM, scheduling, payroll. QuickBooks, Salesforce, and NetSuite already solved it.
- Build only the slice customers actually pay you for, and buy everything around it.
- Custom software's true cost includes 15% to 25% yearly maintenance, integration upkeep, and an eventual rewrite, not just the build price.
- Buying carries vendor lock-in and price risk. Check data export and API access before you sign.
- Most "custom" requests are configuration. Have someone neutral sort commodity from edge before you brief an agency.
FAQ
Is custom software always more expensive than SaaS?
Up front, usually. A custom build runs $25k to $250k before it earns a dollar, then needs maintenance forever. SaaS spreads cost into a subscription. The flip happens at scale or when seat-based pricing on Salesforce or NetSuite outgrows what a paid-off build would have cost.
How do I know if my process is really unique?
Ask whether a competitor wins business because of how this step works. If the answer is no, the process is plumbing, and plumbing is a configuration job in QuickBooks or ServiceTitan. If a customer would notice and pay for the difference, that narrow slice may justify a build.
What is vendor lock-in and should I worry about it?
Vendor lock-in is the cost of leaving a platform: data trapped in their format, workflows shaped around their quirks, integrations you would have to rebuild. It is real with every SaaS tool. You manage it by checking export options and API access before you sign, not after.
Can I start with off-the-shelf and build later?
Often the smartest path. Run on NetSuite or ServiceTitan, learn where it actually hurts, then build only the narrow piece that earns money. You buy proof before you spend on a custom build, and your eventual scope is grounded in real friction instead of guesses.