How to sequence a project so the three pillars compound instead of compete
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.
10%
cost to retrofit accessibility after launch (versus 1 to 3% to phase it in early)
Wall Street Journal, via Rik Williams
100x
more expensive to fix an accessibility defect in production than in design
Deque, citing IBM's defect-cost research
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.
- 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.
- 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.
- Visibility and ongoing growth. Content, technical SEO and AEO, distribution, and the compounding cycle of publishing, measuring, and refining, which never actually finishes.
| Stage | What happens | Why it sits here | What it hands forward |
|---|---|---|---|
| 1. Foundation and accessibility | Semantic structure, information architecture, keyboard and screen-reader support, contrast in the design system | Cheapest to build in, most expensive to retrofit, and every later layer is built on top of it | A page structure that is already legible to both people and machines |
| 2. Conversion architecture | Defined goals per page, clear primary actions, friction removed from flows, measurement wired in | A clean structure makes conversion decisions faster to make and cheaper to test, and there has to be somewhere for traffic to convert before you go earn more of it | Pages worth sending traffic to, and a baseline to measure against |
| 3. Visibility and growth | Content, technical SEO and AEO, distribution, ongoing publishing and refinement | Sending traffic to unclear pages wastes it, so visibility earns its return once there is something ready to receive it | Real traffic and behavior data that feeds back into sharper conversion decisions |
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.
Frequently asked questions
Accessibility and semantic structure first, because they are cheapest to build in and most expensive to retrofit. Conversion architecture next, because it needs that structure to work properly. Visibility and growth after that, and ongoing, because it needs somewhere worthwhile to send traffic before it earns a return.
Because every later decision gets built on top of it. Fixing a heading hierarchy or a focus order after fifty pages exist against the wrong one means redoing those pages, not just the structure. Research cited by Deque, drawing on IBM's defect-cost studies, found fixing an accessibility issue in production can cost around a hundred times more than fixing it at the design stage.
After, in the default sequence. Sending traffic to a page with no clear conversion goal wastes that traffic. Once conversion architecture is in place, visibility work has somewhere worthwhile to send people, and the resulting traffic then supplies the real behavior data that makes further conversion optimization trustworthy rather than guesswork.
Do not wait for a full foundation rebuild. Patch the worst structural and accessibility gaps alongside quick conversion fixes, then schedule the proper foundation pass before the patches pile into their own problem. The sequence is a default for a standing start, not a rule that ignores where a project already is.
Sometimes, if one person or team is holding all three threads and watching for the moment one track builds on an assumption the other has not confirmed. Without that coordination, parallel work usually means rework, because each track quietly assumes the others are further along than they are.
Each new owner starts by relearning what the last owner already understood. A specialist who only owns Build has no reason to anticipate what Grow will need. A specialist who only owns Grow inherits a structure they have to reverse-engineer before they can improve it. One owner across the whole arc carries that context forward instead of losing it at every handoff.
No. It is the order that produces the least rework from a standing start, not a rule every project must follow rigidly. A project that already has one pillar solved should start at its actual gap, not restart from stage one out of habit.
Chasing visibility before conversion architecture exists. It produces the worst kind of failure: more traffic hitting the same unclear page, which looks like progress on a dashboard while the underlying problem gets worse, not better.
The same semantic markup that makes a page usable with a screen reader, real headings, landmark regions, described links, is what search engines and AI answer engines read to understand the page. It is one piece of structural work read by two different audiences, not two separate jobs.
Ask what the current stage assumes is already true, and check whether it actually is. If conversion work is underway on an undefined information architecture, or visibility work is underway on pages with no clear action, that is your actual starting point, regardless of what phase the calendar says you are in.