Imagine a company planning a customer scheduling product. One proposal is to build everything. Another is to buy a scheduling platform and configure it. Both proposals sound decisive, but neither explains where the business needs control.
We prefer to draw that boundary before comparing delivery estimates. Which decisions define the customer experience? Which capabilities are supporting infrastructure? Where would a supplier's limitations become your product's limitations?
Name the difference your customer would notice
Perhaps the distinctive part of the product is how appointments are matched to specialist availability. The calendar display may be ordinary, while the matching rules are central to the business.
In that case, buying parts of the scheduling infrastructure could make sense while retaining ownership of the matching experience. The reverse might be true if a supplier already supports the rules but cannot provide an acceptable customer journey.
Write down the cases that matter before asking vendors for demonstrations. Include the awkward ones: a rescheduled appointment, a cancelled practitioner, an organisation with several locations. A polished demonstration of the standard flow does not settle whether the product can support your operating model.
Compare the work around the purchase
A subscription price is only one part of the decision. Someone still has to connect identities, move data, handle exceptions, train staff, and support customers when two systems disagree.
For each option, sketch the complete journey and mark the responsibility boundaries. If a booking fails between your application and the supplier, who can inspect it? Who can correct it? Can your support team explain the current state without opening several unrelated tools?
Do the same exercise for a custom build. Owning code does not remove the cost of maintaining it. A fair comparison includes the work required to keep both options useful after the initial release.
Test the constraint that could change the decision
Do not build a broad prototype just to make both options feel tangible. Identify the uncertainty most likely to reverse your choice.
It could be whether the supplier exposes the event you need, whether your team can export usable data, or whether the required workflow can be expressed without fragile customisation. A bounded technical investigation can answer that question before you commit to the larger implementation.
Record what would trigger reconsideration later. If a supplier's limits are acceptable at the current scale, name the condition under which they would stop being acceptable. This turns an architectural argument into a decision the business can revisit deliberately.
The strongest answer is often a combination, but it should be a reasoned combination. Build the parts where ownership serves the product, buy the parts that meet the need, and take responsibility for the connection between them.
Talk to us about a product decision with engineering consequences.