Website Development Checklist: What to Prepare Before You Hire a Developer

The first website meeting goes better when you bring something more useful than a list of designs you like. A recent customer inquiry, a service description and a few examples of your work give the team a place to start. Before asking a developer to build anything, gather the information customers need before they can decide to contact you.

This website development checklist covers what a business should prepare before hiring a web developer: the task the site has to support, real content, access to your domain and accounts, a short brief, and a plan for who runs the site after launch. Most of it takes a few hours, and it changes the quotes you receive.

Short answer: before website development starts, prepare one clear goal for the site, draft content for your main pages, a feature list split into launch and later, access to your domain and other accounts, a budget range, and the names of the people who will approve the work and maintain the site afterwards. Put it on one page and send the same brief to every developer you ask for a quote.

The website development checklist at a glance

If you are wondering what to prepare before building a website, use this table as a website planning checklist before your first call with a developer. The last column matters as much as the others: every item needs an owner inside your company, not at the agency.

What to prepare	Why it matters	Usual owner
One primary goal and the customer task behind it	Decides the page structure, the form fields and what counts as success	Owner or manager
Draft content for the main pages	Layouts get approved around real text instead of placeholder lines	Whoever knows the service best
Logo files, colors, fonts and photos you can use	Missing brand files stall design and end in stock images	Marketing
Access to the domain, hosting, email and analytics	Avoids launch delays and protects control of your own address	Owner
Pages and features, split into launch and later	Keeps the first quote focused and shows what the platform must grow into	Project lead
Current URLs and the pages that bring visitors (if replacing a site)	Protects rankings and inquiries during the move	Marketing
Systems the site must connect to: CRM, booking, payments, newsletter	Integrations often take more time than the pages themselves	Operations
Budget range and deadline, with the reason for the deadline	Lets developers propose a scope that fits instead of pricing in unknowns	Owner
One person who collects feedback and makes decisions	Prevents conflicting comments and rework	Project lead
The person who will update the site after launch	Shapes the platform choice and the training you need	Office or marketing staff

Start with the task a customer needs to complete

Think about a task someone should complete on the site. For a service business, that might be sending photographs of a damaged item and requesting an inspection. What would your employee need before replying? A location, contact details and a short explanation might be enough. Asking customers for technical specifications they do not understand could prevent the inquiry altogether. Planning website development around a real task helps the team decide what the page should explain and what the form should ask.

Write the goal as a sentence you could check later. “Get more customers online” is a hope. “Receive ten inspection requests a month from the towns we serve” tells a developer which pages matter, what the form needs and which action analytics should count. If the site has more than one job, rank them. The homepage can only lead with one.

Write real content before anyone approves a layout

Try writing one service page yourself. A rough version is enough. You may discover that the sales team and the old brochure describe the offer differently. Sort that out internally. A designer cannot decide whether installation is included or which towns your staff will travel to.

Use actual service names and photographs in early drafts. A layout that looks comfortable with three short lines may struggle with the explanation your customer needs. Mark anything that still requires checking so nobody mistakes a temporary sentence for approved copy.

Content is also the part of a website project most likely to run late, because it depends on people who already have full-time jobs. Agree a date for first drafts before design starts, and decide who writes, who checks the facts and who signs off.

While you write, make each answer understandable on its own. Customers skim, and search engines and AI assistants increasingly quote a single passage rather than a whole page. Our guide to structuring a website so AI assistants can cite it explains why a paragraph that names its own subject travels further than one that leans on the heading above it.

Collect access to your domain, accounts and brand files

Plenty of launches stall for a reason that has nothing to do with design: nobody can find the login for the domain. Before the project starts, list every account the website depends on and confirm the company controls each one.

• The domain registrar, meaning the account that holds your domain name, with its renewal date and auto-renew switched on.
• DNS management, which is sometimes handled by a different company from the registrar.
• Current hosting, if you have it, and your business email provider.
• Google Analytics, Google Search Console and your Google Business Profile.
• Social profiles, ad accounts and any tracking pixels the marketing team relies on.
• The CRM, booking or payment tools the new site will connect to.

Two details save a lot of trouble later. Register the domain in the company’s name, not in the name of a former employee or a freelancer, and give the registrar account a recovery email address that does not depend on that same domain. If the domain lapses and your only recovery address lives on it, you lose the inbox you need to get it back. Then ask your developer to be added as a user on your accounts rather than setting tools up under the agency’s own login.

Gather brand files in the same pass: the logo in a vector format such as SVG or EPS, color codes, font names and photos you have the right to use. A designer can work around a missing font. A missing photo usually turns into a stock image nobody likes. If the new site will use video, prepare it the same way: on one page, written before anything is filmed. Our one-page video brief template shows what to put on it.

If you are replacing an existing website

A new website can quietly lose the search traffic and inquiries the old one earned. Most of that loss is avoidable if you prepare three lists before development starts.

1. Pages that bring visitors or inquiries. Export them from Google Search Console and your analytics, and mark the ones that must survive in some form.
2. Every current URL. When an address changes, plan a 301 redirect from the old URL to its closest replacement, not to the homepage. Google’s guide to moving a site with URL changes describes this mapping step and explains that permanent redirects carry search signals to the new address.
3. Everything the site talks to. Forms, CRM records, booking calendars, payment notifications and newsletter signups all need a destination and an owner. Our website redesign checklist for forms, CRM, booking and payments shows how to inventory those workflows and test each one before launch.

Keep the old site running until the new one has been checked. Ask the developer to block the staging site from search engines and to remove that block at launch, because a leftover noindex setting can keep a new site out of search results until someone notices.

Describe custom features as everyday tasks

A request for custom website development needs more detail than “we want a customer account”. Write down what a returning customer should be able to do there. Download invoices? Repeat a previous request? Change an appointment? Each action involves different information and rules. Ask whether an existing tool can handle it before commissioning something new.

For each feature, note who uses it, what they do, what should happen next and who gets notified. Four lines per feature is enough for a developer to estimate it honestly. Online stores face this decision often, and our breakdown of when a WooCommerce store needs custom development covers the signs that plugins have stopped being enough.

Separate launch requirements from later additions

You can launch with an inquiry form while leaving online booking for a later stage. Tell the team about that possibility now. They can account for it without building every feature immediately.

A simple way to sort the list is to mark each item as needed at launch, useful within six months, or nice to have. If everything lands in the first group, the list needs another pass.

Write a one-page website brief

A website brief is a one or two-page document that tells a developer what the site is for, who it serves, what it must do and what you can spend. It turns everything above into something a developer can price, and it does not need to be technical. Include:

• What the business does and who the website is for, in two or three sentences.
• The primary goal and the customer task behind it.
• The pages you expect, with a note on who writes each one.
• Features for launch and features for later.
• The systems the site must connect to.
• Two or three websites you like, what you like about each, and one you do not.
• Website requirements beyond looks: languages, an accessibility target and privacy or consent needs for your forms.
• A budget range, a deadline and the reason behind that deadline.
• The person who approves the work and the person who will maintain the site.

On budget, a range helps more than secrecy. When the brief leaves cost open, each developer guesses at a different scope and the quotes stop being comparable. A range lets them tell you what fits now and what would have to wait.

If you sell to the public, write an accessibility target into the brief, for example WCAG 2.2 Level AA. Accessibility is much cheaper to plan for than to fix after launch, and it affects colors, forms and navigation from the first design.

A website brief template you can copy

Here is the same brief as a fill-in template, completed for a fictional appliance repair company so you can see the level of detail a developer needs. Copy the table into a document, replace the examples with your own, and attach it to your first email to each developer.

Section	What to write	Example
About the business	What you sell, where, and to whom	We repair commercial kitchen appliances for restaurants within 40 miles of downtown.
Primary goal	One outcome you can measure	Ten inspection requests a month through the website.
Customer task	What a visitor must be able to do	Send photos of the faulty appliance, the restaurant’s address and a phone number.
Pages	Expected pages and who writes each one	Home, four service pages, service area, about and contact. The owner drafts the service pages.
Launch features	What must work on day one	Inquiry form with photo upload, click-to-call button, link to our Google Business Profile.
Later features	Planned, but not part of this quote	Online booking and a customer area for invoices.
Integrations	Where submissions and data must go	Each form entry creates a CRM contact and notifies the dispatcher.
References	Sites you like and dislike, with reasons	We like sites that show response times near the form. We dislike autoplay video on the homepage.
Requirements	Languages, accessibility and privacy	English and Spanish, WCAG 2.2 Level AA, a consent checkbox on every form.
Budget and deadline	A range and the reason for the date	A stated budget range. Live before the spring maintenance season, when inquiries peak.
People	Who approves and who maintains	The operations manager approves. The office coordinator updates the site.

Compare proposals by the work included, not the page count

A proposal for ten pages may include writing them, or it may assume you will supply every word. Before comparing website development services, ask who prepares the content, adds it to the site and checks the finished forms. Include those responsibilities in the agreement.

Send the same brief to every studio or freelancer you ask to create a website, so each quote describes the same project. Then ask the questions proposals tend to leave out:

• Who writes, uploads and proofreads the content?
• How many rounds of design changes are included, and what does an extra round cost?
• Will the site be built on a theme, a page builder or custom code, and why?
• Who owns the design files, the custom code and any premium theme or plugin licenses when the project ends?
• Who handles hosting, backups and security updates after launch, and for how long?
• What training is included for the people who will edit the site?
• How will forms, redirects and analytics be tested before launch?

The studio linked above is one example of a team offering this service, not an endorsement, and we have no commercial arrangement with them.

The build approach explains many price gaps. A theme-based site and a fully custom build can both be the right answer, but they are not the same product. If a proposal is built on a theme, our guide to choosing a WordPress theme covers what to check for speed, updates and lock-in before you accept it.

Licenses deserve a line of their own in the contract, because they are the item businesses lose track of most often. Visualmodo WordPress themes, for example, are GPL licensed, so a site keeps working if the license lapses, but theme updates and premium support depend on an active license. If that license sits in a freelancer’s account and the freelancer moves on, nobody at your company can renew it or open a support ticket. Ask for every theme, plugin and font license to be registered to your company, or transferred at handover.

Choose one person to collect feedback and resolve disagreements before sending comments to the team.

What changes website development cost

The number of pages is only part of website development cost. Several pages using the same layout may require less work than one calculator with complicated rules. Missing content, additional languages and connections to other systems also affect the work involved. Real-time features change the estimate most, because a live video chat feature keeps costing money every month after launch. Give each contractor the same requirements and ask them to identify assumptions in their estimate.

These are the factors that usually move an estimate the most:

• The number of unique page templates, more than the total page count.
• Features with business rules, such as calculators, customer portals or booking logic.
• Integrations with CRM, accounting, payment or booking systems.
• Copywriting, translation and photography, if the developer provides them.
• Moving content from an existing site and setting up redirects.
• Running costs: hosting, licenses, maintenance and support hours.

Ask each contractor to separate one-time build costs from yearly running costs. A cheap build with expensive subscriptions can cost more over three years than the higher quote.

Plan who runs the website after launch

Decide who will look after the pages once the contractor hands them over. Training belongs in business website development when your staff will make updates themselves. Ask that employee to replace a photograph and edit a service description during the handover, using the actual site. That test is even more useful before the platform is chosen. Our guide on choosing the right CMS for a business website lists the editing tasks to try in a trial environment, so the person who will maintain the site can judge it before anyone signs.

Write the handover into the contract: admin logins in the company’s name, a copy of the latest backup, a list of plugins and licenses, and a short guide to the most common edits. Our guide to what a website handoff document should include lists every item, from registrar details to support terms. A website is easier to look after when nobody has to rediscover how it was built.

Submit an inquiry from a phone and check the receiving inbox. Confirm that every login on your access list now sits under a company account. Keep the support contact with those records so staff know where to turn when a problem appears.

Brief, budget and ownership questions before you hire a developer