Introduction
For decades, Enterprise Architects have relied on a simple hierarchy: Re-Use before Buy, Buy before Build. This principle has guided countless IT investment decisions and saved organisations from the risks and costs of unnecessary custom development. But what happens when building becomes as fast and cheap as buying?
AI-assisted development is fundamentally changing the economics of software creation. What once required months of development and teams of specialists can now be prototyped in hours and refined in days. This isn't a marginal improvement—it's a paradigm shift that forces us to reconsider one of Enterprise Architecture's most sacred principles.
As someone who has spent the last six months actively working with AI coding tools, I've witnessed this transformation firsthand. Projects that would have been automatic "Buy" decisions a year ago are now viable "Build" candidates. The question is no longer whether AI will change the Build vs Buy calculus, but how quickly organisations will adapt their decision frameworks.
We're moving toward a "Re-Use Before Build" EA principle where organisations leverage existing assets and AI to create on-demand solutions, potentially bypassing traditional software procurement for an expanding range of use cases.
The Traditional Principle
Before examining what's changing, let's understand why "Re-Use, Buy, Build" became the dominant framework in Enterprise Architecture.
Leverage existing enterprise assets—APIs, services, components, or entire applications. This maximises prior investments, reduces integration complexity, and ensures consistency across the technology landscape. Re-use is nearly always the lowest-risk, lowest-cost option.
When no existing asset fits the need, evaluate commercial off-the-shelf (COTS) solutions. Vendors have already invested in development, testing, and support. The shared cost model means enterprise-grade functionality at a fraction of custom development costs.
Custom development is the option of last resort. Reserved for truly unique requirements where no existing solution provides competitive differentiation. Building carries the highest cost, longest timeline, greatest risk, and ongoing maintenance burden.
Why This Hierarchy Made Sense
Cost Economics
Custom development required expensive specialists working for months. Buying amortised those costs across thousands of customers.
Risk Profile
Build projects frequently overran budgets and timelines. Commercial products offered predictable pricing and proven functionality.
Quality Assurance
Vendors invested in testing, security, and compliance that few internal teams could match.
Maintenance Burden
Custom software required ongoing support, updates, and technical debt management indefinitely.
This framework served organisations well for decades. But every assumption it rests upon is now being challenged.
The AI Disruption
AI-assisted development doesn't just make coding faster—it fundamentally restructures the economics of software creation.
What's Actually Changing
Before AI
Weeks to months for functional prototypes
With AI
Hours to days for working applications
Before AI
Required specialised developers for each technology
With AI
General technical competence enables broader creation
Before AI
Change requests meant significant rework
With AI
Rapid iteration through conversational refinement
The New Economics of Build
Consider a typical departmental tool—perhaps a workflow tracker, a reporting dashboard, or a data validation utility. Under the traditional model, the analysis would look something like this:
$ Traditional Build vs Buy Analysis
$10,000-50,000 annual licensing. 3-6 month implementation. 70% feature fit. Vendor dependency for customisation.
$100,000+ development cost. 6-12 month timeline. 100% feature fit. Ongoing maintenance burden. High failure risk.
Buy. The economics aren't even close. Accept the 70% fit and work around the gaps.
AI AI-Era Build vs Buy Analysis
Same as above: $10,000-50,000 annual. 3-6 month implementation. 70% feature fit. Vendor lock-in.
$5,000-20,000 development cost. 2-4 week timeline. 100% feature fit. Iterative refinement. Internal ownership.
Build becomes viable. Perfect fit, faster delivery, lower long-term cost, no vendor dependency.
This isn't hypothetical. It's happening now, across industries, as organisations discover that the "Build" option has fundamentally changed.
Toward Re-Use Before Build
If AI makes building cheaper and faster, what happens to the traditional hierarchy? I believe we're moving toward a new model: Re-Use Before Build.
Leverage existing enterprise assets—APIs, data sources, authentication systems, design systems. These become the building blocks that AI-generated solutions consume and extend. Re-use remains essential, but its role shifts from "complete solution" to "enabling infrastructure."
Use AI to rapidly construct solutions on top of the re-use foundation. Generate applications, integrations, and workflows that perfectly fit requirements. The "Build" step becomes a form of sophisticated assembly rather than ground-up construction.
Reserve purchasing for truly complex enterprise systems—ERP, CRM, core banking. Systems where the vendor's domain expertise, compliance investment, and ecosystem integration genuinely exceed what AI-assisted development can achieve.
Software on Demand
The logical extension of this paradigm is "Software on Demand"—the ability to generate fit-for-purpose applications when and where they're needed, rather than procuring and configuring generic solutions.
Imagine a business user describing a need: "I need a tool that pulls data from our inventory system, cross-references it with supplier lead times, and alerts me when we risk stockouts." In the traditional model, this triggers a procurement process, vendor evaluation, contract negotiation, and implementation project. In the Re-Use Before Build model, an AI assistant generates a working prototype within hours, iterating until the solution fits perfectly.
This isn't science fiction. The foundational capabilities exist today. What's needed is the organisational readiness to embrace this approach.
When Buy Still Wins
Let's be clear: this isn't a "Build everything" manifesto. Commercial software remains the right choice for many scenarios. The question is where the boundary lies—and that boundary is shifting.
Buy Remains Optimal For:
1 Complex Enterprise Systems
ERP systems, core banking platforms, supply chain management, healthcare information systems.
Decades of domain expertise, regulatory compliance, complex integrations, and proven scale that no AI can replicate in reasonable timeframes.
Integration layers, custom extensions, reporting, and workflow automation around purchased platforms.
2 Regulated Industries
Financial services compliance, pharmaceutical validation, medical device software, aviation systems.
Certification requirements, audit trails, and liability frameworks that require vendor accountability and proven compliance track records.
Documentation generation, compliance checking, test automation—augmenting rather than replacing certified systems.
3 Ecosystem Dependencies
CRM systems with marketplace integrations, collaboration platforms, industry-specific networks.
Value derives from network effects, partner ecosystems, and marketplace integrations that custom solutions cannot replicate.
Custom integrations, data synchronisation, bespoke workflows connecting platform capabilities.
The Expanding "Build" Zone
What's changing is the scope of viable Build candidates. Applications that were previously automatic "Buy" decisions now deserve fresh evaluation:
Departmental Tools
Workflow trackers, approval systems, scheduling tools, internal portals—often better served by custom solutions that fit exactly.
Integration Layers
Data synchronisation, API orchestration, event-driven workflows—AI excels at connecting existing systems.
Reporting & Analytics
Custom dashboards, data visualisations, automated reports—rapidly generated from existing data sources.
Process Automation
Validation workflows, approval chains, notification systems—bespoke logic without RPA platform overhead.
Impact on IT Organisations
The shift toward Re-Use Before Build has profound implications for how IT organisations are structured, staffed, and governed.
Role Evolution
Developers
Code writers, implementation specialists
Architects
Solution designers, technology selectors
Developers
AI collaborators, code reviewers, integration specialists
Architects
Platform enablers, governance designers
Orchestrators
Solution specifiers, AI directors, quality governors
Enablers
Platform builders, re-use curators, capability providers
New Capabilities Required
- Prompt Engineering: The ability to translate business requirements into effective AI instructions becomes a core skill. Clear specification leads to better generated code.
- AI Output Validation: Teams must develop expertise in reviewing, testing, and securing AI-generated code. This requires understanding code without necessarily writing it.
- Platform Thinking: Re-use becomes more valuable when existing assets are designed for AI consumption. APIs, data services, and components need to be AI-ready.
- Rapid Iteration: The value of AI development comes from speed. Organisations need processes that support quick cycles, not waterfall governance.
Governance Implications
More building means more governance. Organisations must establish frameworks for AI-generated code review, security scanning, and quality assurance before scaling AI development. The speed of creation demands automated validation pipelines.
Code Review Policies
Who reviews AI-generated code? What level of scrutiny is required? How do we ensure security and compliance?
Ownership & Maintenance
Who owns AI-generated applications? How do we prevent proliferation of unmaintained solutions?
Quality Standards
What testing is required before deployment? How do we validate AI code meets enterprise standards?
Intellectual Property
How do we handle IP considerations for AI-generated code? What are the licensing implications?
Implementation Guidance
Phase 1: Foundation 0–6 months
- Audit Re-Use Assets: Catalogue existing APIs, services, and components. Identify gaps in discoverability and documentation that would hinder AI-assisted development.
- Pilot AI Development: Select low-risk use cases for AI-assisted building. Departmental tools, internal utilities, and proof-of-concepts are ideal starting points.
- Establish Review Processes: Create lightweight governance for AI-generated code. Security scanning, code review checklists, and approval workflows should be in place before scaling.
- Train Key Personnel: Develop prompt engineering and AI collaboration skills in your most capable developers. These early adopters become champions and mentors.
Phase 2: Expansion 6–18 months
- Revise Decision Frameworks: Update your Build vs Buy evaluation criteria to account for AI-assisted development economics. Create decision trees that incorporate new cost/time factors.
- Enhance Re-Use Layer: Invest in making existing assets more AI-consumable. API documentation, example code, and integration patterns accelerate AI development.
- Expand Practitioner Base: Move beyond early adopters to broader AI development capability. Consider citizen development programmes with appropriate guardrails.
- Measure and Iterate: Track outcomes from AI-built vs purchased solutions. Use data to refine decision frameworks and identify optimal use cases.
Phase 3: Transformation 18+ months
- Platform Evolution: Transform your re-use layer into a true "AI-ready" platform. Self-service capabilities, automated testing, and deployment pipelines enable scale.
- Vendor Strategy Revision: Renegotiate vendor relationships with new leverage. Some solutions may be candidates for replacement; others become more strategic as platforms.
- Organisation Restructure: Evolve IT organisation structure to reflect new operating model. Platform teams, AI enablement functions, and governance centres of excellence.
- Continuous Optimisation: Establish feedback loops between AI development outcomes and platform capabilities. What gets built should inform what gets re-used.
The Path Forward
The Re-Use Before Build paradigm isn't about abandoning procurement—it's about having more options. Organisations that master AI-assisted development gain agility, reduce vendor dependency, and create perfectly-fit solutions faster than traditional approaches allow. The question isn't whether to adopt this model, but how quickly you can build the capabilities to execute it effectively.
Comments
Share your thoughts on how AI is changing your Build vs Buy decisions.