“Should we build or buy the booking system?” sounds like one decision. In practice, a booking service contains several different things: the customer experience, scheduling rules, calendar data, notifications, and infrastructure. Treating the whole service as one component can push a team toward building too much or buying something that cannot support the part that makes its service useful.
A Wardley map separates those components and places them in context. This worked example uses a hypothetical equipment-repair service to explore where a team might experiment, where it might compare available products, and what it still needs to learn before choosing.
Read the two axes correctly
Wardley Mapping, created by Simon Wardley, connects a user's needs to the capabilities that support them. The vertical dimension represents the value chain and how visible its components are to the user. The horizontal dimension represents evolution, commonly labeled Genesis, Custom, Product, and Commodity. Learn Wardley Mapping's landscape guide explains how these positions and dependency relationships form a map.
Evolution is not a delivery timeline. Moving a component to the right does not mean the team will finish it next month. Nor does a low vertical position mean something is unimportant: an infrastructure failure can prevent the entire service from working.
The map also differs from a strategy map organized around strategic objectives. Here, the question is how the service's underlying capabilities relate to user needs and how established those capabilities are in the relevant environment.
Start with the repair customer's need
Our example service arranges visits to repair commercial kitchen equipment. The user is a restaurant operator who needs a suitable technician at a workable time. The immediate need is not “use our scheduling platform.” It is to arrange a visit that can actually address the fault.
Write that need near the top of the board. Under it, list what must be available: a booking experience, information about the equipment and fault, a way to match the job to technician capability, available appointments, and a confirmation the operator can understand.
Now ask what those capabilities depend on. Appointment availability needs calendar information. Matching a job needs information about equipment types and technician skills. Confirmation needs a notification service. The digital service also needs computing infrastructure, even though customers do not normally interact with it directly.
Draw a connection only when one capability needs another. Two components being owned by the same department is not enough. If the team starts debating every database and API, return to the decision in scope: which parts of the booking service should it develop or source?
Place components using evidence, not familiarity
For this example, assume the team has found several established scheduling products but is still experimenting with a way to route unusual equipment faults. These assumptions define a teaching scenario, not a market assessment of actual vendors.
| Component | Illustrative position | Reason for that position | Evidence the real team would need |
|---|---|---|---|
| Experimental fault-routing approach | Genesis | The proposed approach is novel and its usefulness is uncertain | Existing alternatives and tests showing whether the approach works |
| Repair-specific booking journey | Custom | The example requires a tailored sequence for unusual jobs | Observed customer tasks and a comparison with available workflows |
| Appointment scheduling | Product | The scenario assumes established products with recognizable features | Current product capabilities, constraints, and integration requirements |
| Customer notifications | Product | The scenario assumes a configurable service that can meet the basic need | Delivery behavior, accessibility, operational fit, and supplier terms |
| Basic compute capacity | Commodity or utility | The example treats this as a standardized supporting capability | Service requirements, available provision, and constraints on its use |
Place the booking journey relatively high because it is close to the customer's experience. Put supporting capabilities below it and connect the dependencies. Avoid turning the rows of this table into five disconnected dots; the relationships are what make the sourcing discussion specific.
“We wrote it ourselves” does not establish that something belongs in Custom. A team can maintain its own implementation of a capability that is widely available as a product or utility. Conversely, purchasing specialist work does not make the underlying capability a standardized product.
If the team cannot agree on a position, attach the competing reasons. “Booking engine” may need to be split into routine appointment allocation and unusual-job routing before the disagreement makes sense. A single broad label can conceal components with very different characteristics.
Use the map to change the build-or-buy question
The initial proposal was to build an entire booking system. The map suggests a more focused investigation: can the team source ordinary scheduling while retaining room to develop the repair-specific customer experience and test the unfamiliar routing approach?
That is a question to test, not an automatic recommendation. A scheduling product might impose a rigid booking sequence, require information the customer cannot provide, or make a critical capability difficult to change. A component's position does not remove the need to inspect fit, operating costs, contracts, security requirements, or the practical work of switching.
Simon Wardley's account of an early map shows the value of examining components at different stages of evolution rather than treating a business system as one undifferentiated thing. The repair service can apply that way of looking without borrowing the conclusions of his historical example.
Compare two concrete options
Option A is to build the booking journey, scheduling, and notifications together. The team would control those interactions, but it would also take responsibility for maintaining several capabilities that might already be available elsewhere.
Option B is to build a narrow customer-facing layer around a scheduling product. It may reduce the amount the team must maintain, but only if the product can support the required appointment rules and expose the information the experience needs.
Test Option B with a difficult booking, not just a convenient demonstration. Use a restaurant with an uncertain fault, a technician who handles only some equipment types, and an appointment that may need to change after more information arrives. If the sourced component cannot support that sequence, decide whether the problem is configuration, a missing interface, or a fundamental mismatch.
Draw the service map in Boardmix
Open Boardmix and create a blank board. Draw a horizontal axis labeled Evolution and divide it into Genesis, Custom, Product, and Commodity. Add a vertical label, “Visibility to user,” with the more visible end at the top.
- Place “Restaurant operator” above the need “Arrange a suitable repair visit.” Keep this anchor visible while adding capabilities.
- Add “Repair booking journey” beneath the need. Connect it to “Fault routing” and “Appointment scheduling.”
- Place the five example components in their provisional positions. Add short text labels to the dots so the diagram works without color.
- Connect the booking journey to notifications because confirming the visit is part of this example service. Show the supporting compute dependency lower on the map.
- Place a note beside fault routing: “Experimental approach—compare existing alternatives.” Put the two sourcing options outside the map so they do not look like additional capabilities.
Keep current and proposed arrangements separate. If you want to explore sourcing scheduling, duplicate the relevant drawing area and label the second version as an option. Moving a dot across the original map without explanation can make a proposal look like something already true.
Recognize what the map cannot decide
A map does not calculate the best supplier, establish a return on investment, or tell you when a capability will become commoditized. Resist adding precise coordinates or forecast dates merely to make the drawing appear analytical. A rough position with a clear reason is more useful than an unsupported decimal.
For the repair service, the immediate question is whether the routine scheduling component can be separated from the unusual-job logic without weakening the customer experience. A small integration experiment can answer part of that question. Customer observation can answer another part. The map helps the team see why those investigations belong together.
If the scheduling product fits, the team can reserve more of its effort for the part of the repair journey that remains uncertain. If it does not, the map shows which dependency needs attention instead of reducing the discussion to “buying failed, so build everything.”
