.png)
Build or Buy? A Decision Framework for Software and AI
Half the consulting calls we take end up at the same fork: should we build this ourselves, or buy something off the shelf?
The textbook answer is tidy. Buy for commodity, build for competitive advantage. It is not wrong. It is just useless on a Tuesday afternoon, when a vendor demo looked great and someone on the team swears they could build the same thing in a month.
So here is the framework we actually use with clients, with the trade-offs left visible.
Start with an honest question: how unique is this process, really?
Your invoices are not special. Your payroll is not special. Your CRM pipeline is probably not special either, even if the fields have unusual names. For all of that: buy, and spend your energy elsewhere.
But somewhere in your company there is a process that is the business. The way you price risk, route orders, or assess a dossier. The thing customers actually pay for. Renting that from the same vendor as your competitor is how companies become interchangeable.
That is the classic two-way split. What most comparisons miss is the third option, and it is where the majority of our projects actually land.
Assemble. Buy the boring blocks: standard databases, hosted models, proven components. Build only the wiring that makes them behave like your process. You own the logic without owning a platform.
Most of the interesting work happens in the right half of this picture.
AI has moved the math on all of this, in both directions at once.
Building got dramatically cheaper. A workflow tool that would have cost six figures three years ago is now a few weeks of senior work. The threshold where building beats buying has dropped, a lot.
Maintenance did not get cheaper. AI writes the first version quickly, and then somebody has to own it: patch it, adapt it, answer for it when it breaks during month-end. We have started meeting a new kind of legacy system on client projects: AI-generated software that nobody in the company understands.
So the real question was never build versus buy. It is: which decisions do you want to own, and who maintains the result?
Before any build decision, we ask four questions.
Does this process make us different, or just make us run? Different leans build. Run leans buy.
How often will it change? A stable process tolerates a vendor's roadmap. A fast-moving one will fight it every month.
Where does the data live, and who else can see it? For our clients in finance and Treuhand, this question often decides the whole thing on its own.
Who maintains it in year three? If the answer is a shrug, buy. An honest shrug now is cheaper than an abandoned codebase later.
Then there is the money, which behaves differently than most comparisons suggest.
Build costs are ugly and honest: they arrive up front, in an invoice you can see and argue about. Buy costs are polite and endless: per seat, per month, growing with your team and repriced whenever the vendor feels confident.
Illustrative, but it matches what we see when we model this for clients.
For a stable team over ten years, the subscription usually wins the first years and loses the decade. Not always. But often enough that we model it before deciding, every time.
The lock-in question deserves one honest paragraph too. Vendor lock-in is real, but so is contractor lock-in on a custom build. The difference: you can change the contractor and keep the code. Try firing your ERP.
Where does that leave a decision maker with a real budget and a real deadline?
Buy where you are like everyone else. Build where you are not. Assemble everywhere in between, and staff the maintenance before you write the first line.
And whichever way you go, keep the decision reversible. The companies that get this wrong are rarely wrong once. They are wrong, then stuck.
Frequently asked questions
When should a company build custom software instead of buying?
When the process is genuinely differentiating, changes faster than a vendor roadmap, or handles data you cannot hand to a third party. If the process just keeps the lights on, buy it. Most companies overestimate how unique their operations are and underestimate how unique their core process is.
Has AI made building custom software cheaper?
The building part, yes, often by a large factor: weeks of senior work where it used to be months. The owning part, no. Maintenance, integration and accountability cost what they always did. Budget the build as the down payment, not the price.
What is the third option between building and buying?
Assembling: standard blocks, custom wiring. Buy proven components such as databases, hosted AI models and off-the-shelf tools, and build only the logic that makes them behave like your process. You own the decisions without owning a platform, and you can swap blocks without starting over.
How do we compare the real costs of build versus buy?
Model both over five to ten years, not one. For buy: seats times growth times price increases. For build: the build price roughly again in care and evolution over the following years. Then compare. The subscription usually wins early years and loses the decade for a stable team.
How do we avoid vendor lock-in?
Own your data and the interfaces. Insist on export paths before signing, keep integration logic on your side of the fence, and prefer vendors whose format you could leave with. Lock-in is rarely the product. It is the years of process quietly shaped around it, so shape the process around your data instead.
