Build, buy, or use what you already own
The argument is almost never about software. It is about a process nobody has written down, which is why both answers fail the same way and for the same reason.
In short
Buy anything that is not how you win. Configure what you already own before buying anything new. Build only where the process is genuinely yours and the available products would force you to give that up. The common mistake is not choosing wrongly, it is choosing before anybody has written down what the process actually is, at which point both options fail for exactly the same reason.
The six real options
Buy off the shelf
The default, and it should be. Somebody has already solved this and maintains it for a living. Configuration beats construction for anything that is not a genuine differentiator.
Configure what you already own
The most overlooked option by a wide margin. Most companies use a fraction of what their current systems do, and the spreadsheets beside them exist because nobody was ever assigned to set them up properly.
Build a thin layer
Keep the bought systems and add a small piece of glue that does the one thing they cannot. Small surface, small maintenance, and most of the benefit of a custom build.
Build the whole thing
Correct only where the process is a real advantage and every product on the market would force you to abandon it. This should feel rare, because it is.
Buy, then build later
Start on a product, learn what actually matters from running it, and build only the part that survives contact with reality. Requirements written before use are mostly guesses.
Neither, yet
If the process changes every month, no software will hold still long enough to help. Stabilise the process by hand first. This is the cheapest option and the least popular one.
Why both options fail for the same reason
Almost every build versus buy argument is really an argument about a process that nobody has described. One side argues that no product fits. The other argues that products obviously exist. Neither can be right yet, because the requirement is still a feeling rather than a specification.
A product not fitting is a specific claim, and it should be possible to name the three things it will not do and roughly what each of those costs per month. When a team cannot produce that list, the honest position is that evaluation has not happened yet, whatever the calendar says.
The most common finding on this question is uncomfortable and it repeats across industries. The system already owned does considerably more than anybody is using. The spreadsheets sitting next to it exist because nobody was ever given the job of configuring it properly, and a spreadsheet was faster that particular week.
That is not a software problem, it is an ownership problem, and buying something new does not fix it. The new tool arrives, gets configured to roughly the same depth as the last one, and a second set of spreadsheets grows beside it inside a year.
Where building is genuinely right, the correct build is usually far smaller than the one being proposed. The valuable piece is a thin layer that connects two bought systems and encodes the single rule that is actually yours. That is weeks of work with a small surface to maintain, rather than a platform with a roadmap.
The question that settles it is maintenance in year three. Every build is a permanent commitment to somebody continuing to understand it. Buying transfers that commitment to a company whose entire business is honouring it, and that transfer is the real product being purchased.
Build, buy, or switch on what you already have
Seven factors, read across. The second row decides most of these arguments, and it is the row that usually gets skipped because it is the least enjoyable to answer.
| Factor | Buy off the shelf | Configure what you own | Build |
|---|---|---|---|
| Is this how you win? | No. It is table stakes: payroll, accounting, email, standard CRM. | Mostly not, but the way you run it is somewhat yours. | Yes. The process is a real advantage you would have to give up. |
| How well is the process understood? | Well enough to evaluate vendors against it. | Well enough to name what is missing from what you have. | Written down completely. Anything less and you are paying to discover it. |
| Time to working | Days to weeks, plus migration. | Days. The licence is already paid for. | Months, and longer than the estimate, in every study and every anecdote. |
| Ongoing cost | A subscription, and it rises over time. | Nothing new, plus somebody's time to configure it. | Maintenance forever. It does not stop when the build does. |
| Who can change it later? | The vendor, on the vendor's roadmap. | You, within the limits of the product. | Only whoever built it, unless it was documented while it was built. |
| Main risk | You inherit the vendor's priorities and whatever terms they set later. | You hit a ceiling and have to make this decision again. | The person who built it leaves and takes the understanding with them. |
| Reversibility | High. Export the data and move. | Very high. Nothing structural changed. | Low. This is where the decision quietly becomes permanent. |
The middle column wins far more often than anybody expects. It is worth an honest afternoon before a purchase order or a build estimate, because it is the only option with no new commitment attached to it.
Five questions before anybody writes code
These take about a day between them. A day spent here regularly removes a purchase or shrinks a build by an order of magnitude.
- Have you written the process down?Not a diagram. The actual steps, who does each one, what triggers it, and what happens on the exceptions. If this does not exist, no vendor evaluation and no build estimate means anything, because there is nothing to evaluate against.
- What does the system you already own actually do?Read the feature list of the product you are paying for and compare it to what is switched on. This exercise takes an afternoon and it removes the need for a new purchase more often than anybody expects.
- Is this a differentiator or is it table stakes?If a competitor could buy the same capability tomorrow, it is table stakes and you should buy it too. Building table stakes is the most reliable way to spend a year on something that never shows up in the numbers.
- Who maintains this in year three?Name the person or the team. Every build is a permanent commitment to somebody continuing to understand it. If nobody can be named, the build has a hidden end date and it arrives with their resignation.
- What is the smallest thing that would work?Ask what could be shipped in two weeks that removes the worst part of the problem. The answer is usually far smaller than the proposal, and shipping it tells you more about the requirement than another month of specification.
Questions we get
How do we know whether a product genuinely does not fit?
Name the three things it will not do, and what each one costs you per month in time or lost work. If that list cannot be produced, the evaluation has not happened yet.
Half the time the list turns out to be one thing, and that one thing is a thin integration rather than a reason to build a platform.
Is a no code tool building or buying?
Both, and it inherits the risks of each. You are buying a platform and building on top of it, which means you carry the maintenance of your logic and the vendor carries the roadmap under it.
It is often the right answer for a first version. Treat it as a build for planning purposes: somebody still has to own it, document it, and notice when it breaks.
We were told a custom build works out better over time. Is that true?
Sometimes, and the comparison is usually done unfairly. A one off build gets compared against years of subscription, while maintenance, the cost of change, and the risk of the builder leaving are left out of the build column.
Put all four in the same table before deciding. The answer sometimes survives that, and when it does, it is worth acting on.
What is the smallest useful build?
A thin layer between two systems you already pay for, encoding one rule that is specific to how you work. Weeks rather than months, and small enough that one person can hold all of it.
If a proposal cannot be reduced to something like that, the process underneath it is probably not understood well enough yet.
How do we avoid getting locked into a vendor?
Ask how you get your data out before you sign, and test the export once during the trial rather than believing the documentation. Also ask what happens to your configuration on export, since that is what is usually unrecoverable.
Some lock in is a reasonable trade for not maintaining software yourself. Unknown lock in is not.
Our engineers want to build it. Is that a warning sign?
Not by itself. Engineers are usually right that the thing is buildable. The question is whether it should be built, which is a different question and not really theirs to answer alone.
Ask what else those weeks would go to. If the answer is work that customers would notice, that comparison is the decision.
What should we do before evaluating any vendor?
Write the process down and switch on what you already own. Do both before the first demo.
Vendor evaluation without a written process becomes a feature comparison, and feature comparisons are won by whoever has the longest list rather than by whoever solves your problem.
Does AI change this calculation?
It lowers the cost of building the thin layer, which makes the small custom piece more attractive than it was. It does not lower the cost of maintaining it, and maintenance is what actually decides these questions.
It also makes it much easier to produce something that looks finished and is not. Build small, put a person on the output, and keep the surface something one person can hold.
More in the guides and every answer in one place.