What to Prepare Before Starting a Website Project

A website project rarely slows down because nobody can design a section. It slows down because decisions, content, proof, logins or approvals are missing. The designer waits for service descriptions. The developer waits for domain access. The copywriter waits for a product list. The director wants to comment but was not involved earlier. The launch date approaches, and everyone suddenly discovers that the business still has not agreed what the website must say.

Preparation does not mean doing the supplier's job. It means gathering the raw material that only the business can provide. A web design team can shape the structure, write stronger copy, improve user experience, build the pages and set up tracking. But they cannot invent real proof, choose your business priorities, know which enquiries are profitable or access accounts that belong to you. Those pieces need to come from the business side.

If you already have a written brief, use this article as the practical checklist behind it. If you do not have a brief yet, start with the website project brief template, then come back here to collect the files, decisions and access that will make the project easier to deliver.

Before collecting images and passwords, clarify the decisions that guide the whole project. The first is the main goal. Is the website meant to generate leads, sell products, build credibility, support recruitment, answer customer questions or prepare the business for campaigns? The second is the audience. A site for corporate procurement teams needs different copy from a site for parents, patients, tourists, developers or retail customers.

The third decision is the scope of the launch. Some businesses try to launch everything at once: services, products, blogs, case studies, downloads, landing pages and integrations. That can work when content and approvals are ready. When they are not, it is better to define a strong phase one. A clear first launch might include the homepage, about page, core service pages, proof, FAQs and contact paths, with case studies or extra landing pages added later.

The fourth decision is budget range. You do not need a perfect figure before requesting a quote, but you should know whether you are planning a basic presence site, a lead-generation website, an ecommerce store or a more custom system. A public website cost guide can help you understand how scope affects price before the first proposal conversation.

Content is the most common bottleneck in website projects. Many businesses say the content is ready, then discover that it exists across WhatsApp messages, old proposals, brochures, social media posts, staff laptops and memory. The project becomes slower because someone must keep hunting for the latest description of each service.

Create one project folder before work begins. Add your company profile, current service descriptions, team bios, product lists, price sheets if applicable, past proposals, brochures, FAQs, testimonials, case studies, brand assets, photos and any documents that explain how the business works. The content does not need to be perfect. It needs to be available. A good website team can refine rough material faster than they can chase invisible material.

If you are building a service website, prepare one rough note for each service. Include who the service is for, what problem it solves, what is included, what is not included, common questions, proof and the next step you want visitors to take. If you are building an online store, prepare products, categories, descriptions, prices, variations, stock rules, delivery rules and payment information. For a redesign, also list what content from the old site should be kept, rewritten, merged or removed.

Website copy becomes much stronger when proof is available early. Proof can be client testimonials, reviews, project photos, before-and-after examples, certifications, awards, press features, numbers, years of experience, client logos, partner logos, compliance information or short case notes. The type of proof depends on the business. A school may need facilities, curriculum, parent confidence and student outcomes. A construction company may need project photos and safety process. A consultant may need case results and sector credibility.

Do not leave proof for the end of the project. Proof affects page layout. If testimonials are strong, they can sit near calls to action. If project images are available, the design can use them to make services feel real. If the business has certifications, they can support trust sections. If there is no proof, the copy may need to be more educational and process-led until stronger evidence is collected.

You should also check permissions. Some clients may not want their names or logos used. Some project photos may show private information. Some testimonials may need approval before publication. Collecting proof early gives you time to ask for permission instead of delaying launch.

Access problems are frustrating because they often appear late. A website can be ready to launch, but the team cannot point the domain, configure email, verify Search Console, move hosting or connect analytics because the right login belongs to an old developer, former employee or forgotten account. Solve this early. You do not need to hand over everything on day one, but you should know who controls each account.

Common access includes domain registrar, hosting, WordPress admin, business email, Google Analytics, Google Search Console, Google Business Profile, payment gateway, M-Pesa account, CRM, email marketing platform, social pixels and any third-party tool that needs to connect to the website. For an existing site, also check whether you have backups, admin roles and the ability to create new users safely.

This matters for ownership. A business website should not depend on one person who is impossible to reach. If the site will use WordPress, prepare a secure admin handover plan and make sure maintenance responsibilities are clear. If the site needs ongoing updates, discuss website maintenance before launch, not after something breaks.

Website projects can become slow when everyone is allowed to comment but nobody is responsible for deciding. Before kickoff, name one project owner. That person does not need to write everything or approve in isolation, but they should gather internal input, keep priorities clear and give consolidated feedback to the website team.

Also list the stakeholders whose input is needed before certain stages. Sales may need to review service messaging. Operations may need to confirm process claims. Finance may need to approve pricing language. HR may need to review careers content. Leadership may need to approve positioning and final launch. If these people appear only at the end, the project can restart after it looked complete.

Agree how feedback will be given. Clear comments are specific and tied to the goal. Weak comments say a section feels off without explaining why. Strong comments say the page needs more proof for corporate buyers, the form should ask for location, the service description is missing a key package, or the pricing context could attract the wrong enquiries. The more precise the feedback, the faster the project improves.

Launch planning is often treated as the final step, but the rules should be known early. Decide whether the new website will replace an existing site, launch on a new domain, start as a subdomain or go live in phases. If the current website receives search traffic, redirects need to be planned. If forms support sales, test emails and lead routing before public launch. If the site uses payment, test checkout with real operational scenarios.

For redesigns, prepare a list of important old URLs. Some pages may need redirects to protect search visibility and user bookmarks. Some content may need to be rewritten instead of deleted. Use tools such as website redesign readiness scoring or an SEO audit before removing old pages that may still have value.

After launch, decide who will check forms, analytics, Search Console, page speed, backups and updates. A website is not truly finished when it is visible; it is finished when the business can trust it, measure it and maintain it.

You do not need to make every detail perfect before starting. A good website team can help you refine structure, copy and technical choices. But you should avoid starting with empty hands. The more organized the business is, the more the website team can spend its time on strategy, design, build quality and launch readiness instead of chasing missing basics.

• The website goal, audience, launch scope and budget range are clear.
• Core services, products, proof and brand assets are gathered in one folder.
• Domain, hosting, CMS, analytics and integration ownership is known.
• The project owner and approval stakeholders are named.
• Old website URLs, useful content and redesign risks have been reviewed.
• Launch testing, tracking, maintenance and handover responsibilities are planned.

Preparation is not paperwork for its own sake. It is what gives the project enough truth to work with. When the business brings clear decisions and real material, the website can become sharper, faster and more useful from the first strategy session.