Buyer resource
Build vs Buy: When Custom Software Is the Wrong Answer
Buy software when your need is genuinely common and a market product covers it without heavy rework; build when the process is a real competitive advantage, when integration with your own equipment or data is the point, or when bending a product to fit costs more than building. Most businesses should buy the core and build only the edges.
Published · Last reviewed by Geek Engineering senior engineering review.
The default answer is buy
This is a software company saying it: most business needs are common needs, and common needs are served better by products that thousands of companies already use. Accounting, email, CRM, scheduling, document storage and payroll have mature products whose yearly license costs less than a week of custom development. Custom software earns its cost only where your process is genuinely different in a way that matters.
The expensive failure is not choosing wrong once; it is drifting — buying a product, then paying year after year to customize it into a bespoke system you now own the worst half of.
When buying is right and when building is
| Situation | Usual answer | Why |
|---|---|---|
| The need is common across many businesses (accounting, CRM, email) | Buy | Products amortize development across thousands of customers; you get updates and support included |
| The process is a real source of advantage you refined over years | Build | A product flattens your process into its own assumptions, which gives your advantage away |
| The software must talk to your own equipment, machines or data | Build the integration layer | Connecting what is yours is exactly what products cannot anticipate |
| A product covers most of the need with light configuration | Buy and adapt the process | Changing a working product less beats changing your process more only when the process truly matters |
| Configuring the product would cost more than building | Build | At that point you are paying custom prices for someone else's roadmap |
| The need is urgent and the team is small | Buy now, revisit later | Speed matters more than fit while the business is proving the need |
Compare total cost of ownership, not purchase price
Run the comparison over several years, not one. Products usually win early years; custom can win later ones when license counts grow or the product needs constant workarounds. The crossover point is the decision.
- Buy: licenses per user per year, implementation and configuration, training, the cost of adapting your process, integration work, and the exit cost if the vendor raises prices or retires the product
- Build: design and development, hosting, security and dependency maintenance, support, the cost of the features you will inevitably add, and the risk of depending on whoever built it
- Both: data migration in, data migration out, and the management time nobody budgets
The hybrid that usually wins
Buy the commodity core and build the edges: a purchased ERP or CRM with a custom integration to your production data; a standard e-commerce platform with a custom configurator; off-the-shelf accounting with a custom job-costing feed. The product handles what is common, the custom layer handles what is yours, and each can be replaced without losing the other.
The discipline that makes the hybrid work is keeping your data exportable and your custom code at the edges, talking to the product through its supported interfaces rather than modifying its internals.
A decision checklist
- Write the need down in one page without naming any product or technology.
- Check honestly whether the need is common; if two market products cover it, the burden of proof is on building.
- Trial the best product against your real work for a month, and list every place it fights your process.
- Price the fight: configuration, workarounds, process change, per-user licenses over several years.
- Price the build over the same years, including maintenance and support, not just construction.
- Whichever way you go, keep your data exportable and your integrations documented, because every decision gets revisited.
How vendors bias the answer
Product vendors present configuration as free and process change as easy; development firms present products as straitjackets and custom as freedom. Both are selling. The useful correction is to make every party price the whole lifecycle in writing — licenses, configuration, maintenance, support, exit — and to be suspicious of any answer delivered before the one-page need has been read.
Key takeaways
- Buy for common needs; build where the process is genuinely yours.
- Judge on total cost of ownership over years, not purchase price.
- The strongest pattern is a bought core with custom edges.
- Keep data exportable so the decision stays reversible.
Related questions
Should a small manufacturer build a custom ERP?
Almost never. ERP is a solved, commodity category with decades of product maturity, and a custom one makes you the sole maintainer of your most critical system. The usual right answer is a standard ERP plus custom integrations to the things that are genuinely yours: machines, quality records, scheduling quirks.
What is the difference between configuring and customizing a product?
Configuration uses the product's own settings and stays supported through upgrades. Customization changes or extends the product's behavior with code, which you now own and must retest at every upgrade. Configuration is usually cheap; heavy customization is where buy quietly turns into build at product prices.
When does buying quietly become more expensive than building?
When per-user licenses grow with the company, when the product needs permanent workarounds that burn staff time, or when customization has gone deep enough that upgrades are projects. If the yearly cost of licenses plus workarounds approaches what a focused custom tool would cost to build and run, it is time to re-run the comparison.
Who owns custom software after it is built?
Whoever the contract says. Insist on source code delivered in a repository you control, documentation that lets another developer take over, and accounts — hosting, domains, services — registered to your business. Ownership on paper without the ability to run or change the system is not ownership.
Our business runs on spreadsheets; is that a build or buy problem?
First it is a process problem: map what the spreadsheets actually do and who touches them. Often a market product replaces most of it, and a small custom piece handles the genuinely unusual part. Rebuilding the spreadsheet chaos as custom software without the mapping step automates the mess and makes it permanent.
Continue your project research
What a custom website or app costs
The drivers that set the price band.
Software development services
Custom applications, integrations and dashboards.
Business & technology consulting
Help deciding what to build, what to buy, and in what order.
What to know before building a business
The full pillar guide this page was split from.
Prefer to talk this through?
Send a short brief — objective, equipment, timeline — and a senior engineer will respond with questions and an honest fit assessment.
Get a Quote