Website Project Intake Checklist: What to Ask
Everything a typical website project needs from the client, grouped by category, with a short reason for each item and whether it can wait until after kickoff.
How to use this checklist
This is a reference list, not a script — cut anything your project does not need and add anything specific to it. Every item below carries two things: a one-line reason it matters, and a rough call on timing, because not everything belongs in the same request.
Before kickoff means the project cannot really start without it, or starting without it means redoing work later. Can come later means you can begin with a placeholder or a sensible default and swap in the real thing once it arrives, without losing time. Getting this split right is most of what makes an intake request feel reasonable instead of overwhelming — a list of twelve things due tomorrow reads very differently from four things due tomorrow and eight that can follow over the next two weeks.
If you want the process this checklist plugs into — how to phrase the request, how to follow up, how to handle the items that never come back — see how to collect documents and files from clients.
Identity and brand
| Item | Why you need it | Timing |
|---|---|---|
| Logo file (SVG or high-res PNG) | A screenshot or a resized JPEG will not scale cleanly to a favicon, a retina header, or print. Ask for the source file, not an export someone made for a slide deck. | Before kickoff |
| Brand colors (hex codes if they have them) | Guessing colors from a screenshot introduces drift the client will notice even if they cannot articulate why. If they do not have hex codes, a phone photo of something branded (a sign, a business card) is enough to sample from. | Before kickoff |
| Typography preference, if any | Most small clients do not have a defined typeface and are fine with your recommendation — but ask, rather than assume, if they already use a specific font on printed material. | Can come later |
| Existing style guide or brand book | Rare below a certain company size, but when it exists it settles a dozen small decisions (logo clear space, color usage, tone) that would otherwise be a back-and-forth. | Can come later |
Content
| Item | Why you need it | Timing |
|---|---|---|
| Homepage headline and intro copy | The single piece of text most likely to hold up a launch if it is missing, because it is also the hardest for a client to write — ask for it first and expect it to need a revision round. | Before kickoff |
| Secondary page copy (about, services, etc.) | Structure and layout can proceed with placeholder text, but final copy changes line counts and section heights, so build it in once it exists rather than treating it as a drop-in swap at the end. | Can come later |
| Photos (with a minimum count and resolution stated up front) | A phone photo at full resolution is almost always fine; a photo already resized for a Facebook post usually is not. State the minimum width in the request instead of finding out after upload. | Before kickoff for hero/key photos, later for the rest |
| Team bios and headshots | Needed for an about or team page, rarely for the homepage — usually safe to leave for a later round. | Can come later |
| Testimonials or reviews | Real client language outperforms placeholder copy by enough that it is worth a specific ask ("can you paste your three best Google reviews") rather than a generic "any testimonials?" | Can come later |
| Video or other media assets | Often the last thing ready and the most negotiable — confirm whether the project actually needs it before treating it as a blocker. | Can come later |
Technical access and integrations
| Item | Why you need it | Timing |
|---|---|---|
| Current website admin login, if one exists | Needed to migrate content, redirect old URLs, or simply see what is there before replacing it. Ask for this as a credential, not a document — see the note on handling logins below. | Before kickoff |
| Domain registrar access or DNS delegation | Launch day depends on this. Finding out the client does not have their own registrar login (an old developer registered it for them) two days before launch is a common and avoidable delay. | Before kickoff |
| Hosting account access, if the project keeps existing hosting | Same reasoning as the registrar: confirm access exists before you need it, not when you need it. | Before kickoff |
| Analytics tracking ID (e.g. Google Analytics) | Nice to wire in from day one, but a site can launch and collect a data gap of a few days without lasting damage — not worth delaying launch over. | Can come later |
| Email marketing or CRM integration details | Usually a later-stage connection (newsletter signup, form routing) rather than a structural requirement of the site itself. | Can come later |
| Third-party booking, payment, or scheduling accounts | If the site's core function depends on one of these (a restaurant's reservation system, a shop's payment processor), treat it as a launch blocker, not an integration to add later. | Before kickoff if launch-critical |
Credentials deserve a different handling path than everything else on this list. A password sitting in an email thread is a standing liability, not a filed document — it stays readable in every backup of that inbox indefinitely. Collect logins somewhere built for a one-time handoff rather than in the body of a message; BriefGate's secrets vault encrypts a submitted credential and releases it once, to the person who asked, which is closer to how a password should travel than an email ever is.
Legal and business
| Item | Why you need it | Timing |
|---|---|---|
| Business name, address, and contact details exactly as they should appear | Small inconsistencies (a slightly different phone number in the footer versus Google listings) hurt local search and look sloppy. Get the exact, current version rather than assuming last year's version is still right. | Before kickoff |
| Opening hours, service area, or other operational facts | These are facts about the business, not design decisions, and only the client can supply them correctly. | Before kickoff |
| Pricing or service packages, if shown on the site | Ask whether this is meant to be public before designing a page around it — some businesses deliberately keep pricing off the website. | Before kickoff if the site will show it |
| Privacy policy and terms of service | These carry legal weight and should come from the client or their lawyer, not be invented on their behalf, especially for a site that collects any personal data. | Can come later, but before launch |
| Industry-specific disclosures (health, finance, legal, alcohol) | Requirements vary by sector and jurisdiction; flag early that this is the client's responsibility to confirm, not a default template will not cover it. | Before kickoff for regulated industries |
| Sign-off on who has authority to approve the final site | On any project with more than one stakeholder, confirm this once at the start rather than discovering a second decision-maker after launch. | Before kickoff |
Where BriefGate fits
Turning this checklist into an actual request is the part most tooling skips: someone still has to send it, track what came back, chase what did not, and keep the credentials rows separate from everything else. BriefGate exists for that step. An AI coding agent — or you, from the dashboard — declares this list as typed items with the constraints above baked in (minimum image width, required versus optional, a schema for structured facts like opening hours), and BriefGate generates one branded client portal, sends the reminders on a schedule you choose, and hands back validated data instead of a folder of mismatched files and a stalled email thread. The restaurant, advisor, and club website templates cover a version of this exact checklist pre-built for those three project types, so a recurring project type does not mean rebuilding the list from scratch each time.