What to Prepare Before Starting a Web Development Project

A project goes well when both sides understand what is being built before anyone starts building it. Most of what makes a project expensive is a decision made without the information needed to make it properly, discovered halfway through.

1. The problem, in your own words

Write a paragraph describing what is wrong today and what would be different if it worked. Not a solution — a problem. "Customers cannot tell what we do from our site" is a problem. "We need a new website" is a request for a solution, and it skips the step where the better solution gets found.

2. Who uses it, and what they will be doing

• Which customers matter most, and which can be ignored for now.
• What they arrive trying to do.
• What usually stops them.
• What currently happens instead — and whether that is a problem.
• What the site must do on a phone versus a desktop.

3. Your content, or a plan for it

This is the most common cause of delay. Layout is designed around real content, and placeholder text is never the right length or tone. Gather what exists, even if unfinished, and identify who will write what is missing.

• Every page, even as rough notes.
• Photographs and logos, at the highest quality available.
• Existing written material worth reusing.
• A named owner for each piece of content that does not exist yet.

4. Anything the site must connect to

Enquiries, bookings, stock, payments, a mailing list, an existing CRM. Each of these is an integration with its own constraints, and discovering one late is expensive. For each, find out whether it offers a documented way to connect, and what it charges.

5. Constraints that are already fixed

1. An existing brand or website with rules that must be followed.
2. Regulatory or accessibility requirements that apply to your sector.
3. Deadlines that are real, and the reason for them.
4. Budget, including the ongoing costs after launch.
5. Who inside the business can approve decisions, and how quickly.

6. How you will judge whether it worked

Agree the measure before the build: enquiries, sign-ups, calls, sales, or something else. Without it, success becomes a matter of opinion, and the discussion at the end is about taste rather than results.

7. Who maintains it afterwards

Decide this early, because it changes what should be built. If the answer is "nobody internally", the site needs an editor and training. If the answer is a developer, it needs a codebase they can work in. If the answer is an agency on a retainer, that is a budget line to agree now.

What a good first conversation looks like

1. You describe the problem In your words, without proposing a solution.
2. They ask what already exists Content, systems, brand rules, deadlines, budget range.
3. They come back with scope and questions Written down, with what is explicitly excluded.
4. You both agree what done means Before anything is built, so it is not a debate afterwards.