How to Decide Where to Focus your Engineering Efforts (using Wardley Mapping)

"Not Invented Here" is a big problem for many developers.

“Yes, there are products that deliver some of the functionality we need for our feature, but those products are overkill; we only need a fraction of the functionality. By the time we integrate with the other product, we could have built it all ourselves.”

When we fall into this trap of trying to build everything from scratch, we can lose sight of what really matters: delivering value quickly.

But, equally, we can’t outsource all of our features to third parties. We would lose differentiation for our products, because anyone else could assemble the same pieces as well. It can also negatively impact the user experience through a disjointed experience, and it could end up being prohibitively expensive.

Unfortunately, architectural decisions like “build versus buy” can end up in circular, opinion-based arguments. We need a more structured way to decide which features to build and which to buy.

Understanding Wardley Mapping

Wardley Mapping, developed by Simon Wardley, provides a powerful framework for navigating these decisions. At its core, a Wardley Map is a visual representation of the components needed to serve the underlying user needs of our feature, organised along two axes: visibility to users (vertical) and evolution (horizontal). This framework helps teams understand which components are truly differentiating and which are better sourced from existing solutions.

The evolution axis is particularly important, as it shows how components naturally mature over time:

1. Genesis: Novel, uncertain components that require experimentation

2. Custom-Built: Tailored solutions for specific needs

3. Product: Established solutions available in the market

4. Commodity: Standardised, utility-like services

Creating Your First Wardley Map: A Practical Example

In our article about Breaking Down Complex Solutions, we used the example of an Expense Tracker app. We’ll continue with that app and try to uncover which elements we should build versus buy. You can read the article above to get some more context on the app that we’re building.

Let's walk through creating a Wardley Map for our expense tracking system. The process involves four key steps:

1. Start with User Needs
   Begin by identifying what users actually need, not what you think they want. In our expense tracker example, users need to record expenses, submit reports, get approvals, and analyse spending patterns.

2. Identify Components
   List all the components required to meet these needs. This includes visible features like receipt scanning and invisible infrastructure like databases and authentication systems.

3. Map Dependencies
   Draw connections between components to show how they depend on each other. For instance, expense submission depends on receipt scanning, which in turn depends on OCR technology.

4. Position on Evolution Axis 
   This is the crucial step where you determine how evolved each component is. In our example, basic authentication is a commodity (far right), while AI-driven spending analysis might be in genesis stage (far left).

Drawing a Wardley Map is a team activity because there will likely be debate about the relative placement of items on the map. These debates should be embraced because they can tease out complexities in the solution that are not obvious. And, by having the debates within a structured context, you can avoid future repetitions of the same conversations as the project progresses.

The completed map reveals where to invest in custom development versus using existing solutions. For example, the map might show that building custom OCR technology adds little strategic value when excellent commodity solutions exist. Items in the custom development and genesis phases should be delayed until later in the feature delivery, where possible, in case the team learns that these items are not needed.

Bringing It All Together

The true power of Wardley Mapping lies in how it transforms technology discussions. Instead of circular debates about individual technologies, teams can have structured conversations about strategic value and evolution. This leads to better decisions about where to invest development resources and where to leverage existing solutions.

The key insight is that not everything needs to be built from scratch. By carefully mapping components and their evolution, organisations can focus their innovation efforts where they truly matter while standing on the shoulders of giants for everything else.

The expense tracker example demonstrates this perfectly. While custom development might focus on unique features like company-specific policy enforcement, the map clearly shows that components like authentication and storage are better sourced from commodity providers. This approach leads to faster delivery, better resource allocation, and more sustainable technology strategies.

If you want to dive deeper into Wardley Mapping, I can highly recommend the book by David Anderson, The Value Flywheel Effect.