Bring your own checklist: import a build process from a spreadsheet

The launch and migration projects were built around a checklist we wrote for you — a sensible default list of pre- and post-launch tasks, ready to tick off. That works beautifully when our list matches your work. But plenty of people already have a list. It’s the one they’ve refined over a hundred builds, that lives in a spreadsheet, and that they trust because it’s caught real mistakes. Asking those people to abandon their process and adopt ours is the wrong trade.

So this release does the opposite. Custom projects take the spreadsheet you already have and turn it into a tracked, shareable checklist that lives next to your crawl — your steps, your wording, your phases. You bring the process; the toolkit gives it a home.

The process you already trust

Most studios don’t build a website from memory. There’s a document somewhere — a Google Sheet, an Excel file, a Notion board exported to CSV — that lists everything a build runs through before it’s ready to go live. Scoping and the kick-off call. Wireframes and design sign-off. Copywriting and proofreading. Image sourcing, cropping, compression, alt text. Building the templates, entering the content, wiring up forms and analytics. The QA pass across desktop, tablet and mobile.

That document is your build process. The problem is that a spreadsheet can’t do anything except sit there. It doesn’t know which site it belongs to, it can’t be shared with a client without handing over an editable file, and ticking a cell is the full extent of its ambition. The knowledge is good; the tool around it is a flat grid.

Import it, don’t rebuild it

From a crawl’s results page there’s a new button: Import custom project. You pick your spreadsheet, and the toolkit reads it into a real project — the same working surface the launch and migration checklists use, with the same tick-off, filtering, hiding, reordering, and the same private edit link and read-only share link for the client.

The format is deliberately simple, because it’s the format the toolkit already exports. Each worksheet becomes a tab. The first three task sheets become your project’s three tabs, and their names become the tab labels — so “Scoping & Design”, “Content & Images” and “Build & QA” come through as exactly those tabs, not a generic “Pre/Post”. Each row needs three columns: a Category, a Group, and the Task itself. That’s it.

Why it lives next to the crawl

A checklist in a generic tool is an island. A checklist in Website-Toolkit sits beside the audit of the actual site — the broken links, the missing tags, the pages the crawler found. That’s the whole idea behind the toolkit: the tool that finds a problem is the tool that tracks the fix. A custom project inherits that context for free. Your hand-built “check every page loads” step now sits in the same place as the crawl that can tell you which ones don’t.

And because a custom project is a first-class project, it shares everything the others have: the read-only share link so a client can watch progress without being able to change anything, and a one-click Excel export so your checklist can leave the same way it arrived.