For ten years, buy versus build was barely a real question

I consulted on Salesforce implementations for about a decade, for somewhere north of a hundred companies. In all of that, I can't think of one company that was ever considering building its own business system.

All the traffic ran the other way. Private equity, for example, commonly created value by moving companies off their legacy homegrown systems, all of which were described the same way. A dinosaur. A Frankenstein. A hot dumpster fire. Whatever your pejorative of choice is, it was always the case that somebody built it fifteen or twenty years ago, that person is long gone, and now it is a liability impeding the company. It was always time to modernize, which you'd do by renting software another company had already built.

The short version, if you want it before the reasoning. Is this a solved problem, and has somebody solved it well enough to solve yours? If the answer is yes, buy it and stop reading. If it is no, the framework below is the harder, more honest version of that question, and it is worth sitting with before you start.

You only built it if the software was the business

There was one kind of company that did build. SaaS companies. The software was the thing they sold.

I worked with a company in H-1B visa review, matching candidates to employers. They spent over a million dollars to stand up their own portal, and it made complete sense, because that portal was the business itself. Every dollar they made ran through it. That is a software company building software.

The reason this was the case is cost. If you wanted your own system, you were hiring. Ten people, a recruiting cycle to find them, a permanent payroll line once you did, and implementation on top of all of it. That is a decision you make when the software is the reason the company exists and makes revenue. Nobody takes on a fully-baked engineering team just to get better internal tools. The return on investment was poor, especially given that off-the-shelf options exist.

Which is exactly why everyone bought that software off the shelf and hoped it fit well enough to use as-is, or customized until it was livable. And this strategy was almost never questioned. Buying vs. Building here was never really a decision to make.

The real debate happened downstream.

Where this question did come up would happen within existing platforms.

You are on Salesforce, you need quoting, and now you have a decision. License CPQ and embed it in your org, or build your own version on the platform you are already paying for. Real fork, real case on both sides, and I watched companies go both ways. One company chose to build their own, but then got acquired and were migrated into the buy strategy.

Integrations were the other one. Hand-roll a custom connection between two systems, which needs a genuinely technical developer and then keeps needing one, or stand up Boomi or Workato and buy your way past it. For instance, if you want to integrate HubSpot and Salesforce you can use the native connector. It's free, and you can be live by lunch (exaggerating here, obviously, but you take the point and I like alliteration). But the field mappings do what they do, the object-to-object transformations only go so far, and if your data model has any real complexity you will hit that ceiling. Then you are right back at the same decision, except later, with more data in play. So maybe you should have just built your own? But... by renting a middleware tool like Mulesoft?

Regardless, that was the real shape of it. A module, a connector, a component. Almost never the full system itself.

Some companies were never going to fit

Underneath all of it, there was always a set of scenarios where none of this worked that great. They customized, and customized again, and still ended up bending their process around the software rather than the other way around. Bending over backwards to make it fit.

That was never really the vendor’s fault. It is market math, because - again - the only economically-viable software was multi-tenant, despite the cliche that every client thinks they're unique.

I've been thinking of all these parallels between this technology shift and the gradual shift that happened in the TV media landscape. Everybody in the country used to watch MASH, because there were four channels. But things changed in media production; people can now capture high-res videos on their iPhone. All of which allows cable to show up, then streaming, and the audience fractured into a thousand pieces. What came out of that was a whole category of relatively niche, "cult hit" shows that could never have existed before, because they only needed three hundred thousand viewers instead of forty million. Smaller budgets, narrower audience, but now a viable thing.

Software has been sitting in its four-channel era this entire time, for exactly the same reason. To justify building a product, you need a market big enough to support a company. If the specific shape of your problem is shared by forty other businesses, that is not a market, and nobody is ever going to build it. So you were stuck between a rock and a hard place, retrofitting something designed for a different kind of company and calling it close enough.

That gap has been there the whole time. There just was not anything to do about it.

What changed

AI made writing code cheap. That is most of it, affecting not only your direct ability to build but also the entire supply chain you build on.

You can stand up software specific to your business, your workflow, and your interface without a hiring cycle sitting in front of it. Forty businesses is still not a market. It just does not have to be one anymore, because you are not trying to build a company. You are trying to build one application, for you.

Plenty of things downstream have to move with that. If building your own is materially cheaper than it used to be, the value of leasing somebody else’s gets thinner, and the pricing has to answer for it eventually. Everybody is quietly wondering whether they could vibe code their own Salesforce. Some of them will try. Some competitors will try it specifically to undercut the mothership.

And yet that is not the question I would be asking.

Is this a solved problem?

That is the one I keep coming back to. Is this a solved problem, and has somebody solved it well enough that it would solve mine too?

Accounting, to me, feels like an obvious example. Every business needs it, there are thousands of tools, and people have been grinding on that problem for forty years. Is there some square peg and round hole in how it fits you? Sure, probably. Does that justify building your own general ledger, while worrying about handling the security you've put in place when handling sensitive data? No. Lease what somebody already figured out and go do your actual job. That logic holds for plenty of categories and it did not stop holding just because code got cheap.

The answer changes when your problem is the narrow kind. When its shape comes from your org chart, your business model, your pricing, the particular way you win work. Those problems were never going to get a product built for them. Now they can have one anyway. Now there are times when they definitely should! But also, there are times when they still should not.

Also, how much of the problem are you actually buying a solution for? A product might work almost immediately, or it might give you a very expensive starting point that still needs months of customization. And if most of your existing system works, you might only need to build the piece it is missing. Be specific about what you are deciding to replace.

Writing code is cheap. Building software is still hard.

Say you find yourself in that spot. These are the things I would sit with before anybody starts building.

Taste. AI will write you code. It should not make all your decisions. AI being able to make any software for you does not at all mean it's going to make the right software. A blank canvas is full of possibility, and also the risk of heading in the wrong direction, especially when there's no "right" answer to begin with. What color should this thing be, red or blue? Claude will make a choice for you, but it often is not the one you want. What does good look like to you? Nobody has automated that.

Security. Would you bet the company on an app your financial controller vibe coded over a weekend, running for a hundred people, holding your customer records? I certainly would not. The same tools that let you move fast let attackers move fast, and that half of the trade does not come up nearly enough.

Maintenance. Shipping is not the finish line. The infrastructure underneath your app keeps changing whether you are paying attention or not. Who fixes it when it breaks at seven in the morning? Who keeps it current as the technology improves? With SaaS, you share the cost of that work with the vendor’s other customers, and the vendor decides what gets built next. With your own system, you get to set those priorities. You also need a plan to keep paying for them.

Ownership. This is the one that decides it. The people who know your business best have day jobs, and those day jobs are not product management, solution architecture, or security review. Being handy with technology and being trained to build software that a hundred people depend on are two different things. If the person who built it moves on and nobody picks it up, you have just manufactured the next dinosaur, and somebody will be calling it a Frankenstein in fifteen years.

Legacy SaaS bakes every bit of this into the price. That is a real part of what you are buying, and it is worth something.

Every platform that ever promised anyone could build it grew an ecosystem of specialists around it anyway. The tools moved where the expertise had to sit. They never removed the need for it.

---

The two obvious answers are a weekend project and a permanent engineering department. One of those you can afford and cannot sustain. The other you can sustain and probably cannot justify.

So before you decide anything, answer the last question honestly. Can you name the person who will still own this in three years, who has the time, the expertise, and the professionalism to keep it good?

If you cannot, that is your answer, whatever the software costs.