Discuss Whether to Build or Buy

An engineering leader says a team has enough ability to create a capability internally. Treat such a statement as an invitation to compare work, rather than an objection requiring a quick rebuttal. Engineers often have sound reasons for a build. Their team might know a workflow deeply, need control over a specialized process, or already possess useful components. A seller loses credibility by pretending an internal route lacks merit. Start by asking which problem a prototype or proposed build serves.

A useful comparison begins after a first release. A small internal project might answer an immediate need. Production ownership brings further questions. Who responds when a workflow fails? Who watches changes? Who handles support requests? Who decides when a dependency needs attention? Who keeps documentation current when an original author moves onto another project? Such questions do not accuse engineers of poor skill. They describe ordinary responsibilities deserving an honest place in a decision.

In a fictional practice situation, Marcos leads an engineering group at a subscription business. His team built a small tool for routing approval requests between support and finance. A prototype worked for one team during a two week trial. A seller named Nia hears Marcos say, “Our engineers have enough skill to finish this ourselves.” Nia replies, “What does finished mean for your group after people depend on a workflow every day?” Marcos pauses, then says a prototype has no alerting, user support plan, or agreed owner for permission changes.

Nia does not claim a purchased platform solves every concern. She asks Marcos to define an operating horizon. “Who owns this during a next two planning periods?” Marcos names a staff engineer for technical decisions and an operations manager for daily questions. Nia asks whether either person has capacity alongside current roadmap work. An answer matters more than a generic feature comparison. A path with a named owner, known workload, and realistic review schedule deserves serious consideration.

Use one required workflow as a center of a conversation. Avoid comparing broad categories such as flexibility or ease of use without an example. Ask a buyer to walk through a request from start to finish. Who starts a request? What information enters a process? Which decision requires approval? What happens when data is missing? Where does a person need a clear record? A shared workflow exposes responsibilities hidden behind a simple claim about engineers building a service.

Marcos describes a fictional approval request. A support lead enters a request on Monday morning. Finance needs a cost center before approval. A prototype accepts a request, yet provides no clear place for a reviewer to ask for missing information. An employee sends a message outside a tool, then later copies an answer into a note. Nia asks who would decide how exceptions appear in a production version and who would test them after each significant change. Marcos says a team has assigned neither task.

This discussion should include an internal build as a real option. Ask what a team already has and what work remains. An internal service might use existing identity systems, logging conventions, or data structures. Such assets change an amount of new work. A purchased platform might need configuration, integration, internal training, or a revised operating process. Such work belongs in a comparison. A fair conversation names work on both paths rather than treating either path as effortless.

Build a simple ownership map together. Put each responsibility in plain language: defining a workflow, implementing changes, handling access, watching for failures, answering user questions, reviewing data, and deciding priorities. Then place a person or team beside each responsibility for both options. Blank spaces matter. A blank beside support or maintenance does not prove a build is wrong. A blank signals an open decision. An engineering leader might fill a gap, reduce scope, or prefer another route.

Cost discussions work best when connected to work already planned. Avoid speculative numbers presented as facts. Ask which roadmap item moves when a same group builds and operates a service. Ask whether planned integration or security review is shared with another project. Ask what portion of support falls on an existing team. Answers help a buyer weigh priorities without a seller inventing a return calculation.

In a fictional situation, Marcos expects his staff engineer to spend six working days extending a prototype before a broader release. The engineer also owns a reporting project due in seven weeks. Nia asks how a reporting date changes when approval work becomes a priority. Marcos says a team needs to move a reporting release by one planning cycle or add another engineer. This does not settle a choice. A detail gives leadership a concrete tradeoff for review.

Respect buyer engineers during every part of a conversation. Do not describe a prototype as a toy or shortcut. Ask what a team learned from building one. An answer might reveal a hard requirement your offering does not address. When such a gap appears, acknowledge a gap. A seller who gives a clear boundary helps a buyer reach a sound decision, even where an internal approach fits better. Trust grows from accurate limits rather than a broad promise.

Ask for evidence needed to compare both routes. For an internal build, evidence might include a brief architecture outline, expected owners, planned milestones, and unresolved operational questions. For a platform, evidence might include a demonstration of a required workflow, a clear statement of product boundaries, and an account of work required from a buyer’s team. Keep evidence tied to a decision criterion. A long feature tour rarely helps an engineering leader decide who owns a failed approval request on a busy morning.

Set a decision meeting with people who live with a result. Invite an engineering owner, an operations owner, and a person responsible for a business workflow. Send a short note before a meeting. State a workflow, two paths under review, ownership questions, and evidence each person brings. Avoid announcing a winner in an invitation. A meeting should test assumptions, rather than approve a choice made in advance.

During a meeting, let a buyer lead discussion of an internal option first. Ask them to describe scope, owners, and timing. Then show only a relevant portion of your offering and state any boundary. Return to an ownership map. When a responsibility has no owner on either path, name a gap before comparing benefits. End by asking what needs resolution before a decision. A clear next action is more useful than an artificial close.

For a practice exercise, use Marcos’s fictional approval workflow. One person plays Marcos, one plays a staff engineer, and one plays Nia. The group spends ten minutes listing operational responsibilities for an internal build. Then Nia asks one question about an unowned responsibility instead of defending a product. Before a session ends, Marcos writes a reporting deadline, a six day estimate, and a missing support owner on a decision note. On Tuesday afternoon, he sends a note to an operations manager, asks for a Thursday review, and attaches a revised ownership map with every blank space marked for discussion.