A web developer first request after signing the contract is usually some version of “send me everything.” That phrase is shorthand for a long list of materials that the developer needs in order to do the work, and the speed at which the project moves is almost entirely determined by how complete that list is on day one.
Most clients send a small fraction of what is actually needed, then send the rest in pieces over the next several weeks as the developer asks for it. Each missing piece pauses the project until it arrives. The cumulative effect of those pauses is the difference between a project that finishes on time and one that drifts past its estimate.
A Clear Statement of Purpose
The first thing to provide is a clear statement of purpose. Not a description of the business, but a description of what the website is supposed to accomplish. What action should the visitor take? Who is the visitor? Why are they on the site? A developer can build any structure, but the structure that gets built is determined by the answer to those three questions. Without them, the developer guesses, and the guess is rarely right.
Brand Assets
The second is brand assets. Logo files in the original vector format, not screenshots or low-resolution exports. Color codes, ideally in HEX or RGB. Font choices, including any licensing details. If a brand guideline document exists, send the whole thing. If it does not, send whatever has been used consistently in the past so the new site matches the rest of the business.
Photography
The third is photography. Not “we will take photos later.” Final photos, ready to use, in usable resolution. If photos do not exist, the project needs a photographer before it needs a developer. A site cannot be designed around content that has not been produced. Stock images can fill some gaps, but they communicate something specific about the business — usually that the business is generic — so they should be used carefully and intentionally.
Written Content
The fourth is written content. Page by page, in roughly final form. The home page. The about page. Each service or product page. The contact page. Headlines and subheadings included. Calls to action specified. The content does not have to be perfect, but it has to exist. Designing around blank text creates layouts that fail when real text arrives, because the volume and rhythm of real content is different than the volume and rhythm of placeholder text.
Reference Examples
The fifth is examples. Sites the client likes. Sites the client does not like. The reason for each preference. “Make it look like this” is more useful than “make it look professional” because preferences are specific even when clients cannot articulate them. Three or four reference sites with notes about what works in each saves the developer from designing in the dark.
A List of Integrations
The sixth is a list of integrations. What email platform sends marketing emails. What CRM stores leads. What scheduling tool books appointments. What payment processor handles transactions. What analytics tools track behavior. Each integration has its own setup requirements, and each one needs credentials, account access, or configuration that depends on the client decisions. Sending the list early gives the developer time to plan around them. Sending it late forces last-minute scrambles.
Account Access
The seventh is access. Domain registrar login. Hosting login if the site is moving to existing hosting. Email account credentials if email forwarding is needed. Any existing site logins if content is being migrated. These are usually handled badly because owners do not have the credentials organized, do not know who has them, or are uncomfortable sharing them. Resolving access issues during the project itself is one of the most common sources of delay.
A Single Decision-Maker
The eighth is the decision-maker. Not the assistant, not the partner, not the friend who is good with computers. The person who has authority to approve the design, the content, and the launch. Projects with one clear decision-maker move faster than projects where decisions get debated by committee. The developer needs to know whose feedback is final and whose is advisory.
A Real Timeline
The ninth is a timeline. Not “as soon as possible.” A specific target launch date, or at least a window. The developer plans around the timeline. The client should plan around it too — including blocking time for feedback, content review, and testing during the relevant weeks. A timeline without committed client time is not really a timeline.
A Real Budget
The tenth is a budget. Not the comfortable budget. The actual budget, including the buffer for the things that always come up. A developer working with realistic numbers can scope appropriately. A developer working with a number that the client knows is unrealistic ends up either cutting the scope mid-project or asking for more money at the worst possible moment.
What Clients Should Not Provide
There is also a list of things clients should not provide, because providing them slows the project down. Detailed instructions about how to build the site. Fully designed mockups created in tools that are not the developer. Lists of plugins to install based on something an article recommended. The developer value is in knowing how to build the thing. Telling them how to do it usually creates more work to undo than it saves.
The Phase With No Visible Output
The right way to think about the discovery phase is that it is the most important phase of the project, even though it is the one with no visible output. A project with a thorough discovery phase finishes on time, on budget, and with a result that matches what the client expected. A project that skips discovery and tries to figure things out as it goes finishes late, over budget, and with results that surprise everyone — usually unpleasantly.
The materials listed above are not a wish list. They are the minimum required for a project to proceed without constant interruption. A client who sends them all in the first week sets the project up to succeed. A client who sends them in pieces over months gets a project that takes months — and pays for the difference whether or not the developer invoice reflects it.