How we run website builds from now on: one structure for every build, gates you can trust, blockers that surface themselves, and estimates that learn. The pilot is live on Marcel Method Orthodontic Specialists — every example in this doc is real, pulled from our own Asana this week.
This isn't criticism of the work — the sites are good. The problem is the system around the work made truth expensive: finding out where a build stood meant reading, asking, and remembering. We audited 18 of our own projects from 2021–2026 before designing this. Receipts below.
Everything for one client — SEO, Ads, Creative, Video, Rebrand, and the post-launch Website Requests queue. Keeps all of it; only the build moves out, leaving a link.
Where build work happens. One section per launchable build (Marcel has two: custom site + interim migration) plus a Punchlist section.
The pipeline. One control row per build — same rows you know, now carrying real fields instead of hand-typed notes. Group by Phase and it sorts itself.
Holds the build projects. Its Dashboard tab charts every task across every build — hours by phase, blocker-days, punchlist sources. The cross-build view nothing else can give.
Each phase is one parent task. Its done gate lives in the task description — the objective definition of finished. Between phases, the thing that changes hands is named below: if the artifact isn't ready, the handoff didn't happen.
Estimates aren't gut-feel anymore: they're computed from the page inventory using rates per page type, plus per-phase formulas. Then reality gets logged, and the rates get corrected. That loop is the whole point.
The inventory classifies every page on two axes: template type (drives design/dev effort) and copy type (drives writing effort). Marcel: 25 content pages + blog hub + 4 thank-you pages.
Rates × counts = role estimates. Copy rates per page type (see panel), design as a per-concept formula, dev as setup + per-template + per-page load. These land on the control row: Marcel = 24.1h copy · 10h design · 44h dev.
Per-phase formulas cover the rest: 02 = base + per-page · 05 = per revision round · 07 = base + per-page + per-form · 08 = base + handoff. Each phase task carries its estimate.
You track time with the built-in timer ▶ — hit play on the task or subtask you're actually working, pause when you stop. Time tracked on subtasks rolls up into the phase task natively, so the reporting layer stays true without anyone copying numbers. Estimating at the subtask level is supported too — estimate where the work is real.
Retro closes the loop. At launch, actual-vs-estimate per phase recalibrates the rates. Every build makes the next estimate more honest.
Built 6/10 from the real state of the build. Completed phases came over as completed — and the system made its first two catches on day one, without anyone having to notice them.
| Field | What it means | Who sets it |
|---|---|---|
| Web Build Type / Phase | What it is · where it is (00–08, ⏸ On Hold, ✖ Cancelled) | Web lead at kickoff · then automatic |
| Brand status · Design-ready | The 00 gate pair — design can't start mid-rebrand by accident | Web lead/AM; the flip is the recorded decision |
| Page count · Est. hours ×3 · Content inventory link | Scope + role estimates, rolled up from the inventory (§04) | Set once at scoping |
| Client approval | Not sent → In review → Revisions → Approved for Dev (the 05 gate) | Web lead — this field is what unlocks dev |
| Blocker category + days | Content · Assets/Brand · Client · Access/DNS · 3rd Party · Internal — and what waiting costs | You, the minute you're stuck; days computed for you |
| Estimated time → Actual time ▶ | Asana's native pair: the budget vs. the timer. Subtask time rolls up to the phase automatically | Estimates at kickoff (or on your subtasks) · you just run the timer |
| QA escape source phase | On punchlist items: which phase let this through | QA, when logging a finding |
| Staging URL | One canonical link for all QA and review | Dev, when staging spins up |
The rule behind the rules: anything we want to report on is a task; subtasks are checklists. That one principle is why the dashboards work.
Why it matters: 27 of 57 active builds are blocked right now — and under the old way, each one was discovered by someone asking. The clock isn't surveillance: it's how we prove where time goes, what waiting costs, and which blockers deserve a process fix. Blocked time is the #1 thing this system exists to recover.
| # | When… | The rule… |
|---|---|---|
| R0 | Vertical is set | fills in Vertical fit for you |
| R1 | you set a Blocker category | flips status to 🚫 Blocked, notifies the web lead, starts the clock |
| R2 | you clear it to None | back to In Progress, clock stops |
| R3 | a phase completes | reminds you: check the gate honestly + log Actual hours |
| R4 | Client approval → Approved for Dev | notifies dev and kicks off scheduling |
| R5 | a task lands in Punchlist | marks it Needs Assignment — nothing sits untriaged |
| R6 | a due date is 2 days out | nudges the assignee |
| R7 | marker.io creates a feedback item | routes it into Punchlist automatically — client feedback becomes data, zero process |
Behind the rules, automation handles what rules can't: advancing the control row's phase, computing blocker-days, cascading dates when a milestone moves, the weekly pipeline digest, stuck-too-long flags, and the retro pack that recalibrates estimates after every launch.
Your tasks, your phase, the gates, the punchlist. Phase owners live here.
One row per build — now with real fields. Group by Web Build Phase and stage columns replace section-shuffling and Notes-reading.
Holds the build projects — its Dashboard tab charts tasks across every build at once.
Plain answer to the obvious question: control rows are never "in" the portfolio — they live in WPP and the build project. The portfolio contains projects; its dashboards read every task inside them. During the pilot the new columns aren't in WPP yet — they get attached on promotion day, so the team meets the new pipeline exactly once, fully formed.
The pilot is live on Marcel Method (private). It was built from the build's real state — completed phases came over completed, blockers came over blocked.
Rules go in and we hold this walkthrough. Bring questions — friction you spot now gets fixed before anyone else lives in it.
Promotion day: the pilot becomes Marcel's project of record, Web Project Priorities gets the new columns, and the dashboards turn on. You meet the new pipeline exactly once, fully formed.
Migration waves: the ~40 active builds move over one batch at a time, full history intact — comments keep their original author and date. Nothing is lost, nothing is retyped.
The template: every new build starts identical from day one — which is what keeps fifty projects reportable as one system.
It's different work, and less of it. You gain: one field when blocked, and a timer ▶ you tap while you work. You lose: status meetings about status, Notes-field archaeology, being asked "where's the build at," and re-typing dates nine times when a launch moves.
No — it's about fixing the estimates and proving where time goes. When a phase runs over consistently, we fix the rate or the process, not the person. Visible numbers are also your best defense when scope creeps: the hours argue for you.
It stays — same rows, same place. The rows just become trustworthy: real stage and blocker fields replace the four overlapping signals. Nothing changes for you until the pilot is promoted, and then it changes once, fully formed.
Active builds (~40) migrate in waves with full task history — comments carry their original author and date. The 997 completed rows stay where they are as history. Client hubs keep everything that isn't the build, including Website Requests.
The build goes ⏸ On Hold with a blocker category — visibly, clock running. When they return, dates cascade forward in one pass. No more zombie builds discovered years later.
Mostly nobody — that's the point. Automation advances the phase, rolls up blockers, counts the days. The web lead touches it at kickoff and at client approval.