Hoe een project te faseren zodat de drie pijlers elkaar versterken in plaats van met elkaar te concurreren

The short version: sequence a project foundation first. Build accessible, semantic structure before anything else, because it is cheap to include and expensive to bolt on later. Then design for conversion on that clean structure. Then let visibility and growth compound on both, permanently, not as a final phase. Real projects bend this order. The default rarely fails you.

Let me walk you through why the order matters as much as the work itself.

Why does the order you build things in matter as much as what you build?

Every project I have run taught me some version of the same lesson. Do a thing in the wrong order, and you do not just lose time. You pay for the same work twice, once badly and once properly, and the second pass is always more expensive than if you had done it right the first time.

Accessibility is the cleanest proof of this I know. Tim Springer, chief executive of the accessibility firm SSB BART Group, told the Wall Street Journal that retrofitting an existing site for accessibility runs about 10 percent of total website costs, versus 1 to 3 percent when it is phased in as part of natural upgrades (Wall Street Journal, via Rik Williams, to re-verify). Deque, citing IBM's defect-cost research, puts a sharper number on the same idea: a single accessibility complaint that would cost about $100.50 to fix during design can cost roughly $10,050 to fix once the product is already in production, a hundred-fold difference (Deque, to re-verify). Different studies, same shape. The earlier a foundational decision gets made, the fewer things are already built on top of it, and the cheaper it is to get right.

This is not a rule unique to accessibility. It is true of any foundational layer: information architecture, content structure, page templates. Fix a heading hierarchy after fifty pages have been written against the wrong one, and you are not editing headings. You are re-editing fifty pages. Sequence is not a scheduling preference. It is a cost decision, made whether you notice it or not.

What is a sensible default sequence for the three pillars?

Here is the order I default to, and the reasoning behind each stage. Think of it less as three separate projects and more as three layers, each one resting on the layer built before it.

1. Foundation, accessibility, and semantic structure. Clean information architecture, real heading hierarchy, landmark regions, keyboard support, color contrast built into the design tokens from day one, alt text and focus order treated as part of the build, not a pass at the end.
2. Conversion architecture. Clear goals per page, a defined primary action, message hierarchy that leads somewhere, forms and flows that remove friction, measurement wired in before launch, not after.
3. Visibility and ongoing growth. Content, technical SEO and AEO, distribution, and the compounding cycle of publishing, measuring, and refining, which never actually finishes.

Why does accessible, semantic structure come first?

Two reasons, and they reinforce each other.

The first is the cost argument above: structural decisions are the ones every later decision depends on, so they are the most expensive to unwind. A heading hierarchy, a landmark region, a focus order: these are not surface polish. They are the skeleton everything else attaches to.

The second reason is one people miss. The same semantic structure that makes a page usable with a screen reader is what search engines and AI answer engines read to understand the page at all. MDN's own guidance on accessible HTML makes this point plainly: proper semantic markup is what lets both assistive technology and machine crawlers understand a page's structure and meaning (MDN, to re-verify). You are not doing accessibility work and SEO work. You are doing one piece of structural work that both disciplines happen to read. Build it once, correctly, and you have quietly done two jobs.

Why does conversion architecture come next, and not first or last?

Because visibility without somewhere clear to land is a waste of traffic, and conversion clarity is what makes that traffic worth anything.

I have watched this play out on real redesign projects: teams pour effort into a site that looks sharper, launch it, and the conversion rate does not move, because the problems were structural, not aesthetic, and nobody defined what "convert" even meant on each page before the redesign began (Webfor, directional, to re-verify). A beautiful page with no defined action is not a conversion asset. It is a brochure.

So conversion architecture comes second, not first, because it needs the foundation underneath it: clean structure means a form field's error message is announced properly, a call-to-action is reachable by keyboard, a page's hierarchy actually guides attention rather than fighting the browser's default reading order. And it comes before visibility, not after, because sending a flood of new visitors at a page that does not know what it wants from them just produces more people leaving unconverted, faster.

Why does visibility come last, and why does it never actually finish?

Visibility is the layer that compounds, which is exactly why I put it last in the build and never let it end.

Reasoned from principle: you cannot learn what is working until you have enough real behavior to learn from. Rigorous A/B testing, for example, typically needs a real volume of visitors and conversions before a result is trustworthy rather than noise (Invesp, to re-verify). Visibility is what generates that volume. Without it, conversion optimization is just opinion dressed up as strategy. With it, every visit becomes a data point that sharpens the next conversion decision, which in turn makes each visit more valuable, which makes the next unit of visibility worth more than the last. That loop is the compounding effect the whole studio is named for. It only turns once the first two layers are solid enough to hold the traffic visibility sends.

This is also why visibility is not a phase you complete and move past. Build and Grow keep feeding each other for as long as the project lives.

Real projects flex. Here is when the sequence bends.

I want to be honest with you about this, because a rule that pretends reality never intrudes is not a useful rule.

The site already has traffic and a weak foundation. Do not wait for a full rebuild before touching conversion. Patch the worst accessibility and structural gaps in parallel with quick conversion wins, then schedule the proper foundation pass before the patches accumulate into their own mess.

A deadline forces parallel tracks. Foundation and conversion architecture can genuinely run side by side if the same person is holding both threads and watching for the moment one is building on assumptions the other has not confirmed yet.

One pillar is already strong. A client with rigorous accessibility already in place and a weak conversion story does not need to redo stage one. Start where the actual gap is. The sequence describes where value compounds best from a standing start, not a checklist every project must run in full.

The order is a default because it is where I have seen the least rework, not because reality always cooperates. Know why you are deviating, and you are sequencing on purpose instead of just improvising under pressure.

How does one owner keep the thread across Discover, Build, and Grow?

This is the part a handoff cannot do, and it is the real argument for one person owning the whole arc.

A specialist who owns only Build has no reason to build conversion architecture with Grow's future needs in mind. A specialist who owns only Grow inherits whatever structure Build left behind and has to reverse-engineer the reasoning before they can improve it. Every handoff is a small act of forgetting, and the next owner pays to relearn what the last owner already knew.

One owner across Discover, Build, and Grow does not have that gap. The information architecture gets built already anticipating the content that Grow will need to slot into it. The conversion flows get instrumented with the exact events the growth work will later analyze. Nothing gets built twice because nobody had to guess what the next phase would need. The sequence holds not because it is written down, but because one mind is carrying it from the first decision to the fiftieth.

Your turn

Take a project you are running right now, foundation, conversion, or visibility, and ask where it actually sits. If you are pushing visibility work on a page whose primary action is not defined, stop and define it first. If you are polishing conversion copy on a page with a broken heading hierarchy, fix the hierarchy first, it is cheaper today than in six months. The sequence is not a rulebook to memorize. It is a question to keep asking at the start of every stage: what does this stage assume is already true, and is it actually true yet.