Short answer: buy or keep existing software when it covers the core workflow; configure it when fields, roles, and rules are the problem; connect tools when handoffs are the problem; build only when the process or data model is genuinely distinct and the evidence supports the cost and risk. Choose no-go when none of the options improves the operation enough.
Why this is not simply “build vs buy”
Most businesses have more than two choices. A current platform may be usable after configuration. Two good systems may need a dependable connection. A spreadsheet may only need one accountable owner and clearer rules. Starting with “custom or SaaS?” skips the cheaper and safer middle.
Compare the five decisions
| Decision | Best when | Primary risk | Evidence to require |
|---|---|---|---|
| Use | The current tool covers the core object model and workflow. | Buying something new to solve a training or process problem. | Actual feature use, workarounds, support history. |
| Configure | Fields, roles, states, templates, or reports do not match the operation. | Over-customizing a platform until upgrades become difficult. | Current-state map, role needs, missing rules. |
| Connect | Each system works, but staff copy data or chase handoffs between them. | Automating bad source data or creating silent sync failures. | System of record, field authority, error and recovery path. |
| Build | The business has a distinct object model or process that suitable software cannot support without rejected workarounds. | Underestimating discovery, migration, permissions, training, support, and recovery. | Alternative comparison, business case, bounded scope, migration inventory. |
| No-go / park | The value does not justify the cost or risk, or key evidence is missing. | Pressure to force a decision because discovery already consumed time. | Recorded unknowns, decision threshold, next evidence needed. |
When a custom build becomes credible
A custom build deserves serious consideration when at least two strong signals are present:
- No vertical tool covers the core object model without a workaround the owner refuses.
- The business pays materially for software while using only a small portion of it.
- The process is a real differentiator the owner will not change to fit a vendor.
- Per-seat pricing scales badly for many light users.
- Operational data lives in shared spreadsheets, and the rules exist mainly in the owner’s head.
These are screening signals, not automatic permission to build. Migration condition, integrations, mobile or offline needs, security, support, and recovery can still change the answer.
What discovery should document
- System of record. Which system is authoritative for each important object and field?
- Objects and states. What are the leads, customers, jobs, inventory items, documents, approvals, and statuses the operation actually uses?
- Roles and permissions. Who sees, creates, changes, approves, and administers each part?
- Data and migration. Where does the data live, how clean is it, and how will totals and counts be reconciled?
- Integrations. Which APIs, exports, or supported paths exist? What happens when one fails?
- Constraints. Mobile, offline, reporting, compliance, training, timing, and support requirements.
- Alternatives and unknowns. At minimum, compare existing software, a bounded custom option, and no-go.
Costs that a license comparison misses
Software cost is more than the monthly subscription. Compare implementation, configuration, migration, integrations, training, user pricing, change management, workarounds, support, backup and restore, and the operational cost of being unable to change a system later. A custom build replaces vendor constraints with ownership responsibilities; it does not make those responsibilities disappear.
Three guardrails that should not move
- Keep the accounting ledger where it belongs. An operating system may integrate with accounting; it should not casually replace the ledger.
- Do not automate consequential judgment. Models can parse uncertain input, while reviewed code applies explicit rules and a person approves action.
- Require a recovery path. Backups without tested restoration, integrations without reconciliation, and launches without rollback are incomplete designs.
Frequently asked questions
When should a small business build custom software?
A custom build should be proposed only when discovery supports it and at least two strong signals are present—for example, a distinct core process, unacceptable workarounds, poor software utilization, bad user economics, or risky shared spreadsheets.
Is configuring existing software usually cheaper than building?
Usually, but compare total operating cost: implementation, migration, support, user pricing, recurring workarounds, and the cost of changing the business to fit the software.
What is the safest first step?
Document the current system of record, business objects, states, roles, integrations, migration condition, constraints, and desired outcome before choosing a product or architecture.