10 things to prepare before your first call with a web developer

The most useful thing you can do before your first call with a web developer costs nothing and takes an evening: get these ten things in order first, so the call is about your project instead of extracting basic information a form could have collected.

None of this replaces vetting the developer themselves. It just means the conversation moves faster once you've found someone worth talking to.

1. A realistic budget range, not a number you're hoping to be talked down from

Quotes for the same brief can vary widely between developers, and a lot of that gap disappears once you can state a real range instead of hoping someone reads your mind. You don't need an exact number, "somewhere between X and Y" is enough to filter out mismatches before either of you wastes an hour — see our own pricing page for what a realistic range looks like at different tiers.

2. The pages your site actually needs

Walk in with a rough page list, not a vague "a website." Our page checklist covers the ones that cover almost any small business — even a rough version of that list turns a vague first call into a scoped one.

3. Two or three examples of sites you like, and why

Two or three sites you genuinely like, not necessarily competitors, say more about your taste in five minutes than a long verbal description. Say specifically what you like about each: the layout, the tone of the copy, the colour palette, the way it's organised. "I like the vibe" gives a developer nothing to work from.

4. Your brand assets — logo, colours, fonts, whatever exists

If you already have a logo, brand colours, or fonts, bring them, even if they're rough. If you don't, say so upfront — it changes whether design work needs to start from the brand or from the site.

5. Who owns your current domain and hosting

Know who owns your current domain registration and, if you have an existing site, who has access to the hosting account. This sounds administrative, but it's the single most common thing that stalls a project for weeks: the account is registered to a previous developer, an employee who's since left, or nobody remembers the login.

6. Who your site is actually for

"Everyone" is not an audience. Whoever your actual customer is, a specific type of business, a specific kind of household, a specific budget range, shapes tone, layout, and even which pages matter most.

7. The one thing the site has to accomplish

Pick the single outcome the site has to drive: bookings, quote requests, phone calls, purchases, applications. Sites that try to do everything with equal emphasis tend to do the one thing that actually matters for the business worse than a site built around it deliberately.

8. Whether the content and copy exist yet

Copy and content are usually the actual bottleneck on a project timeline, not the build itself. Know honestly whether you have real photos and written copy ready, whether you need it written for you, or whether you're planning to write it during the project, each answer changes the realistic timeline.

9. Who has final say

If more than one person needs to approve the design, know that going in and say so. A project that needs sign-off from someone who wasn't on the original call is where scope creep and delayed feedback usually start, our guide to stopping scope creep covers the pattern in more detail.

10. Your real timeline, including any hard deadline

Give a real timeline, including any date that's actually fixed: an event, a launch, a season. "As soon as possible" tells a developer nothing about how to sequence the work; a real deadline, even a loose one, lets them tell you honestly whether it's realistic.

What if I don't have all of this ready yet?

Missing two or three of these isn't disqualifying, a good developer will ask for what's missing. But showing up with none of it turns the first call into an intake form instead of a conversation about your project, and you'll likely need a second call just to cover ground this list would have handled in advance.

Should I ask about page speed and Core Web Vitals on the first call?

It's worth asking what the developer does by default for image optimisation and Core Web Vitals, since these are the metrics Google surfaces across its own tools as the real measure of user experience [1], and they're far cheaper to build in from day one than to retrofit after launch.

Is it worth asking how they'll measure success after launch?

Yes, ask whether analytics gets set up on day one or added later as an afterthought. GA4's own reporting exists to answer exactly the question you'll have three months post-launch, is this working, and it only has useful data if it's been running from the start [2].

What should I ask about how they'll get the site found in search?

Ask whether they'll connect Search Console before or after launch. It's free, it's the only place that shows you the actual search queries and click data Google has for your site, and setting it up on day one means you have a real baseline the moment the site goes live [3].

Do I need to think about a privacy policy this early?

If your site will have a contact form, bookings, or payments, yes, even briefly. The FTC's own small-business guidance treats how you handle customer data as a business responsibility, not just a legal footnote, and it's easier to plan for from the start than retrofit once the form is already live [4].

Does any of this matter if I'm changing platforms or domains later?

It matters more, not less. Google's own guidance on site moves assumes you already control your domain and hosting, which is exactly the account access point 5 above is about, without it, a future migration means starting from scratch on access before the actual technical work can even begin [5].

None of this replaces the vetting you should be doing on your side too, our guide to vetting a developer covers what to check before you commit. Coming prepared just means the first call is spent on the actual project instead of information either side could have gathered beforehand. And organising a page list at all leans on the same logic Google gives for site structure generally: group what's related, and make it easy to find [6].