Framed as custom software versus ERP, this decision has no good answer. Both sides are defensible in the abstract, so the argument gets settled by whoever is most confident in the room. The useful version of the question is narrower: which parts of this business are the same as every competitor's, and which parts are the reason customers pick us? Buy the first group. Build the second, and only the second. That rule resolves most of these debates in an afternoon, and it usually resolves them in favor of buying more than the people who called the meeting expected.
Buy the sameness, build the difference
Your general ledger is not a competitive advantage. Neither is payroll, sales tax calculation, benefits administration, accounts payable, or fixed asset depreciation. Thousands of companies have already solved these problems, regulators constrain how they can be solved, and the vendors who sell them absorb the cost of keeping up with changing rules. Building any of it means paying to reinvent something you can rent, and then paying again every time a tax jurisdiction changes.
The other end of the spectrum is the operating model itself: how work gets scheduled, priced, routed, inspected, escalated, and billed. This is where companies actually differ, and it is where platforms tend to impose someone else's assumptions. If your dispatch logic, your pricing structure, or your service model is why customers stay with you, encoding it in a configuration screen designed for the average customer is a slow way to become average.
Telling a real differentiator from a preference
Nearly every operations team believes its process is unique. Most of the time what they have is a preference: a way of working that grew out of a former system's limitations, a long-departed manager's opinion, or the shape of a spreadsheet someone built in 2011. Preferences feel identical to differentiators from the inside. They are separated by a few blunt questions.
- Would a customer notice if you stopped doing it this way? If not, it is internal preference.
- Can you point at revenue, retention, or margin that depends on it? A differentiator has a number attached.
- Did you choose this, or did a previous system choose it for you? Inherited constraints masquerade as requirements more often than anything else.
- Do your competitors do it differently and still win? Then the process is not what is winning.
- If the process were public, would it help a competitor? Genuine advantage is usually inconvenient to copy.
Run this on every workflow before scoping anything. Most operations come out of it with one or two workflows that clear the bar and a long list that does not. That list is the buy list, and shortening it is the single cheapest thing you can do to a project budget.
Function by function: buy, build, or integrate
The defaults below hold for most mid-market operating companies. They are defaults, not rules, but if you are departing from one, you should be able to say why in a sentence that mentions a customer.
| Function | Default | Reasoning |
|---|---|---|
| General ledger, AP, AR | Buy | Standardized by accounting rules and audit expectations. No customer has ever chosen a vendor because of its journal entry structure. |
| Payroll, benefits, tax filing | Buy | Compliance changes constantly and the penalty for getting it wrong is legal, not commercial. Rent the obligation to track it. |
| CRM and sales pipeline | Buy | Mature category, low switching cost, and sales process differences are usually about people rather than software. |
| Scheduling, dispatch, and routing | Build if it is your advantage | This is where operating models actually diverge. If throughput depends on how you sequence work, a generic scheduler will cap it. |
| Pricing and quoting logic | Build if it is your advantage | Complex, segment-specific, or contract-driven pricing is one of the most common places platforms force a downgrade. |
| Field and customer-facing experience | Build if it is your advantage | Per-seat licensing and generic mobile interfaces quietly reduce adoption, and unadopted software produces no data. |
| Reporting and analytics | Buy the tool, own the model | Use an existing BI tool. The differentiated part is the data model underneath it, not the chart library. |
| Document storage, email, identity | Buy | Commodity infrastructure with serious security obligations. Building here adds risk and subtracts nothing from a competitor. |
| The connections between all of the above | Integrate and own | This is the layer nobody sells you and everybody needs. Treat it as a maintained system, not a set of one-off scripts. |
The hybrid answer most companies should reach
Applied honestly, the framework rarely produces an all-or-nothing outcome. It produces a hybrid: a platform carrying the commodity functions, a purpose-built system carrying the one or two workflows that constitute the operating model, and a deliberate integration layer between them. The finance team keeps the software their auditors expect. Operations stops working around a scheduler that was never designed for their work. Neither side has to win the argument.
The integration layer is the part that gets underestimated. It is not a set of nightly exports. It needs a defined system of record for each entity, a sync direction, error handling that surfaces failures to a human, and someone whose job it is to maintain it. Budget for it explicitly. Hybrid architectures that fail almost always fail here rather than in either of the two systems they connect.
- 1
Decide the system of record for each core entity (customer, job, invoice, employee) and write it down. Two systems both believing they own customers is the most common source of silent data drift.
- 2
Keep the commodity platform as close to stock as you can. Every customization you add to it becomes an upgrade liability.
- 3
Build the differentiated workflow as its own system with its own data model, not as an extension bolted onto the platform's schema.
- 4
Make the integration observable. Failures should page someone, not accumulate quietly until month-end close.
Total cost of ownership over five years
One-year comparisons always favor buying, because the platform's cost is spread over a subscription and the custom build's cost is concentrated up front. Five years is the honest window. It captures renewal increases, the implementation partner you keep on retainer, paid connectors, version upgrades, and the labor cost of the manual workarounds people invent when the software does not fit, the last of which never appears in a business case because no one issues an invoice for it.
| Cost line | Platform only | Custom only | Hybrid |
|---|---|---|---|
| Licensing and renewals | High and rising | None | Moderate, fewer seats |
| Initial implementation | Moderate | High | Moderate to high |
| Ongoing change and support | Low but constrained | Moderate and yours to control | Moderate |
| Integration maintenance | Low | Moderate | Moderate and unavoidable |
| Compliance and regulatory updates | Vendor absorbs | You absorb | Vendor absorbs the risky parts |
| Manual workaround labor | Often the largest hidden line | Low | Low |
| Risk if it goes wrong | Throughput capped by the platform | Capital spent rebuilding commodity features | Contained to the integration layer |
The two failure modes
Building commodity functionality badly
A team decides the platform is the problem and rebuilds the whole thing, general ledger included. Two years later they own a mediocre accounting system that no auditor likes, they are absorbing tax rule changes themselves, and the workflow that actually needed custom software got the last four weeks of the budget. This failure is usually driven by frustration with a vendor rather than by any analysis of where advantage lives.
Bending the operation to fit the platform
The opposite failure is quieter and more common. The platform cannot express how the work runs, so the process is reshaped to match the software. Steps get added, staff start keeping a parallel spreadsheet, field users are left off the license count, and throughput drops a few percent a quarter. Nobody records this as a software failure because it arrives as a series of small operational compromises. It shows up in the numbers a year later as capacity that used to be there and is not.
A trades services business paying enterprise cost for software that made field work harder moved dispatch, mobile field updates, and invoicing onto a bridge stack in six weeks, then built the permanent platform around how the work actually ran, while accounting stayed where it was.
How to run the decision
- 1
List every major workflow and mark each as differentiating or commodity, using the five questions above. Do this with operations in the room, not just leadership.
- 2
For anything marked differentiating, ask what revenue or retention depends on it. If nobody can answer, move it to commodity.
- 3
Price the commodity list as a platform purchase and the differentiating list as a build. Compare over five years, workaround labor included.
- 4
Design the integration layer before committing to either side. If you cannot describe how the two systems stay in sync, you are not ready to sign anything.
- 5
Start with one differentiated workflow in production rather than a full replacement. If the framework was wrong, you find out in weeks for a bounded cost.
If you work through this and the answer is that your current platform fits, keep it. A system that constrains nothing that matters is not a problem worth spending capital on, and replacing it because it is unfashionable is the most expensive mistake available in this category.
Common questions
- Is custom software always better than an ERP?
- No, and for most companies it is worse across most functions. Platforms carry the cost of regulatory change, security, and feature maintenance for problems that are identical across thousands of businesses. Custom software earns its cost only where your operating model genuinely differs and that difference is why customers choose you.
- How do we know if our process is a real differentiator?
- Ask whether a customer would notice if you stopped doing it, and whether you can point to revenue, retention, or margin that depends on it. If neither answer is yes, it is a preference, usually one inherited from a system you no longer run. Preferences should be adapted to a platform, not encoded in custom software.
- Can we run a platform and custom software at the same time?
- Yes, and that is the right answer for most operations. Keep the platform for finance, payroll, and other commodity functions, build the differentiated workflow separately, and connect them deliberately. The requirement is a real integration layer with a defined system of record per entity and monitored failure handling, not nightly exports.
- What does the hybrid approach cost compared to just buying?
- More up front and often less over five years, though it depends entirely on how much workaround labor the platform-only path requires. The comparison should include licensing increases, implementation partners, paid connectors, and the hours your team spends re-keying data and maintaining shadow spreadsheets. That last line decides most of these cases.
- Our ERP is frustrating everyone. Is that enough reason to replace it?
- Frustration is a signal, not a diagnosis. Find out whether the platform is capping something measurable (throughput, invoice speed, field adoption, order accuracy) or whether the pain is configuration and training. Replacing a system for the second reason is expensive and tends to reproduce the same problems in new software.
- Where should we start if we think custom software is justified?
- Start with one differentiated workflow running in production with real users and real data. It validates the framework at a bounded cost and produces something useful even if the larger plan changes. Full replacements that begin with everything at once discover their wrong assumptions late, when they are expensive to correct.