Website Development Template
A phase-based board for a website build: discovery and design, build, QA, launch. Each phase gated by a sign-off instead of a guess about readiness.
A page doesn't enter Build until a design is signed off, not "roughly agreed in a call."
Why website builds stall between phases
A website build has a shape most project work doesn't: distinct phases that genuinely depend on each other, followed by a client who is not in the tool checking progress from outside it. Most templates ignore both, and get built instead for ongoing product work where nothing is ever really "finished." That's a poor fit for a project with a fixed set of pages and a hard launch date.
Design and build overlap without anyone deciding they should. A developer starts building a page whose design isn't finished because the backlog didn't distinguish "designed" from "ready to build," and the rework that follows is blamed on the developer.
Client sign-off happens in email, not on the board. Approval for a page lives in a thread nobody else can see, so the team can't tell whether "approved" means the client glanced at it or genuinely signed off, and disputes about scope later have no clean record to settle them.
QA is squeezed to whatever time is left before launch instead of being a phase with its own space on the board, so it either doesn't happen or happens after the client has already seen the bugs.
Content and copy arrive later than the pages that need them. A page reaches Build with placeholder text because copy was never tracked as its own dependency, so "the page is built" quietly comes to mean something less finished than it sounds.
Agencies feel this hardest, because the client relationship compounds every one of these problems: an overlap between design and build reads as unprofessional rather than a process gap, an unclear sign-off becomes a billing dispute, and squeezed QA becomes a bug the client finds instead of one the agency caught first. A template that makes each phase and its exit condition explicit protects the agency as much as it protects the schedule.
The structure, and why each part is there
Discovery & design, Build, QA & review, Launch-ready. A page moves left to right through its own lifecycle rather than sitting in one undifferentiated "in progress," and the column a page is in tells you something real about what's left to do on it.
A cap on how many pages can be under active build at once, so half-built pages don't pile up while the team waits on content or images for each of them. A smaller number of finished pages beats a larger number of stalled ones.
Each page carries a sign-off checkbox before it can move from design into build, and again before it can move into launch-ready. Approval is a recorded state, not an inference from silence.
The built-in wiki holds the reasoning behind layout and copy calls next to the page itself, with page history, so "why did we cut that section" has a real answer six weeks later.
Pages are scheduled against who's actually available for design and dev work that week, with approved leave accounted for, not against a headcount that assumes everyone is free. That's how a four-week estimate quietly becomes six.
Nothing reaches this column without QA and sign-off both complete, so "ready to launch" means the same thing every time it's said, rather than shifting depending on who's asking.
Copy is treated as its own dependency per page, not assumed to arrive alongside the layout, so a page missing final content is visibly incomplete instead of quietly marked as built.
How to use it
- 01List every page before you design any of them. A sitemap the board can track beats a design file the board can't see into, and it surfaces the total scope before anyone's committed to a build timeline for it.
- 02Don't let a page enter Build without a signed-off design. This is the rule teams break first and regret most.
- 03Set the build limit to what your dev capacity can actually finish in a week, not to how many pages are designed and waiting.
- 04Give QA its own column and its own time, rather than treating it as the last two days before launch. A bug found here is cheaper than the same bug found by the client after the site is live.
- 05Log the client sign-off on the card, with a date, instead of trusting that the email thread will still be findable later.
- 06Track copy as its own item per page, separate from the build task, so a missing paragraph is visible before the page reaches QA.
The four phases don't have to map to four calendar weeks. A one-page microsite might move through all of them in three days; a twelve-page corporate rebuild might spend a month in Build alone. What stays constant is the gate between phases. A page doesn't advance until its own conditions are actually met, regardless of how long that takes.
Delivery forecasts get more useful once a few pages have moved end to end, because they're calculated from how long pages actually took to clear each gate rather than from the original estimate in the proposal. That's often the first honest signal a team gets that the timeline needs adjusting, well before the client has to ask why launch is slipping.
- Design and build are separate phases with a real gate between them, not one continuous blur
- A build limit stops half-finished pages from piling up while content is chased
- Sign-off recorded on the card beats sign-off buried in an email thread
Common questions
No. That one is a sprint-based board for ongoing product work, a backlog that never really empties. This one is phase-based (discovery, build, QA, launch), built for a project with a defined end date and a client sign-off step, which a website build usually has and a product backlog usually doesn't. Use this one for the build; switch to a general dev board afterward for ongoing maintenance if the site needs it.
Yes, clients can be added as users to see progress and leave sign-off on their own pages, which keeps approval on the board instead of scattered across email.
Most teams do, since post-launch work is usually ongoing fixes and small requests rather than a phased build. See the product overview for the other templates available in the same workspace.
Nothing to start with. It's part of the Free plan, covering up to five users and two projects, no expiry date attached. See pricing for what a paid plan adds once a build needs more than five people on it.
That's up to the workspace admin. Client access can be removed once launch-ready sign-off is complete, or kept if the same client will need it for future projects. Admin actions like removing a user are logged either way.
Related pages
See it on your own work.
A workspace your whole company will actually use is 60 seconds away. No card, no risk, nothing to install.
14-day full-access trial · sample project included · no card required