The Return of Custom Software

For most of the last two decades, the smart answer to “should we build this ourselves or buy it off the shelf?” was: buy it. Building custom software was slow, expensive, and risky. A serious internal tool meant a team of engineers, six months to a year of runway, and a number with a lot of zeros. Against that, paying a monthly fee for a polished product someone else maintained was an easy call. So we all bought. We bought a subscription for every problem, and we bent our companies to fit the software.

I think that era is ending, and most people haven’t clocked it yet.

The economics just changed underneath us

The reason build-vs-buy always tilted toward buy was cost and time. Both of those just collapsed.

The kind of custom internal tool that not long ago might have taken something like six months and a seven-figure budget can now, in the right hands, be built in a fraction of the time for a fraction of the cost: think weeks instead of half a year, and a five-figure number instead of a six- or seven-figure one. I’m being deliberately loose with the figures because they vary wildly by project, but the shape of the change is the point: an order of magnitude cheaper and several times faster. When the cost of building drops by that much, every build-vs-buy decision you made under the old math is worth revisiting.

And a lot of those decisions should flip. Because the thing we all quietly tolerated about off-the-shelf software was that it never quite fit.

Generic software solves everyone’s problem and no one’s

Here’s the dirty secret of most SaaS: to sell to thousands of companies, a product has to be general. It has to do a little of what everyone needs, which means it’s bloated with features you’ll never touch and missing the three that would actually matter to you. It’s built for the average of its market, and no real company is the average.

So you adapt. You change your process to match the tool’s assumptions. You keep a spreadsheet on the side to handle the part the tool doesn’t. You pay for eleven modules to use two. Multiply that across the dozen subscriptions running your business and you’re spending real money to be mildly, chronically ill-fit: a company shaped by its software instead of software shaped to the company.

The pitch for a product that “does so many things for so many people” is exactly the reason it solves no single person’s problem particularly well. Generality is the feature they sell and the bug you live with.

“Generality is the feature they sell and the bug you live with.”

Software as encoded IP

The most interesting reason to build, though, isn’t cost or fit. It’s ownership of your own way of working.

Every company that’s been around a while has a way it does things (the accumulated judgment, the shortcuts, the hard-won rules about what works), and most of it lives in people’s heads and a few battered spreadsheets. It’s some of the most valuable stuff you own, and it’s almost completely uncaptured. When a key person leaves, a chunk of it walks out the door with them.

Custom software is a way to encode that. When you build a tool around how your business actually operates, you’re not just automating tasks; you’re capturing your specific expertise into something durable, something that compounds, something a competitor buying the same generic SaaS as everyone else simply doesn’t have. Off-the-shelf software makes you more like your competitors, because you’re all pouring yourselves into the same mold. Custom software lets you turn the way you work into an advantage instead of a liability waiting to resign.

Do the boring part first

I need to put a firm caveat on all this, because “AI makes custom software cheap” is exactly the kind of line that gets people into trouble.

Cheap to build is not the same as easy to get right. The failure mode I see coming is companies cheerfully automating a process they never actually understood, pouring their vague, undocumented, three-versions-in-different-people’s-heads workflow into a custom tool and getting a fast, expensive monument to their own confusion.

So before you build anything, define the thing. What’s the real sequence of steps? What does success look like, in a number? And (this is the one people skip) what’s the business model or logic underneath it? I’ve watched projects go sideways because we architected toward the output someone wanted to see instead of the underlying model that output was supposed to serve. You have to understand how the value actually flows before you encode it, or you’ll build something structurally wrong very efficiently. Standardize first. Automate second. In that order, every time.

So should you build or buy?

None of this means build everything. That’s the opposite mistake, and it’s just as expensive. The point isn’t that custom is always right now; it’s that the default flipped from “buy unless you have to build” to an actual case-by-case decision. So here’s roughly how I help clients make the call.

Keep buying the commodities. Email, accounting, payments, calendars: the boring universal infrastructure where the off-the-shelf products are excellent, cheap, and where you gain nothing by being different. You do not want to build your own payroll system. Being special at payroll is not a business; it’s a liability. Anywhere the generic tool fits well and the function isn’t where you win, buy it, and don’t give it another thought.

Build where it’s core to how you actually differentiate: the part of your operation that is your edge, where the generic tools force you into painful workarounds, or where the process encodes real institutional knowledge worth capturing. If you find yourself maintaining an elaborate shadow system of spreadsheets and manual steps to make an off-the-shelf product handle your real workflow, that’s the tool telling you it doesn’t fit, and that friction is now cheap enough to design away.

And the most common right answer is the hybrid: buy the commodity layer underneath and build a thin custom layer on top (the part that’s genuinely yours) that sits on the bought infrastructure. You get the reliability and low cost of the standard product for the plumbing, and the perfect fit of custom exactly where fit matters. What you’re avoiding, in all of this, is building for the romance of building. Cheap to build is not a reason to build. A real fit problem, a real differentiator, or real IP worth encoding. Those are the reasons. Cheapness just means that when you do have one of those reasons, you can finally afford to act on it.

Where this is going

Play it forward and it gets genuinely strange. If building software keeps getting cheaper and faster, you eventually stop thinking of software as a product you buy at all. You start thinking of it as something you spin up on demand: you describe the problem, and a tool gets assembled around it, used, and maybe discarded when the problem changes. No app to license. No mold to bend yourself into. Just: here’s what I need to do, now here’s a thing that does it.

That’s a science-fiction version of the near future and I won’t pretend I know the timeline. But the direction is already visible in the small. The question a business owner should be asking has quietly changed. For twenty years it was “which product do we buy for this?” Increasingly the better question is “should this just be ours?” More and more often, the honest answer is yes, and now, for the first time in a long time, you can actually afford it.