AI Broke the Buy vs. Build Decision
AI made software cheaper to build. It didn’t make it cheaper to own.
There’s a conversation I’ve had some version of for basically my entire career. Somebody looks at an invoice and goes, “Why are we paying a hundred grand a year for this? We could build it ourselves in a month.”
For most of that time, my default move was just to push back on the timeline. How many engineers is it gonna take? How many sprints are we burning? What happens the second the requirements shift? You could usually kill the bad idea right there on the arithmetic.
That defense doesn’t work anymore. If an engineer walks into my office today and tells me they can whip up a functional replacement in three weeks, they’re probably dead right. They actually can.
Which is wild. And that’s what makes it dangerous.
Are you actually replacing it?
Take analytics, because that’s the classic trap. The data is already sitting in your warehouse anyway. You track a handful of click events, write a few SQL queries, put some charts on top, and somebody asks why you’re paying Mixpanel six figures for a dashboard.
And look, they aren’t wrong. They can build an analytics tool. But the real question you have to ask before anyone writes a line of code is whether you’re replacing Mixpanel or just cloning the five dashboard widgets you happened to look at this week.
Because what happens next is always the same story. The team knocks out today’s dashboards and today’s basic events. It looks great. Then six months down the road, product wants custom cohort retention. Then somebody needs granular permissions. Then identity resolution breaks because users are logging in across three devices. Then marketing wants multi-touch attribution journeys that nobody even contemplated when that initial schema was drafted.
Every single one of those asks is completely reasonable. Nobody’s being difficult. It’s just normal business growth. But now you’re trapped. You either tell the business no, which means your shiny internal replacement doesn’t actually replace anything, or you pull your best engineers off revenue work to keep building. It’s scope creep on steroids.
When you write a check to a mature SaaS vendor, you’re buying the company behind it. You’re paying for dedicated teams whose only job is keeping that infrastructure alive, and you’re buying the collective scars of thousands of other companies who’ve already tripped over edge cases you haven’t run into yet. People love to look at a platform and say, “We only use twenty percent of this.” Sure. But you usually only understand twenty percent of what you’re gonna need down the road.
The build isn’t the expensive part
On paper, the arithmetic looks seductive. Say you’re paying 100,000 a year fora piece of software. An in−house engineer runs 100,000 a year for a piece of. software. An in−house engineer runs 200,000 a year. You borrow a fraction of their time for a few sprints, delete a six-figure recurring line item, and suddenly you’re a hero. On an executive slide, it’s a banger.
The question nobody asks is what happens after that month is up. Who actually owns the tool? Who gets paged when it falls over? Who decides what gets built next quarter, who patches the security vulnerabilities, and who updates the dependencies when libraries break? What happens when the developer who built it leaves for another job? And the biggest question of all: what higher-leverage project was that developer supposed to be working on instead?
AI can crush three months of development down to three weeks. But you still spent three weeks of top-tier engineering attention, and you just signed up for three years of maintenance.
Then you have to ask why that vendor was charging a hundred grand to begin with. The idea that it’s pure vendor markup you can just delete is mostly nonsense. A lot of the time, the underlying problem is just plain expensive to run. You’re talking about massive data pipelines, third-party API bills, model inference calls, dedicated search indexes, and cloud infrastructure running around the clock whether anyone logs in or not. Rebuild it yourself and you inherit every single one of those infrastructure costs, except now you’re paying retail rates without any of the vendor’s volume discounts. You just decided to become a boutique software vendor inside your own company. Almost nobody runs that ledger.
The orphan product
I can’t tell you how many times I’ve watched the orphan product scenario play out. An ambitious engineer spots an annoying gap in the workflow, maybe a clunky reporting process or some deployment friction nobody wanted to touch, and goes off into a corner to hack together a fix. A couple of weeks go by, and they demo it to the team like magic: “Hey everyone, look what I built over the weekend. Problem solved.”
That’s the exact moment the trouble begins.
Nobody gave that tool an operational budget, nobody assigned it an official roadmap, and nobody named an owner. The engineer who slapped it together has their actual day job to do, and eventually their real priorities take over. A quarter later, an API changes or the business shifts, the script breaks, and nobody has the bandwidth to touch it. Now you’ve got this internal tool that’s half-dead, completely unmaintained, and quietly load-bearing for two critical departments.
AI accelerates this because the upfront friction dropped to basically zero. A working prototype appears in an afternoon. Ten people start using it on Monday. By Friday, fifty people rely on it. By next month, an essential customer onboarding pipeline depends on an afternoon hack. What AI really did was compress the distance between having an idea and accumulating massive technical debt down to about twelve hours.
Mind you, buying off-the-shelf software doesn’t give you an automatic pass either. You can easily walk into the exact same trap from the other side. You buy best-in-class email marketing, best-in-class product analytics, and best-in-class CRM, and then you pay someone to wire them all together. Congratulations: you just bought six commercial products and accidentally built a seventh. That glue code has no vendor account manager, no SLA, and zero customer support. When a webhook drops at two in the morning, you’re screwed.
Sometimes you should build
Now, having said all that, there are times when building in-house is the only sane answer.
Years ago, I was consulting for Rohm and Haas, back before Dow acquired them, helping them figure out their workflow automation. We scoured the market looking for software to buy, and there was nothing out there. The underlying manufacturing and business process was completely idiosyncratic to them. Nobody outside those four walls had ever run into that exact operating model, which meant nobody in the commercial market had ever built for it.
That’s the cleanest justification for building software you’ll ever find. Commercial SaaS works because you’re buying the accumulated wisdom of a thousand other companies who wrestled with the same workflow. In this case, that collective wisdom didn’t exist.
The catch was, their process was gonna keep morphing, and I had zero interest in fielding an emergency call every time someone tweaked an approval chain. So instead of hard-coding their specific workflow into rigid business logic, I abstracted the entire engine into a configurable state machine and built a clean visual editor on top. If the team needed to add an approval step or re-route a shipment, they could change the flow themselves in five minutes. No support tickets, no pull requests, no developer releases.
That system ended up becoming a company-wide standard. Teams across divisions adopted it for internal processes I never even saw, simply because the architecture refused to make hard assumptions about how they operated.
If you’re gonna build proprietary software, that’s the discipline it takes. You have to understand the contours of your business well enough to know which parts are going to shift beneath your feet. An engineer declaring “we can build this” is just a statement of technical capability, and technical capability was never the bottleneck.
Where AI actually changed the answer
So where does AI actually shift the math?
In my experience, the real leverage is disposable experimentation.
If you aren’t entirely sure what your team actually needs, don’t sit in committee meetings debating features. Spin up an AI model, spend an afternoon hacking together a throwaway prototype, and put it in front of five real users. Watch where they click. Figure out that the “mission-critical” feature everyone spent three weeks arguing about is something nobody ever touches. And then, here is the crucial step, throw the code away.
That disposal step is where almost everyone chokes. Teams still treat code like commercial real estate: if you pour the concrete and run the wiring, you have to preserve the building forever. With modern generative tools, software behaves a lot more like temporary scaffolding. You put it up to explore a space or validate an assumption, and once you have your answer, you take it down.
Building something to learn is fundamentally different from building something to own for five years. AI made the learning phase dirt cheap. The maintenance phase is just as stubborn and unforgiving as it ever was.
So these days, when someone pitches me on replacing a hundred-thousand-dollar contract with a month of internal dev work, I don’t waste ten seconds debating their velocity estimate. I believe them.
I just ask who owns it when they’re done.
Because generating code got cheap. Operating software never will.
Know where this has to go, and not how?
Twenty minutes. Tell me where you want this company to be in two years and I’ll tell you what I’d go look at first.