What to Give a Web Developer Before Starting

Before kickoff a developer needs five things: your content (the words and the photos), your brand assets (logo files, fonts, colours), access (domain registrar, hosting, existing site admin, analytics), reference sites with reasons you like them, and one named decision-maker who can approve work. Have those ready and the project runs to schedule. Miss the first one and nothing else matters.

This is the last step before work starts, and it's the one that decides whether the timeline you agreed survives contact with reality. If you haven't chosen a developer yet, how to hire a web developer when you don't know how to code comes first.

Not sure what you actually need to prepare? Tell me what the site has to do and I'll send back a specific list for your project — free, before anything is booked. Get in touch.

1. Content — the words and the photos

Leading with this because it causes more delay than everything else on the list combined. The build finishes and then waits for copy, which is why projects sit at "almost done" for a month.

What's needed, per page: a heading, the body text, and any calls to action. Not polished — a plain document is fine. What matters is that it exists and says what you actually want to say.

If writing it yourself is unrealistic, say so before the schedule is agreed rather than three weeks in. Paying for copywriting costs less than a two-month stall, and a developer who knows the real position can plan around it. How long a website takes to build covers what this does to a timeline.

For photos: real ones of your work, your premises and your team beat stock every time, and on a local business site they're often the difference between credible and generic. If you don't have them, decide early whether you're commissioning a shoot or buying stock — that decision itself is frequently what stalls.

2. Brand assets

• Logo files — vector if you have them (`.svg`, `.ai`, `.eps`). A logo pulled off your old website at 200px wide will look soft on a modern screen, and nobody can fix that afterwards.
• Fonts, and the licence for them if they're not free. Web licences are separate from desktop licences, and this catches people out.
• Colour codes — hex values, not "our blue". If you have brand guidelines, that document answers most design questions before they're asked.
• Anything printed — signage, vehicle livery, business cards — so the site matches what your customers already recognise.

3. Access

Gather these early, because tracking down a login nobody has used since 2019 takes days, not minutes — and it's usually discovered in launch week.

• Domain registrar — the account where the domain is registered, ideally in your business name. Check with a WHOIS lookup if you're unsure.
• Hosting — control panel or cloud account, at owner level rather than a user seat.
• Existing site admin, if there is one, with an administrator-level account.
• Analytics and Search Console, so history carries across rather than restarting at zero.
• Any third-party accounts the site touches: email marketing, booking tools, payment gateway.

Add the developer as a user on accounts you own rather than handing over your own passwords — you can remove that access later without changing everything. If you can't produce some of these because a previous developer holds them, taking over a website from another developer covers recovery.

4. Reference sites — and why you like them

Three to five sites, and here's the part that matters: write one sentence per site saying what you like about it. A list of URLs is nearly useless. "I like how this one puts the phone number in the header and the pricing on the homepage" is a design brief.

Include a couple you actively dislike, with reasons. Knowing what to avoid saves a revision round, and revision rounds are the expensive part.

Competitors count, but don't restrict yourself to your industry — the best reference is often a business nothing like yours that solved the same problem you have.

5. Must-haves versus nice-to-haves

Write two lists and keep them separate. The must-have list is what the site fails without: the enquiry form, the service pages, the booking system. The nice-to-have list is everything else.

This does two useful things. It gives the developer a scope they can price honestly, and it gives you a lever when the budget or the timeline gets tight — because the negotiation becomes about cutting the second list rather than arguing about the first. It's also the document that makes comparing quotes possible, since everyone is pricing the same thing.

6. One named decision-maker

One person, named at kickoff, who can approve a design without convening a meeting. Collect other people's opinions before each review round and hand over one consolidated response.

Projects with three equal approvers don't run three times slower; they run at the speed of whoever is on leave. This is the cheapest scheduling decision available to you and it costs nothing.

What you don't need to provide

Worth saying, because this is where people stall out of a sense that they're not prepared enough:

• Wireframes or mockups. Designing it is the job you're paying for. A rough sketch is welcome if you have one; it is not expected.
• Technical specifications. You don't need to know what framework, CMS or hosting to use, and a developer who asks you to choose is passing you their job.
• A sitemap. Describe what your business does and who it serves; the page structure follows from that.
• Keyword research, unless you're commissioning SEO as a separate engagement.
• Perfect copy. Clear and complete beats polished. It gets edited anyway.

The pre-kickoff checklist

CONTENT
  [ ] Copy for every page (plain document is fine)
  [ ] Photos, or a decision: commission a shoot / buy stock
  [ ] Testimonials or reviews you're allowed to publish

BRAND
  [ ] Logo, vector if it exists
  [ ] Fonts + licence
  [ ] Colour hex codes / brand guidelines

ACCESS  (add me as a user; don't share your own password)
  [ ] Domain registrar
  [ ] Hosting / server
  [ ] Existing site admin
  [ ] Analytics + Search Console
  [ ] Third-party accounts the site uses

DIRECTION
  [ ] 3-5 reference sites, each with WHY
  [ ] 2 sites you dislike, with why
  [ ] Must-haves list
  [ ] Nice-to-haves list  (kept separate)

PEOPLE
  [ ] One named decision-maker
  [ ] Review slots booked in calendars

When you don't need to hire anyone

If working through that list makes it clear you have four pages of content, no bookings, no logins and nothing to sell online, then a site builder will genuinely serve you for a fraction of a custom build — and I'd tell you that rather than take the project. WordPress vs Wix vs a custom website covers where that line sits.

What I'd recommend

Do the content first and everything else follows. If you assemble only one item from this post before your kickoff call, make it the copy — it's the one nobody else can do for you, and it's the one that decides your launch date.

Frequently asked questions

What does a web developer need from me before starting?

Content for every page, brand assets (vector logo, fonts and licence, colour codes), access to your domain registrar, hosting, existing site admin and analytics, three to five reference sites with reasons you like them, separated must-have and nice-to-have lists, and one named decision-maker who can approve work without convening a meeting.

Do I need to write the website content myself?

Someone has to, and it's the most common reason projects run late. You can write it, hire a copywriter, or ask the developer whether they include it — but decide before the schedule is agreed rather than three weeks in. Paying for copywriting is usually cheaper than a two-month stall while a finished build waits for words.

Do I need wireframes or a design before hiring a developer?

No. Designing it is the work you're paying for, and a rough sketch is welcome but never expected. You also don't need to choose a framework, CMS or hosting — a developer who asks you to make those calls is handing you their job. What you do need is clarity about what the site must achieve in business terms.

What access does a web developer need to my accounts?

Domain registrar, hosting or server, existing site admin, analytics and Search Console, plus any third-party services the site touches. Add them as a user on accounts you own rather than sharing your own credentials, so access can be removed later without changing every password. Gather these early — hunting for a forgotten login is a launch-week problem.

How many example websites should I send a developer?

Three to five you like and two you don't, each with one sentence explaining why. The reasons matter far more than the list — "I like the phone number in the header and pricing on the homepage" is a usable brief, while a bare set of URLs leaves the developer guessing and usually costs a revision round.

Where to start

Copy the checklist above into a document today and start with the content section. Everything else on it takes an afternoon; that one takes as long as it takes, which is exactly why it should start first.

Want a version tailored to your project before you commit to anyone? Describe what the site has to do and I'll send one back. Get in touch, or see recent work.