Website projects rarely collapse because of code. They collapse because a call ended with everyone nodding and nobody writing anything down. The agency thought the contact form was included; you thought the blog migration was. The freelancer said “next week” and meant the end of the week after. If you commission web work, a short written follow-up after each call is the cheapest insurance you can buy. Here are eight items to put in that follow-up, in the order they tend to cause trouble.

1. The deliverable, in one plain sentence

Start with what you are getting, described in words a stranger could follow. “A five-page business website on our existing CMS, with a contact form and a blog section” beats “the new site”. If you cannot compress it into a sentence, the call did not settle it, and you have just found out while it is still cheap to ask again.

This matters because web terms stretch. “Redesign” can mean fresh colours or a full rebuild. “Migration” can mean moving ten pages or ten years of posts. The sentence forces both sides to pick a meaning.

2. What is explicitly not included

Every web project has a boundary, and disputes live right at it. Note two or three items that were mentioned and parked: copywriting, product photography, redirects from old addresses, ongoing maintenance. Phrase it neutrally: “We discussed copywriting and agreed it stays with us.” If the other side disagrees, you want to hear it now.

A related trap is the nice-to-have that drifted into the plan. If you are still deciding what the site needs, it helps to read up on which pages a company site normally carries before the call, so the follow-up lists pages by name and not by vague category.

3. The pricing basis

You do not need to restate numbers if you would rather not, but you should record the basis: fixed fee for the defined scope, or time-based billing, and what triggers extra charges. The classic web-project argument starts with “that was outside the quote”. A single line such as “Anything beyond the listed pages will be estimated and agreed before work begins” removes most of the sting.

Keep the tone practical. You are not accusing anyone of overcharging; you are making the rule visible so neither of you has to argue about it later.

4. Dates, split into owed-by-them and owed-by-you

Projects stall as often on the client’s side as on the developer’s. List both kinds of date: when the developer will deliver the first draft, and when you will supply content, logos, login details or feedback. A line like “Draft by the date we discussed; our text and images to you by the Friday before” shows that you take your own side seriously, which tends to make the other side take theirs seriously too.

Be careful with soft time words. “Soon”, “shortly” and “in a couple of weeks” are the web equivalent of “the check is in the mail”. Replace them with a calendar date, or ask for one in your reply.

5. What “done” means

Ask yourself whether the project is done when the pages exist, when they are on a staging address, or when real visitors can use them. Write the one you mean. Add whether testing on phones and common browsers is part of the deal, and who fixes bugs found in the first couple of weeks after launch. The more you use words like “live” and “launched”, the more you need to define them.

Planning helps here. The checklist-minded approach in a step-by-step method for preparing a site before any development begins makes it easier to say what finished looks like, because you already wrote down the goal.

6. Access and ownership of accounts

This one is a favourite source of unpleasant surprises. Note who holds the domain registration, hosting login and CMS admin account, and say that you will have access to all of them. Do not cite law or contracts; just state your understanding as a working arrangement: “The domain and hosting stay in our name; you will have the access you need while you work.” If the answer is anything other than yes, ask a follow-up question rather than hoping.

7. The change rule

Requests will change mid-project. That is normal, and the point is not to ban changes but to say how they travel. A good line: “If we want to add or swap something, I will message you, you will tell me the effect on time and cost, and we will both confirm before it starts.” This keeps changes small, visible and agreed, and it stops the quiet scope creep that turns a three-week job into a three-month one.

If marketing goals are shaping the changes, the thinking in an article on making service pages bring in enquiries may help you decide which ones are worth making before you ask for them.

8. Who confirms, and where it lives

Finish by naming the thread. “I will keep all project messages in this email chain so we both have one place to look.” Then do exactly that. A confirmation scattered across chat apps, voicemail and a notes file is only slightly better than no confirmation. Pick one channel, tell the other side, and forward anything agreed elsewhere into it.

Putting it together: a sample follow-up

Here is a compact version that a busy small-business owner could send within hours of a call.

Thanks for the call today. To confirm: you will build the five-page site on our current CMS, including the contact form, and hand us a staging link for review. Copywriting and photography stay with us. Fees follow the fixed scope we discussed, and anything extra gets estimated first. You deliver the first draft by the date we named; we send text and images the Friday before. “Done” means live for visitors and tested on phones. Domain and hosting stay in our name. If either side wants a change, we message first and confirm cost and time before work starts. Please correct anything I have wrong.

That is under a hundred and fifty words, and it covers seven of the eight items. It reads as friendly, and it gives the developer a clean chance to say “actually, photography needs another day”.

Where a small business might need other professionals

Web work touches money in ways that sometimes need a specialist, such as how a site’s costs are recorded for the business. That is not a job for the developer or for a blog post. Anyone hunting for a chartered accountant could start with a directory: BestCaNow is a directory of chartered accountants where listings can be narrowed by city, speciality and consultation mode. Treat any firm you contact the way you treat a developer: afterwards, send two or three lines about what you understood they would do.

A final practical note

One more habit is worth adding if the project runs for weeks: send a short recap after every call, not only the first one. Mid-project calls are where the quiet changes happen, such as a swapped page, a postponed review or a new plugin that nobody priced. A two-line message after each of them keeps the thread current, and when the project ends you will have a plain timeline of what was decided and when, without having to reconstruct anything from memory.

You do not need all eight items every time. For a small text change, items one, four and five may be enough. For a full rebuild, use the lot. What matters is the reflex: when a call ends, you reach for the keyboard before you reach for the next task. Send the note while the details are warm, ask for corrections, and keep everything in a single thread. The project will still have surprises, because web projects do, but they will be surprises about the work and not about what anyone said.