Make or Buy, which path ?
The make or buy question is old. Do you build the tool yourself, or do you buy something that already exists? For most of my career, “buy” won almost every time. Building software in-house meant months of engineer time just to reach what an off-the-shelf product already did on day one. AI coding assistants just changed that math, and not by a small margin.
How it was before
Buying was never really about the price tag on the invoice. The real cost was the process around it: writing an RFP, shortlisting vendors, running a proof of concept, checking how it fits your existing landscape, security review, negotiating the contract. Weeks, sometimes months, before a single user touches the thing.
Building it yourself meant weeks or months too, just spent differently: specs, architecture, writing the code, testing it, fixing it. Either way, the timeline was long. So “buy” usually won, because someone else had already paid that cost and you were just renting the result.
What changed
With Claude Code, the “make” side of that equation collapsed. Describing what you need, getting a working first version, and iterating on it now takes days, sometimes hours, not months. Testing is faster too, since the AI writes a lot of the test coverage alongside the code.
The “buy” side did not get any faster. You still need the RFP, the calls, demos, building a PoC, the the negiciation, the integration work, the contract review. All of that overhead is now bigger than just building the thing yourself. The balance flipped: writing your own tool can be quicker than the process of evaluating someone else’s.
Customization
Off-the-shelf tools are built for the average customer, not for you. If you have a specific use case or need a specific feature, the “buy” route means opening a feature request, explaining your case to the supplier, and waiting. Best case it lands on their roadmap for a release months out. Worst case it never happens, because your use case is not common enough for them to bother with. Either way, once it finally ships, you still have to fit it into your system landscape, on their schedule, not yours.
Building it yourself skips all of that. You know exactly what you need, you build exactly that, and you control your own integration and your own timeline. No discussions to convince a supplier your feature request matters, no waiting months for a roadmap slot, no settling for a compromise because it did not fit someone else’s product plan.
Vendors are getting greedy
On top of that, software and SaaS pricing has gotten out of hand. Per-seat pricing keeps climbing, basic features get pulled behind a pricier tier, usage-based pricing punishes you for growing. A lot of vendors are optimizing for extracting more, not for being worth more. That pushes the decision toward “make” even further: why pay a growing bill for a fraction of what you actually need, when building the exact fraction you need is now fast and cheap?
How the “make” approach could work
AI-assisted development is not a free pass. It changes the cost of building, not the need for judgement. A few things are non-negotiable if you want “make” to actually succeed:
People who understand the tech stack, not just the prompt. Someone on the team has to actually read the generated code, understand what it does, and catch it when it’s wrong. AI writes confident code even when the code is bad. Without someone able to tell the difference, you are not building software, you are gambling with it.
Stick to a stack you know personally. Let the AI move fast on technology your team already understands well, not on something brand new to everyone involved. Familiar tech means you can spot when the AI goes off track, debug it when it breaks, and know its limits. Using AI to learn an unfamiliar stack from scratch, on something that matters, is a different and much riskier bet.
Accept the risk, and plan for when it goes wrong. Faster and self-developped does not mean risk free. Keep a fallback: a rollback plan, a time-boxed checkpoint to decide if it’s working. A “we buy the tool instead” option still on the table if the in-house build stalls. Taking the risk is fine, but refusing to build a plan B: manual fallback, do it like before or buying a tool is not ok.
Conclusion
The make or buy calculus has quietly flipped for a lot of software decisions. Building your own is often faster than shopping for and rolling out someone else’s product, and vendor pricing is only making that gap wider. But that only holds if you have people who genuinely understand what’s being built, a tech stack the team already trusts, and a real plan for the moments it does not go as expected. AI made “make” cheap. It did not make it safe by default, that part is still on you.