9 December 20257 min read
Build versus buy is one of the oldest arguments in software, and it is usually held with a column missing. Build means your own engineers write it. Buy means a vendor's product does it. Outsource is neither: it is custom software you own, built by people who are not your employees, and it has a different risk profile from both.
Leaving it out distorts the argument in a predictable direction. Teams who cannot spare internal capacity conclude they must buy, then spend two years bending their process around a product that nearly fits. Teams determined to have exactly what they want conclude they must build, then wait six months for a hire. The third column often dominates both, and it is rarely on the slide.
The three options answer different questions
Buying answers: is this problem the same for us as for everyone else? Building answers: is our version of this problem the reason customers choose us? Outsourcing answers: is this work specific to us but not the thing that makes us different?
That third category is enormous and it is where most disappointment with off-the-shelf products comes from. An internal tool that matches your operational model. An integration between two systems only you happen to run together. A migration off something you were sold in a hurry. A portal for a customer segment with an unusual requirement. None of it is differentiating. All of it is specific.
Buy first, and mean it
The default should be buy, and the bar for leaving that default should be high. A mature product has absorbed years of edge cases you have not thought of, its maintenance is somebody else's payroll problem, and it works on the day you pay for it rather than the day someone finishes it.
The honest objections to buying are few. The product genuinely does not do the thing, and no configuration gets it there. The commercial terms scale badly against your growth. The data has to live somewhere the vendor will not put it, which for European buyers with a strict data processing position is a real and not a theoretical constraint. Or the capability is the product, in which case you were never buying.
The dishonest objection is that it does not work the way we work. Sometimes that is true and expensive. Often it means the product embodies a more standard process than yours and adopting it would be an improvement you do not want to have. That is worth naming before you spend a year of engineering avoiding it.
Build in-house versus outsource the build
Once you have decided something must be custom, the remaining question is who writes it, and it turns on two things: whether the knowledge needs to compound internally, and whether the work will continue after the first version ships.
- Compounds, and never stops: build in-house. This is the core, and an employee accumulating context for years is the asset.
- Specific, and mostly ships once: outsource. Internal tooling, integrations, migrations, portals. The knowledge that matters is documentation, not intuition.
- Specific, continuous, but not differentiating: outsource with continuity in mind. Staff augmentation with the same named people works better here than a series of projects.
- Uncertain which it is: outsource a first version deliberately, decide with something real in front of you, and keep the option to bring it in-house.
The last row is the one that gets missed. Outsourcing is a cheap way to find out whether a capability deserves permanent headcount. Hiring to answer that question costs a recruitment cycle and a person's career, and answering it wrong is expensive for everybody.
The costs have different shapes, not just different sizes
Comparing the three on price alone hides the thing that matters, which is when the money is spent and what happens if you stop.
Buying is a recurring cost that starts small and grows with your usage, and it stops when you stop paying, along with the capability. Building in-house is a large fixed commitment: recruitment, salary, employer contributions, the months the role is open, and a person you cannot ramp down in a quarter. Outsourcing sits between them: it starts when you start, it ends on notice, and the asset stays yours.
Run all three over the same horizon, at least two years, and put the things people leave out on the table. On the buy side: implementation, integration work, the price increase at renewal, and the cost of leaving. On the build side: recruitment, the empty months, and management. On the outsource side: the onboarding ramp before anyone is productive, and the internal time spent directing them. The ranking often changes once those are in, which is the point of doing it.
The answer you probably end up with
In practice most teams do all three, and the useful skill is drawing the boundaries rather than picking a winner. Buy the commodity: identity, payments, email, analytics, the finance stack. Build the part that is the reason anyone chooses you. Outsource the specific-but-not-special layer that joins the two, which is where the volume of work actually is.
Boundaries drawn that way also survive growth. When the outsourced layer around some capability grows large enough that it stops feeling peripheral, that is a signal to bring it in-house, and you will have both the working system and the documentation to hire against. That is a much better position than deciding in the abstract.
A decision order that works
Ask the questions in this sequence and most cases resolve in an afternoon. Can we buy it, honestly, including changing our process to fit? If no: is this the thing that makes us different? If yes, hire and wait. If no: will this work continue indefinitely and compound? If yes, plan for it to come in-house eventually and outsource it now with that in mind. If no, outsource it, keep the code and the accounts, and move on to something that matters more.
The failure mode this order prevents is the common one: an expensive internal build of something the team could have bought, funded by not doing the work that was actually differentiating, because the third column was never on the slide.