Build vs Buy redefined: How AI changes the economics

Lately I have been thinking there is a big change incoming on the economics of the IT industry, especially around COTS and SaaS solutions.

For three decades, the conventional wisdom in IT has been pretty straightforward: building custom software is expensive and risky. You need specialized developers, months of implementation, then years of maintaining systems nobody else understands. Buying packaged software seemed like the rational choice. Lower upfront costs, vendor support, faster deployment. Sure, the system wouldn't perfectly match your business. You'd end up customizing it heavily. But buying still felt safer than building.

That logic made sense. It doesn't anymore. And I'm not saying this from blind optimism about technology: I'm saying it because the actual economics have shifted.

The hidden price tag nobody talks about

Organizations choose buy to avoid the supposed expense of building. Then five years later, they've spent more on customization, integration, and fighting the system than a clean build would have cost from day one.

The problem with COTS systems is they look cheaper on the surface, but the hidden costs are enormous. Customization alone typically runs 20-40% of your license costs every single year. Then you're dealing with integration work: Connecting to your existing systems usually means custom APIs, middleware, data mapping layers, all that fun stuff. You change your business processes to fit the software instead of changing the software to fit your business. Your whole company bends around vendor assumptions.

Then comes the vendor's major release and your customizations break. You either spend months redoing the work or stay on an obsolete version and accept the technical debt. Neither option is great.

The vendor lock-in becomes financial lock-in. The system becomes harder to leave each year, so the vendor raises prices. You negotiate a bit, accept the increase, and keep going. Seven years in, you're paying double what you started with. Not because the software got better—because leaving is now impossible.

These aren't implementation mistakes. They're built into the business model.

Why building was expensive (and whats changed)

Traditional build projects were genuinely expensive. You needed experienced teams, months or years of implementation, code written manually from specifications. Then maintaining systems that only two people understood. A simple business rule change meant diving into code archaeology, understanding dependencies, testing everything, careful deployments.

The real cost wasn't business thinking. It was translating business thinking into code at scale. That translation was expensive.

This is where AI actually changes everything. And I mean actually, not in a marketing-speak way.

When you can generate 60-70% of your implementation code directly from business models, when a product manager can describe what the business needs and AI produces the technical infrastructure, the entire economics invert. A business architect describes the domain, the processes, the rules. The system generates the code. Requirements change? Update the model. The code updates automatically. Maintenance becomes model maintenance, not code archaeology.

This is what we built at MyStekz. And it works.

Platform thinking changes the game

This is where it gets interesting. The real shift isn't "should we build one system?" It's "should we build aplatformthat evolves?"

Traditional development is weird when you look at it. You build system A. Later you need system B. You start over: different developers, different approaches, different technology stack. Each system is a standalone project with no shared foundation. You end up with a portfolio of fragmented systems that barely talk to each other.

Platform thinking is fundamentally different. You build foundational layers once. Your domain models, your business processes, your business rules, your data structures. Every new capability leverages what came before. Your second system costs significantly less than your first. Your third even less. Over time you've built compounding value because everything connects to shared understanding of how your business actually works.

This is structurally different from customizing COTS. With COTS you're still trapped in the vendor's domain model. Every customization is you fighting against their assumptions. With a platform approach, your business logic is the foundation. Not a distortion of someone else's logic. Your logic.

The numbers make sense now

Let me be specific here because this matters. These ranges come from actual implementations I'm seeing.

A traditional COTS implementation costs roughly: Initial license plus 18-24 months of implementation and customization (maybe 120-180% of year-one license costs). Then annual maintenance and customization work (20-40% of license annually). Over five years you're at roughly 4-5x your initial license investment. And that's before integration costs with other systems start piling up.

A traditional custom build: Higher upfront cost (12-18 months of team development, probably 2-3x the COTS license cost). But then annual maintenance is much lower (maybe 10-15% of initial development cost). Over five years you're at roughly 2x the initial build cost. The problem is you need five years just to break even against COTS.

A platform build with AI: Moderate upfront cost (6-9 months of modeling and platform setup, comparable to or slightly more than a COTS license). But ongoing costs are significantly lower (5-10% annually, because AI regenerates implementation as models change). Over five years you're at roughly 1.5-2x your initial investment, with dramatically better business fit and zero vendor lock-in.

The real story unfolds in year six. COTS costs keep climbing or you stop paying and run obsolete software. Platform maintenance stays low. Traditional custom builds need periodic major rewrites. A platform approach keeps evolving smoothly.

When this actually makes sense

But this doesn't apply everywhere.

Don't build payroll. Don't build email. Don't build generic accounting. Your competitive advantage isn't there. Buy something proven, integrate it, move on.

This approach transforms things when you're buildingdifferentiatingbusiness capabilities. When how you serve customers, manage your supply chain, handle underwriting, or coordinate operations is what separates you from competitors. When COTS would force you to change how you compete to fit their system.

I've watched organizations choose between heavily customizing SAP or building custom systems. The ones who thought strategically—building for genuine differentiation, buying for commodity functions—ended up leaner, faster, lower cost. The ones who tried to customize their way to competitive advantage spent a decade and a fortune running a system that actually constrained them.

The question changes

Here's what's different now. For thirty years we asked: "How do we afford to build?" That constraint shaped everything. We built less. We bought more. We customized systems that didn't fit because building seemed "too expensive."

The real question now is: "What would we build if building were 10x cheaper?"

That reframing matters. It means asking what your business actually needs instead of picking from what's available in the market. It means stopping business processes you bent to fit software and rebuilding them the right way. It means competing on business capability instead of on how well you've customized a package.

In many cases now, building wins on pure economics. You get better business fit, lower long-term cost, no vendor lock-in, and you own your domain models. The business logic that runs your company stays under your control.

This is why we built MyStekz

When we started MyStekz, we were looking at exactly this problem. Organizations spending millions on COTS customization. Platforms becoming constraints instead of enablers. We asked: what if building from business models could be fast and cheap?

That became our focus. A platform that lets you describe your business domain once, then generates the technical implementation. Change your model, implementation updates. Need new capability? Leverage the domain model you already built. The platform understands how your business works, not some generic vendor assumption.

When AI can generate implementation from business models, building stops being prohibitively expensive. Each new capability costs less than the last. Your business logic lives in models, not code. Total cost over five years beats COTS with all its customization.

The part people dont like to admit

Organizations that made the buy decision ten years ago are now stuck. Expensive systems that don't quite work, can't be left because lock-in is complete. They pay premium prices and work around limitations constantly. Their actual IT spend—once you count all the customization, all the integration work—probably exceeds what a clean platform build would cost.

Organizations making the buy decision today are making the same bet. Some will be fine. Maybe they really are in commodity territory. Others will discover in five years that they've built expensive constraints around vendor assumptions.

The ones thinking strategically right now are asking different questions. They're ruthlessly identifying what's truly commodity and buying that. They're identifying what genuinely differentiates them and building it with platforms that evolve without complete rewrites.

They're competing on capability, not on system negotiations.

What would your organization build if building were actually 10x cheaper? What business processes have you changed to fit software instead of changing the software to fit your business? How much of your annual IT budget actually goes to making systems work that don't quite fit?

These aren't rhetorical. They're the questions that actually matter now.