For a long time, software decisions have been framed as a fairly binary choice: do we build something ourselves, or do we buy it from a vendor? That framing still exists, but needs to be expanded. With the rise of AI coding tools, workflow orchestration, and the possibility of systems that can generate logic at runtime, the choices has become far broader – and far more interesting.
What is it?
The traditional build vs. buy decision assumed two main paths. You either bought a packaged product and adapted your business to it (or did expensive customisation), or you built a custom solution and accepted the higher cost, longer delivery timeline, and ongoing maintenance that came with it.
That is changing.
Today, tools like Anthropic‘s Claude Code and OpenAI Codex are reducing the effort required to create working software. In some cases, you can build usable functionality from a screenshot, a rough description, or a well-structured set of requirements. That makes custom development faster, cheaper, and much more accessible than it used to be.
At the same time, organizations are no longer limited to choosing between a full custom build and a full off-the-shelf product. There is now a broader set of options:
- Buy a packaged solution when the capability is standard and mature.
- Build a tailored solution when the workflow is unique or strategically important.
- Compose a solution by combining platforms, tools, APIs, and automation into something that fits your business better than any single product (either yourself or using tools like Replit or AI agents).
- Generate at runtime (future) by using an LLM that understands the data, the context, and the intent – and creates the response, logic, or even code on the fly.
That last option is especially significant. In some cases, instead of building a traditional application with fixed screens, fixed logic, and fixed workflows, we may be moving toward systems where the model understands the data and dynamically creates what is needed in the moment. That does not replace every application pattern, but it has the potential to change the application space.
So the real shift is this: the question is no longer simply should we build or buy? The question is now what should we buy, what should we build, what should we assemble, and what should we let the system generate when needed?
What does it mean from a business perspective?
This is not just a technology shift. It is a business model and operating model shift. It changes how organizations think about cost, speed, differentiation, and control.
- Custom software no longer automatically means slow and expensive. AI-assisted development is lowering the barrier to building fit-for-purpose tools. That means organizations can now consider custom solutions in places where they previously would have defaulted to buying.
- Packaged software is no longer the only “safe” option. Buying still makes sense for mature, commodity capabilities, but it is no longer the obvious winner simply because it is faster to implement. The speed gap has narrowed.
- Competitive advantage becomes a stronger reason to build. If a workflow is central to how your organization creates value, serves clients, or differentiates itself, the case for building becomes stronger when the cost and effort of custom development drop.
- Hybrid solutions will become more common. Many organizations will not choose one path. They will buy a platform, compose services around it, add custom logic, and use AI to generate certain responses or outputs dynamically. This middle ground may become the new default.
- Maintenance shifts rather than disappears. The argument against custom solutions has often been the ongoing maintenance burden. AI tools can reduce that burden through better scaffolding, refactoring, testing support, and standards enforcement. But maintenance still exists – it just moves toward managing prompts, specs (this is key), model changes, dependencies, evaluations, and governance.
- Architecture and standards become even more important. If AI can generate code quickly, it can also generate inconsistency quickly. Organizations with strong architectural patterns, clear standards, and disciplined design approaches will get far more value than those that simply generate code without guardrails – these patterns can be fed to the AI code generator.
- Governance becomes a key business issue. The challenge is no longer only “can we build it?” It is choosing how we build it, who owns it, how is it tested, how is risk managed, and how do we control access to data and functionality? For many organizations, governance will become the real decision point.
- The economics of software portfolios may change. Some internal tools that were never worth building before may now become viable. Some expensive vendor contracts may come under pressure. Some traditional applications may eventually be replaced by more flexible, data-aware, AI-driven interaction layers.
What do I do with it?
This shift is exciting, but it should not lead to a free-for-all. The smart move is to treat this as a strategic design decision, not just a new way to code faster.
- Reframe your software decisions. Don’t just ask whether we “build or buy?” Start asking “what should we buy, what should we build, what should we compose, and what should we generate when needed? (this last one is likely a future question)”. Work with the Enterprise Architecture teams and Solution Architects to implement this.
- Identify where differentiation matters. Review your business processes and identify which ones are truly unique, valuable, or customer-facing. Those are often the best candidates for custom build or AI-enabled composition.
- Keep buying for commodity capabilities. Not everything should be custom. For standard functions like common back-office processes, mature packaged solutions may still be the right answer.
- Experiment with low-risk internal use cases. Start where the risk is manageable: internal tools, reporting interfaces, workflow helpers, or knowledge access tools. These are great places to test the new economics of AI-assisted build.
- Invest in standards before scaling. If you are going to build more with AI assistance, define your architecture principles, coding standards, security controls, documentation expectations, and testing patterns early. Speed without standards creates future cleanup.
- Treat prompts, specs, and tests as assets. In an AI-assisted environment, well-written requirements, Gherkin scenarios, acceptance criteria, and evaluation methods become even more valuable. These are no longer just supporting documents – they are part of the delivery engine.
- Build governance into the process. How does this change your SDLC? Decide who can approve AI generated solutions, how changes are reviewed, what data can be used, and how auditability will be maintained. This matters even more as the speed of creation increases.
- Look at total cost differently. Compare not just license cost versus development cost, but also fit to business need, adaptability, change velocity, maintenance approach, and long-term flexibility. (We should still look at the underlying process and whether it needs to be improved first, rather than just automating a poor process.)
- Prepare for more fluid application patterns. Some future solutions may not look like traditional applications at all. Start thinking about where fixed workflows make sense and where dynamic, model-driven (or Agent driven) interactions could be better.
The old build vs. buy debate has not disappeared – but it has evolved. AI-assisted development, composable architectures, and future runtime generation are changing the economics of software and giving organizations more options than ever before. That is a big opportunity, but only if it is approached with discipline.
The organizations that will benefit most are not the ones that rush to generate everything. They are the ones that make deliberate decisions about where to standardize, where to differentiate, where to compose, and where to let AI create on demand.
How are you thinking about this shift in your own organization? Are you still framing decisions as build vs. buy – or has your thinking already moved beyond that?
#GenerativeAI #AIStrategy #BuildVsBuy #SoftwareArchitecture #DigitalTransformation #AIAgents #ProductStrategy #EnterpriseAI #AIAdoption #TechnologyLeadership #Innovation #ComposableArchitecture