For decades, one of the first questions asked at the start of every IT project was remarkably simple: Should we build the solution ourselves or should we buy a package?
Entire sourcing strategies have been built around this seemingly binary decision. Some organisations adopted a "buy before build" philosophy, believing packaged software would reduce costs and implementation risks. Others preferred custom development, convinced that unique software was essential to differentiate themselves from competitors. Over time, this discussion expanded with additional questions. Should development be done in-house, outsourced, or somewhere in between? Should the solution run on-premise or in the cloud? Should it be implemented using Agile or Waterfall? Should one choose a single vendor or a best-of-breed landscape?
These remain valid questions today, but they no longer describe the reality of modern software delivery. The traditional buy-versus-build discussion assumes only two possible choices. In practice, there is now an entire spectrum of implementation models, with countless combinations in between.
The first major evolution occurred on the buy side. Purchasing software no longer simply means installing a package on an internal server. Organisations can still buy a traditional software license and operate everything themselves, but they can equally choose a packaged solution that is customized by the vendor, hosted by the vendor, and/or fully managed by the vendor. Software-as-a-Service (SaaS) shifted responsibility for infrastructure and maintenance to the vendor, while Business-as-a-Service (BaaS) goes even further by outsourcing parts of the operational business process itself. Between these extremes exists an almost endless range of hybrid models where responsibilities for infrastructure, software maintenance, customization, integrations and operational support are shared between customer and supplier.
Interestingly, the build side has evolved just as dramatically. Building software no longer implies writing every line of code from scratch. Modern applications increasingly resemble compositions of existing capabilities. Developers combine open-source libraries, cloud-native services, microservices, APIs, and specialized platforms into integrated solutions. Technical platforms such as BPMS solutions (e.g. Appian or Pega), ESB solutions (e.g. MuleSoft) or BI solutions (e.g. Power BI, Tableau or Qlik Sense) provide extensive capabilities for solving specific issues, like business process modelling, integration and data analytics. Even productivity platforms such as Microsoft Excel or SharePoint allow business users to create surprisingly sophisticated applications for niche business problems.
The arrival of low-code, no-code and more recently vibe coding has accelerated this evolution even further. Platforms such as Lovable, Bolt.new, Replit, Google AI Studio and many others allow non-specialists to build functional applications within hours rather than months. At the same time, professional developers are becoming dramatically more productive through AI-powered development assistants such as Claude Code, Cursor, GitHub Copilot and similar tools. Much of the repetitive coding, documentation and testing effort is now automated, allowing development teams to focus on business logic rather than technical plumbing.
As a consequence, the historical gap between custom software and packaged software is becoming increasingly blurred. Custom applications can be developed far more rapidly than was imaginable only a few years ago, reducing both implementation cost and time-to-market. Conversely, packaged solutions have become far more flexible. Most enterprise packaged software now exposes extensive configuration frameworks, workflow engines, SDKs, plugin architectures and APIs that allow customers to tailor standard software to their own business processes. Increasingly, AI even assists in creating these customizations.
This convergence changes the economics of software implementation. Traditionally, packaged software was selected because it was faster and cheaper, while custom development was justified only when significant business differentiation was required. That trade-off is becoming much less pronounced. When AI can reduce development effort by a factor of two or three, the total cost of ownership of custom software becomes much more attractive. At the same time, when packaged software can be extensively configured without modifying the core product, organisations obtain many of the benefits of custom development while retaining vendor support and upgradeability.
Does this mean that the old buy-versus-build discussion has disappeared? Certainly not. The decision remains important, but the criteria have changed. Rather than asking whether software should be bought or built, organisations should first determine where they create competitive differentiation. Few companies gain strategic advantage from developing their own authentication system, payment gateway or document management platform. These capabilities are largely commodities and can often be purchased more efficiently. On the other hand, the customer journeys, pricing models, advisory capabilities or decision engines that truly distinguish an organisation may well justify custom development.
This explains why composable architectures are becoming the dominant design philosophy. Modern solutions increasingly consist of a carefully selected combination of commercial software, cloud services, reusable APIs, open-source components and custom-developed capabilities. Rather than reinventing the wheel, organisations focus their development capacity on the small number of capabilities that genuinely differentiate them. A ride-sharing platform such as Uber illustrates this perfectly. Much of its technology stack relies on standard building blocks for maps, cloud infrastructure, messaging and payment processing. Its competitive advantage lies not in these individual components but in the unique way they are combined into a seamless customer experience. Several competitors even rely on many of the same underlying services while still competing through product design, user experience and business model.
This also changes the discussion around outsourcing. For many years, outsourcing was primarily justified through labour cost savings. In practice, software development is rarely a commodity. Productivity differences between development teams are substantial, and communication overhead, contractual complexity, onboarding efforts and differing incentives often offset much of the apparent financial advantage. Outsourcing continues to make perfect sense where providers benefit from genuine economies of scale, such as shared cloud infrastructure, managed security services or standardized operational platforms. However, when external teams effectively become dedicated long-term development teams, organisations should carefully evaluate whether the expected cost savings still outweigh the additional coordination effort and reduced organisational agility.
Ultimately, every implementation decision should therefore start with a business case, not a technology preference. Besides implementation cost, organisations should evaluate factors such as time-to-market, business agility, maintainability, availability of expertise, intellectual property ownership, operational resilience, regulatory requirements, and long-term total cost of ownership. Equally important is understanding which capabilities are truly strategic. There is little value in owning software that does not contribute to competitive advantage, while outsourcing a core differentiator may erode precisely what makes an organisation unique.
Perhaps the biggest lesson is that software implementation has evolved from choosing between two alternatives into designing the right combination of many alternatives. Every project sits somewhere on multiple spectrums: ownership, customization, hosting, operations, development approach and sourcing model. There is rarely a single correct answer, and different parts of the same solution may require entirely different implementation strategies.
The question is therefore no longer "Should we buy or should we build?" The real question has become: "What should we own, what should we consume as a service, what should we compose from existing building blocks, and where should we invest our scarce development capacity?"
In an era where AI is making custom software faster to build and packaged software easier to adapt, the most successful organisations will not be those that always buy or always build. They will be those that understand where they truly create value. Buy the commodity. Build the differentiation. Compose everything else. That is rapidly becoming the new implementation strategy for the AI era.
Comments
Post a Comment