Episode 38 — Choose Wisely Between Acquire and Build in Modern Digital Environments
In this episode, we move into one of the most practical decisions in the product and service lifecycle, and one that can shape everything that follows long after the initial excitement of improvement has faded. New learners often hear acquire and build and assume the choice is mostly about technology, budget, or whether an organization likes doing things in house. That is part of the story, but it is not the whole story, because choosing between acquiring capability and building capability affects speed, fit, ownership, support burden, risk, flexibility, and the way value is delivered over time. In modern digital environments, the decision becomes even more important because organizations have more options than ever before, from ready-made platforms and outside providers to internal development and blended approaches that combine both. The goal is not to memorize that buying is fast and building is flexible. The goal is to understand how to choose wisely so the service becomes more useful, more dependable, and more supportable for the people who actually rely on it.
Before we continue, a quick note: this audio course is a companion to our course companion books. The first book is about the exam and provides detailed information on how to pass it best. The second book is a Kindle-only eBook that contains 1,000 flashcards that can be used on your mobile device or Kindle. Check them both out at Cyber Author dot me, in the Bare Metal Study Guides Series.
Acquire means obtaining capability from outside the organization instead of creating every part of it internally. That could include using a ready-made platform, working with a supplier, using a hosted service, or relying on an external provider for part of the service experience. Build means creating or configuring capability more directly inside the organization so the product or service reflects local needs, local design choices, and local control to a greater degree. In the lifecycle model, both stages matter because modern organizations rarely create everything alone and rarely outsource everything without keeping some local responsibility. The decision is not simply about where the code lives or who owns the hardware. It is about how the organization wants value to be created, how much control it needs, what kind of change it expects, and what level of dependence it is willing to carry in exchange for speed or convenience. Once you hear it that way, the acquire versus build decision starts feeling less like a technical preference and more like a service management choice with real consequences across the full journey.
One reason this topic matters so much is that the wrong choice can create pain that surfaces much later and in places that seem unrelated at first. A service may launch quickly because the organization acquired a capable outside platform, yet support teams may later struggle because the platform cannot be adapted cleanly to the way users actually need to work. A different service may be built internally with great ambition, yet months later the organization may realize it took on more design, testing, maintenance, and support responsibility than it can handle well. In both cases, the problem is not simply that a team picked the wrong technology. The deeper problem is that the choice was made too narrowly, without enough attention to the service outcome, the people who must operate and support it, and the long-term effort required to keep it healthy. Choosing wisely means recognizing that acquire and build are both valid paths, but neither one is safe merely because it sounds modern, independent, fast, or powerful.
Acquiring capability can create real value when the service need is common enough that a mature outside option already solves much of the problem well. Many organizations do not need to invent a new solution for routine needs such as scheduling, messaging, identity, collaboration, or content delivery when solid external services already exist. Acquiring can reduce time to value, shorten the path to initial delivery, and allow teams to benefit from outside expertise that would be expensive or slow to reproduce on their own. It can also help the organization focus its internal effort on the parts of the service that are more unique or more central to the outcome it wants to create. Yet acquiring is not the same as escaping responsibility. When an organization acquires capability, it is still accountable for how that capability fits the service, how well it supports users, how supplier relationships are managed, and how the external solution behaves inside the broader service experience. Acquisition done carelessly can create just as much pain as building done carelessly, only through dependency and weak fit instead of through overextension.
Building capability can also create real value, especially when the service requires special workflows, unusual decision logic, deeper customization, or a level of differentiation that ready-made products cannot support well enough. Building gives the organization more control over how the service behaves, how it evolves, how it integrates with local processes, and how unique needs are handled. That can be extremely valuable when the service itself is closely tied to the organization’s identity, mission, or way of creating meaningful outcomes. Yet building should never be romanticized. Internal creation sounds empowering, but it brings responsibility for design, testing, maintenance, improvement, resilience, documentation, and long-term support. It also requires honest awareness of whether the organization truly has the skills, time, focus, and governance needed to build something that can remain useful and dependable after the initial project energy fades. Building is not simply making something new. It is agreeing to carry what that new thing will require over time, including the parts that stop feeling exciting once the service becomes part of daily life.
A wise decision begins with value, because value is what tells the organization why the service exists in the first place and what the users or stakeholders actually need from it. If the need is fairly standard and the value comes mostly from making a reliable service available quickly, acquisition may be the wiser path. If the value depends on a distinctive service journey, specialized decision logic, or unique integration with local ways of working, building may deserve stronger consideration. This is where many organizations go wrong, because they let pride, habit, or industry fashion make the decision before they have defined what truly matters about the service. Some teams prefer building because it feels more capable or more independent. Others prefer acquiring because it sounds faster and less risky. Neither instinct is wise on its own. The key question is whether the capability being considered is a routine enabler of value or a meaningful part of how the organization creates value differently. That distinction often matters more than technical elegance or initial convenience.
Cost is another area where weak thinking can distort the decision badly. New learners often assume acquiring is cheaper because the organization avoids creating everything itself, or that building is cheaper over time because the organization is not paying an outside provider forever. Both ideas can be true in certain cases, but both are also dangerously incomplete. Acquisition may reduce upfront effort while introducing ongoing subscription costs, supplier management needs, change limitations, and future dependency that become expensive in practice. Building may avoid some vendor dependency while introducing high development effort, staffing needs, technical maintenance, upgrade burdens, and support costs that continue long after the initial launch. A wise decision looks beyond the first invoice or the first project estimate and asks what the full lifecycle cost will look like once the service is operating, being supported, being improved, and being relied on every day. Cost is not only about purchase price or development effort. It is about what the organization will have to keep carrying in order to preserve value over time.
Risk also needs to be understood more broadly than many people first imagine. A team may think acquisition lowers risk because an external provider already has a mature product and a large customer base. That can reduce certain kinds of risk, especially when the outside capability is stable and well supported, but it can increase other forms of risk if the organization becomes too dependent on a supplier it cannot easily influence or replace. Building can feel safer because the organization controls more of the environment, but it also creates risk if the internal team underestimates complexity, security needs, support responsibility, or the effort required to keep the service strong as conditions change. Risk in this decision includes more than system failure. It includes service continuity, user trust, supplier dependence, change responsiveness, compliance needs, and the ability to recover when something behaves differently than expected. Wise choices come from asking which risks are being traded, not from pretending one option is automatically safer in every meaningful way.
Integration is one of the clearest places where the acquire versus build decision stops being abstract and becomes visible in real service experience. A capability may look excellent in isolation and still create strain if it cannot connect cleanly with the rest of the service journey. Users rarely care whether a function was acquired or built. They care whether the service feels coherent, whether information stays consistent, whether the next step is understandable, and whether support staff can explain what is happening when something goes wrong. A solution acquired from outside may be strong on its own but awkward when connected to local data, local workflows, or local communication needs. A solution built internally may match the environment well but become complicated if it tries to recreate too many features that external tools already handle effectively. This is why wise choices consider fit across the full service, not just within one team’s local view. The question is not whether a capability works in theory. The question is whether it works as part of the whole product and service experience people will actually live through.
A common beginner mistake is treating acquire and build as a strict either-or decision when modern digital environments often reward a blended approach. Many of the strongest services combine acquired components with internally built logic, locally designed workflows, or carefully chosen extensions that make the overall experience more appropriate for the organization and its users. An organization may acquire a stable platform for routine functions while building the pieces that reflect its unique service model. It may build the workflow and communication layer around acquired core capability so the experience fits local needs more naturally. This blended path is not automatically better, but it is often more realistic because it allows the organization to avoid rebuilding everything from scratch while also avoiding the rigidity that can come from relying on a generic tool without thoughtful adaptation. The deeper lesson is that wisdom often lies in balancing standard capability with local value creation, rather than choosing one extreme simply because it sounds cleaner in a meeting.
Imagine a community college deciding how to improve its digital student portal for registration, deadlines, and financial aid updates. The college could acquire a ready-made student experience platform that already handles many routine functions well, which might speed up initial improvement and reduce the amount of local development needed. It could also decide to build a more customized experience because its students struggle with a very particular sequence of tasks, support interactions, and communication needs that generic products do not address clearly enough. A wise decision would not begin with which option sounds more modern. It would begin with what students actually need from the service, which workflows truly require local design, what support teams can realistically explain and sustain, how much change the college can manage well, and what parts of the portal are routine enough to standardize. The answer might be to acquire a strong core platform while building the guidance, messaging, and workflow elements that make the journey more understandable for students. That is what choosing wisely sounds like when value, fit, and long-term support all matter.
A neighborhood health clinic faces a similar question when improving digital appointment booking and follow-up communication. It could acquire an external scheduling and messaging platform that is already proven, widely used, and fast to deploy, which may be the right move if the clinic mainly needs dependable routine capability. It could also choose to build more of the service logic itself if patient communication, preparation guidance, and care pathways are distinctive enough that standard tools keep producing confusion or weak support experiences. A wise choice would ask whether the clinic’s real need is common and operational, or whether the experience itself is central enough to care quality and patient trust that stronger local control is necessary. It would also ask who will own the service after launch, who will adjust it as clinical needs change, and how front desk staff and clinicians will support the resulting experience in daily life. Once again, the decision is not between modern and old-fashioned approaches. It is between different kinds of responsibility, different kinds of flexibility, and different ways of carrying value through the service journey.
The lifecycle model also helps make better choices here because acquire and build should never be separated from discover, design, transition, operate, deliver, and support. Discovery helps the organization understand what truly needs to be solved before it decides how capability should be obtained or created. Design clarifies what kind of service experience is required, which makes it easier to judge whether an outside solution fits or whether local creation is necessary. Transition matters because acquired and built capabilities both need to move into live use responsibly. Operation, delivery, and support matter because the real cost and quality of the decision will be felt there long after the initial project is celebrated. This is one reason rushed choices often disappoint people. Teams make the acquire versus build decision too early and too narrowly, as if it were the entire story. In reality, it is one major choice inside a longer lifecycle, and it becomes wiser when the full lifecycle is kept in view from the beginning.
By the end of this discussion, choosing wisely between acquire and build should feel like a service design and management decision rather than a technical preference or a matter of organizational pride. Acquisition can create value through speed, maturity, and focus when outside capability fits the need well enough. Building can create value through control, fit, and distinctive service design when the experience truly depends on local creation. Both paths carry cost, both carry risk, and both require real ownership after the initial choice is made. In modern digital environments, the wisest answer is often the one that understands where standard capability is sufficient, where local design truly matters, and how the resulting service will be supported across its full lifecycle. That is the deeper lesson ITIL is pushing you toward. Choose not by fashion, not by ego, and not by fear of one path or the other. Choose by asking which mix of capability, responsibility, and long-term support will best help the service create meaningful value for the people who depend on it.
