Overview

Complex web projects don’t usually go wrong because teams can’t build properly.

They go wrong because we rush to the solution before we truly understand the problem.

You’ll recognise it in lines like:

• “Just copy what we have now, but better.”
• “Let’s pick the platform first, then we’ll know what’s possible.”
• “We can always refactor later.”
• “It’s a simple change.”
• “We need it to be flexible.”

These aren’t bad intentions. There are signals that clarity is missing.

What we mean by “clarity”

Clarity is when everyone agrees on the goal, the constraints, how we’ll measure success, and the plan before we start building.

Not a perfect spec. Not a giant backlog. It is a shared understanding of the problem you want to solve and the options available, narrowed down to a single, agreed decision on the path forward.

The real costs of unclear work

When clarity is missing, projects get expensive in predictable ways:

• Rework - because teams built the wrong thing, or built it in the wrong order
• Slow decisions - because ownership and approvals aren’t clear
• Integration surprises - because “it connects to X” wasn’t mapped properly
• Higher long-term costs - more environments, more maintenance, more support
• Missed outcomes - you ship features, but the results don’t move
• Technical debt - because short-term decisions become long-term constraints that limit future work

This is why “simple” requests become complex when you work with real systems and real teams.

The two places clarity breaks first: integrations + governance

In most modern builds, the hard part isn’t the UI.

It’s usually:

• Integrations: what system owns what data, how it flows, what happens when it fails
• Governance/approvals: who can change what, who signs it off, and how publishing actually works

If these aren’t clear early on, delivery becomes a constant negotiation.

Two examples (anonymised)

Story 1: “We need a second site"

A client had multiple local versions of their site, each run by a different team. They asked us to duplicate the site we’d built for them for a new location. They assumed separate teams meant separate sites.

We ran a short Discovery session to understand:

• How each team manages content today
• How they want to work going forward

What we found: they didn’t truly need “two sites”. They needed operational autonomy (two teams editing their own local content without friction). The CMS setup already supported this.

So we:

• Migrated the content
• Switched on and configured the multi-locale setup properly
• Kept one platform

Result: No second deployment, lower maintenance, better content reuse, and reduced server costs while still giving both teams autonomy.

Story 2: “We went headless. Revenue dropped.”

A potential client had launched a Hydrogen-based headless e-commerce site. Six months later, revenue was down significantly.

They expected that headless would automatically improve SEO, performance, and flexibility. Headless can help with these, but it doesn’t guarantee results.

In this case, the new site failed to deliver:

• Proper planning, which led to unstructured, poorly thought-out development
• Content management was difficult (so teams struggled to operate the site)
• Redirects were likely missed or under-specified (so users landed on 404 pages)
• Search visibilitydropped, and revenue followed

This wasn’t “headless is bad.” It was a clarity gap: goals and constraints weren’t turned into a delivery plan that protected the things that mattered (like redirects, measurement, and operating workflows).

What Discovery is (and isn’t)

Discovery is how we reduce complexity when things aren’t clear yet.

It’s how we turn “we think we need X” into “we know what we’re solving, what constraints we’re working with, and how we’ll deliver safely.

Discovery is not

• Finalising every requirement upfront
• Locking scope as a to-do list
• Designing every page in detail

Discovery does give you

• Decision guardrails (what we optimise for, what we won’t)
• Clear goal and success measures
• Assumptions & risks register
• Integration map
• Architecture options + recommendation
• A delivery plan (phases, milestones, team shape)

The 5‑Question Clarity Test (before you commit to build)

1) What user goal are we enabling specifically?

Not “modernise.” Not “make it flexible.”

A real user goal you can prioritise around.

2) What does success look like and how will we measure it?

If you can’t measure it, you can’t steer it.

3) What constraints are real (and non-negotiable)?

Focus on the things that usually create surprises:

• Critical user journey: Booking/conversion/checkout (happy path + key edge cases)
• Integrations: Systems of record, data ownership, data flow, failure handling
• Governance/approvals: Who can publish, who approves, release constraints
• Content operations: Who owns content, how it’s managed, what changes often

4) What decisions and boundaries have we explicitly agreed?

This is where “flexible” becomes real.

Example (ecommerce):

• Decision: Phase 1 prioritises a stable, high-converting checkout.
• Boundaries:
• Yes: guest checkout + saved addresses
• Not in Phase 1: subscriptions, bundles, multi-currency
• Personalisation: simple merchandising rules only (not per-user personalisation)

Example (multi-team / multi-locale):

• Decision: One platform, local teams can publish independently.
• Boundaries:
• Local teams own local pages and promos
• Global components/templates are centrally controlled
• Shared content is reusable by default; exceptions need a reason

These aren’t to-do lists. They are the explicit choices that stop wasted effort and rework.

5) What’s the delivery path that reduces risk earliest?

A good plan tests the hardest parts first, usually integrations, governance, and the critical journey, so you don’t find out too late that something doesn’t work.

Three “expensive sentences” to challenge early

• “We can always refactor later.”
• “Let’s pick the platform first, then we’ll know what’s possible.”
• “Just copy what we have now, but better.”

Each one delays key decisions until the build is underway, when change is more costly.

A practical next step

If you want a low-friction way to reduce complexity before the build, start with the 5‑Question Clarity Test and use it to align stakeholders on:

• the goal,
• how success is measured,
• the real constraints (especially integrations, governance, and checkout/booking),
• the explicit decisions/boundaries,
• and a delivery path that de-risks early.

They go wrong because we start building before we agree on what we’re building, why, and what has to be true for it to work.