Insight

Guide to Product Decisions

Stop building what you should buy. Use Wardley Mapping as a practical tool for smarter build-vs-buy and product evolution decisions.

Alaa Almallah November 6, 2024 9 min read

Most build-vs-buy mistakes are not technical mistakes. They are ownership mistakes.

Teams build things they should merely use because building feels like control. Teams buy things they should own because buying feels faster. Six months later the codebase is full of proud wrong turns: a custom auth layer nobody wanted to maintain, or a vendor workflow sitting exactly where the product should have been differentiated.

The useful question is not "can we build it?" It is "if this decision goes wrong, where do we want to carry the regret?"

This is a practical take on Wardley Mapping for founders and product teams. The goal is not a pretty strategy artifact. It is to stop spending senior attention on components that do not deserve it.

If you are still defining the first shippable slice, pair this with How to Ship an MVP Without a Full Product Team. If the market itself is moving under your feet, follow with Product Strategy in Uncertain Markets.

The wrong question teams ask

Build-vs-buy debates usually sound like this:

"The vendor is expensive."
"We could build a lighter version ourselves."
"It would be cleaner in our architecture."
"What if we outgrow it later?"

Those are not useless questions. They are just second-order.

The first-order questions are:

If this breaks, does the user experience break in a way that changes our product truth?
If this becomes a bottleneck, will we regret not owning the pace of change?
If we build it, are we prepared to own the boring parts for years, not the launch week version?

That is the frame: own the regret, not the component.

A simpler Wardley map

You do not need a workshop wall full of sticky notes. You need three labels for every major component:

User proximity - how close is this to the job the customer hires you for?
Strategic volatility - how likely is this layer to change because of market learning?
Market maturity - is this still special, or is it now a product everyone can buy?

Map components top-down:

`` User job -> Product behavior that makes you different -> Systems that support that behavior -> Utilities that keep the lights on ``

Most teams reverse the map. They start with the stack they know, then invent reasons it matters to the user.

The regret test

Here is the decision lens I find more useful than generic "core vs non-core."

If we buy this and regret it...	If we build this and regret it...	Default bias
We move slower on a meaningful product behavior	We burn months on plumbing nobody values	Buy unless product truth lives here
A vendor caps our learning speed	We create a maintenance tax with no moat	Buy until pace itself becomes strategic
We cannot shape the workflow we are betting on	We become the unpaid vendor for a commodity	Build only where the workflow is the product

That table cuts through ego quickly.

Example: auth

Most early teams do not regret buying auth. They regret trying to be an identity company by accident.

What they usually want is:

secure login
password reset and session handling
role basics
maybe SSO later

That is not product truth. That is table stakes. The regret of buying is low. The regret of building is years of subtle security and maintenance work.

Example: payment rails

Almost nobody wins because they built card capture from scratch. They win because they priced well, packaged well, or designed trust into checkout.

Own the parts below. Rent the rails.

Layer	Own or rent?	Why
Pricing model	Own	This is part of the product logic
Packaging and entitlements	Own	It shapes the offer and expansion path
Card collection and processing	Rent	Compliance and reliability burden
Reconciliation logic tied to your business rules	Own lightly	It touches finance reality and support pain

Example: AI features

This is where people get confused fastest.

Owning model infrastructure is rarely the differentiator at the start. Owning the workflow, evaluation logic, domain context, and failure handling often is.

So the question is not "should we build AI in-house?" It is "which layer actually contains the learning we cannot outsource?"

What usually deserves ownership

Build or deeply own when the layer carries product truth:

the workflow that defines why a customer chooses you
decision logic tied to hard-won domain knowledge
integration behavior that becomes part of the user promise
trust-shaping product details users feel directly

Rent or adopt when the layer is mostly solved and mostly boring:

auth
storage
email delivery
commodity analytics
generic search
billing rails
standard admin surfaces

The test is not glamour. It is whether the layer compounds your learning.

Product truth vs utility tax

This distinction matters more than "core" because "core" gets abused. Every team says their stack is special.

Product truth

Code or systems that teach you something specific about the customer, the workflow, or the decision you are betting on.

Examples:

a ranking model whose output changes the experience materially
a workflow engine built around how a real operations team handles exceptions
custom permissions because the domain is unusual, not because the team dislikes vendors

Utility tax

Systems you only notice when they break, but which do not make the product more itself.

Examples:

password reset flows
generic file upload plumbing
basic CMS editing
commodity queuing and notifications

Good teams pay utility tax with money. Bad teams pay it with senior attention.

How decisions age

A correct decision can still become wrong later.

That is why build-vs-buy should include an evolution note at the moment you decide.

Today	Six months later	What to watch
Vendor is fine for current needs	Team keeps hacking around it	Pace of change becomes the issue
Custom system fits a unique case	Market tools catch up	Owning it may stop paying
Managed service is cheap and fast	Costs spike with scale	Revisit economics, not only architecture
Open source gives flexibility	Nobody on the team wants to maintain it	Hidden ownership becomes real ownership

Write down what would change your mind. If you do not, every revisit becomes emotional.

A useful 45-minute exercise

Run this on one live product area, not the whole company.

Step 1. List the critical layers

Pick one user journey and list:

what the user is trying to get done
which parts of the system define that experience
which parts merely support it

Step 2. Score each component

For each component, ask:

close or far from the user job?
likely to change as we learn?
already mature in the market?
painful if we do not control it?

Step 3. Make one move only

Do not rewrite the architecture from the workshop. Pick one:

migrate a commodity custom layer to a managed service
pull one product-truth layer back in-house
document an exit path for a vendor sitting too close to strategy

One good move beats a map nobody revisits.

Common failure modes

Architecture pride. The team wants to prove they can build the thing.
Vendor shame. Buying feels less "serious" than owning.
Frozen decisions. A call made at one stage becomes doctrine even after the market changes.
Fake differentiation. Teams label plumbing as strategic because they already invested in it.
Ignoring maintenance appetite. A team wants launch ownership, not long-term ownership.

For how technical choices compound over time, see The Architecture of Decisions. For how AI accelerates the wrong kind of overbuilding, see Working with AI Coding Assistants.