Eric Ries didn't write The Lean Startup because building software was expensive. He wrote it because building had just gotten cheap. The LAMP stack and early AWS meant a small team could build almost anything, fast. So teams built everything, and most of it went unused. His framing of the moment stuck: "The big question of our time is not, Can it be built? but, Should it be built?"
That question was about product risk. Are we building something anyone wants. AI-assisted coding asked it again, louder, and added a second half Ries didn't have to carry. Not only should we build it. Should we build it, or buy it. And who owns it after we do.
The new temptation
A developer with Claude Code or Copilot can now scaffold in days what used to take a team weeks. The code comes out navigable enough that someone new can maintain it without the original author in the room. So a new default has taken hold in a lot of organizations. We'll just build it.
And for the first time, that default is sometimes right for companies that could never have justified it before. The barrier dropped. The flexibility argument got stronger. There are good reasons to build today that didn't exist three years ago.
But most teams jump to how they'll build before they settle whether they should. Build or buy is the first question. How deeply to build is the next one, and a different one. This piece is about the first.
The temptation to build has outrun the discipline to ask what it costs. This isn't an argument against building. It's an argument for asking honestly, before the first commit.
The primary filter: strategic importance
Before any cost analysis, one question sets which way the decision should lean.
Is this core to how you compete, or is it commodity infrastructure?
Core to how you compete means the capability drives revenue, differentiates your product, or reflects a process so specific to your business that no off-the-shelf tool can serve it without becoming a liability. Your moat. Your method. The thing customers choose you for.
Commodity infrastructure means the problem is solved. Other companies have the same need. A mature market of vendors has spent years and hundreds of millions of dollars on it. Your version won't be better. It will just be yours to maintain.
The question doesn't settle the decision. It sets the default, and it puts the burden of proof on the right side. If it's commodity, you need a compelling reason to build. If it's strategic, you need a compelling reason not to.
Two icebergs, not one
Vonnegut wrote that before any of this. He was describing human nature. AI just made the flaw more expensive to indulge.
Both choices are icebergs. What you see, the build estimate or the license price, is the tip. The bulk sits below the waterline: everything you still owe after you've decided. Most frameworks show only one of the two, usually the build. The decision isn't whether to take on an iceberg. It's which one, and whether you can see the whole of it before you commit.
The build iceberg. The number in the proposal is usually engineering hours times rate. That's the tip. Below the waterline:
- Security patching and vulnerability management
- Access control: who can do what, when, and where
- Audit trails and compliance documentation
- Dependency management as adjacent systems change
- Onboarding new people to custom code
- Documentation that ages out and never gets updated
- The engineer who built it leaves
- Incident response when it breaks at 2am
- Feature requests from every team that adopted it
Build, and you don't avoid these costs. You just stop billing them to a line anyone can see.
The buy iceberg. The license price is also a tip. Below the waterline:
- Implementation and onboarding
- Consultant fees to customize (implementation guides commonly put Salesforce rollouts at two to three times the annual license)
- Process adaptation: your team learns to work around the tool instead of the tool serving your process
- Tier lock-in: the feature you actually need is always one tier up
- Vendor dependency: pricing changes, acquisitions, and deprecations are outside your control
- Switching costs that compound as more data and process gets embedded
The promise of enterprise software is configurability. The reality, for a lot of organizations, is a process that now serves the software instead of the other way around.
AI-assisted building shifts one part of this. You can build to your process instead of adapting to a product, faster and cheaper than before. That's a real advantage. It doesn't drain the build iceberg. It does change the math where process fit is the deciding variable.
The decision matrix
Map the two variables that decide most of this, strategic importance and ownership readiness, and four positions fall out.
The top row is where you can act now. The bottom row is a readiness gap to close first. What follows walks each call in turn.
When buying is the right call
Buy when the solution is mature, the customization need is low, and your process doesn't need to differentiate.
The strongest case for buying is that a vendor has made solving this their whole business. Their security team is bigger than yours. Their compliance certifications are already in place. Their support function exists so yours doesn't have to. Part of the subscription is paying someone else to own all of that.
The test is whether your engineers' time would return more somewhere else. For commodity infrastructure, project management, HR systems, basic CRM, document collaboration, the answer is almost always yes. The goal was never to build everything you can. It's to build what returns more than it costs to own.
One case complicates the buy decision. You already pay for a tool and wonder whether you could rebuild it for less. That math carries transition, migration, and integration costs the steady-state comparison misses. It deserves its own treatment, and it's coming in a later piece.
When bridging is the right call, for now
Not every build is permanent. Some are bridges: the light thing you build when you're not ready to commit to buying yet, whether because no one owns the decision or it's simply too early to justify the spend. Build the stopgap now, buy the real thing when you're ready.
A pre-revenue startup needs to track prospects and conversations. A CRM at $150 a month is a recurring cost against zero revenue, a locked tier structure, and a sales motion they haven't figured out yet. A Claude subscription at $20 a month lets them cobble together something light, and draft the pitch deck, research competitors, and write the first contracts besides.
The build here is temporary on purpose. The owner is the founder. The exit condition is named up front: when we hit product-market fit and hire a sales team, we move to a real CRM. That's not a bad build. That's a bridge, built deliberately, with the road already in mind.
The tell that separates a bridge from a mistake is whether you can name the moment you'd stop using it. If yes, it's a bridge. If the answer is "we'll figure that out later," it's a road with no maintenance plan.
This is also a build you keep deliberately shallow. A prompt or a light workflow, not a platform. Matching the depth of the build to the actual use is its own decision, and the next one to work through once you've decided to build.
When building is the right call, permanently
37signals runs the company on its own products. They build Basecamp inside Basecamp. When they needed email, they built HEY instead of buying it. "Drink your own champagne" isn't a slogan there, it's the operating model.
On the surface this looks like the mistake everyone makes. Project management and email are commodity needs. Mature tools exist. Why build?
Because for 37signals, using someone else's tools would undercut the thing they sell. Telling customers your software can run their business while you run yours on a competitor's product is a credibility problem, not an efficiency one. The build isn't a straight ROI call. It's strategic identity. Their own stack is a live proof of the product.
The question that makes this defensible is whether your customers would trust you less if they found you using a competitor's product instead of your own. Most companies can't answer yes. A few can. This exception holds when building is an expression of what your product is, not a preference for how you work. It needs a product whose flexibility is the point and a customer base that's watching. Narrow category. For everyone else, it's an inspiring story, not a playbook.
The success trap
An engineering team we worked with built an internal project management tool. The need was real, the infrastructure was there, and AI-assisted coding made it tractable for one person. So one person built it.
It worked. Teams adopted it. Other teams heard about it and adopted it too. Then the feature requests started, from multiple teams, regularly. The non-developer who built it, for whom this was never the actual job, is now running a backlog on the side of their real one.
The tool can't be productized: it's purpose-built for internal use, not sharp enough to compete in the market it replaced. It can't easily be dropped: too many teams depend on it, and migrating would take coordination nobody has scheduled. The exit door narrows with every team that onboards.
This is the success trap. The tool worked too well for its own good. The original mistake wasn't the build. It was the two answers nobody had before the first commit: who owns this if it scales, and what happens if it succeeds.
In grid terms, a prompt-sized need quietly became a platform nobody signed up to own. AI made the code passable, and passable code is not an ownership plan. Vonnegut's flaw didn't disappear when building got easy. It moved downstream, to whoever inherits the maintenance.
Five questions before the commit
The matrix tells you which way to lean. These five tell you whether you're ready to act.
- Is this core to how we compete? Yes, leans build. No, leans buy. Either way, the rest still apply.
- Does an equivalent solution exist, and what would it truly cost to make it fit? Not just the license. Implementation, customization, process adaptation, consultant hours. If that rivals a build, the flexibility argument for building gets real.
- How repeatable is this, and does the level of build match the level of use? A one-time need and a process that runs weekly call for different depths. Over-engineer a prompt into a platform and you burn engineering time. Under-invest in something that runs the business and you cap the return. This is the question the AI Utilization Grid exists to answer.
- Is this reversible, and is there a named exit condition? Bridges are fine. The mistake is a bridge that becomes permanent before anyone decided it should.
- What happens if it succeeds, and who owns it at 2x, 5x adoption? Not who builds it. Who owns it when three more teams want in and the requests arrive weekly. The same question applies to a vendor: someone owns renewals, customization, integration breaks, and the call when pricing jumps or the vendor gets acquired. "We'll figure that out" is not an owner, on either side.
Where this goes next
Ries asked whether it should be built. That's still the first question, and AI made it easier to answer wrong, because building is no longer the thing standing in your way.
Once the answer is build, the harder question is how to leverage AI without overbuilding. A prompt, a time-boxed experiment, a configured workflow, and a custom platform are not interchangeable. Each carries a different cost, owner, and maintenance load. Often the efficient move isn't to build yet. It's to experiment first, on real data, and prove the need before you commit engineering to it. Sorting build from experiment is what the AI Utilization Grid is for, and it's where this decision hands off.