A preparation checklist for business owners: objectives, audience, content, assets, access, decision-making, and the details that make a website project move faster.
Written by
Mahmoud Fawzy
Independent full-stack developer and automation specialist.
Keep reading
Automation
Five focused automation ideas that connect the tools a small business already uses, with practical boundaries, failure handling, and human approval points.
Read article
Website Decisions
A practical comparison of page builders and custom websites, focused on the work, ownership, trade-offs, and ongoing responsibility behind each option.
Read articleA fast website project does not begin with a blank design file. It begins with decisions.
You do not need to arrive with a complete brand strategy or perfectly polished copy. You do need enough information for the developer to understand the business, define the pages, identify dependencies, and recognise what “finished” means.
Preparing the following material before the start date makes estimates more accurate and reduces avoidable delays.
Start with the change the website should create.
“We need a modern website” describes appearance, not an outcome. A more useful statement is:
Choose one primary outcome. The site can support secondary actions, but it should not treat every possible action as equally important.
Describe the people you want to reach in plain language:
For example, a consultant’s visitor may not need a detailed history of the business. They may need to know whether the consultant works with companies their size, what the engagement covers, and how the first conversation works.
The strongest page structures answer real decision questions in a sensible order.
For each offer, write down:
Do not worry about polished marketing language yet. Accurate raw information is more valuable than vague, enthusiastic copy.
If the service still changes every time you explain it, the website project may expose a business-definition problem. Resolve that before asking the developer to make the page look final.
You do not need to know the final information architecture, but a draft list helps define the size of the project.
A small business website might begin with:
Other projects may need pricing, process, frequently asked questions, legal pages, locations, or several service pages.
For every proposed page, answer:
What specific job does this page perform that another page cannot?
If there is no clear answer, the information may belong on an existing page.
Content normally includes more than paragraphs. Prepare:
Mark each item as:
This gives the developer a realistic view of what can begin.
Basic copy refinement is different from full copywriting. Refinement improves structure, clarity, and consistency in material you provide. Full copywriting may require interviews, research, positioning work, or approval from several people. Confirm which service is included.
Collect the highest-quality versions of:
Whenever possible, provide original files rather than images copied from a previous website.
Also confirm that you have the right to use each asset. Images found through search, customer logos, fonts, and illustrations may have licensing or permission requirements. The developer cannot safely infer those rights from the file alone.
If you have no brand system, say so. The project can then include a limited visual direction or identify whether proper brand work is needed first.
Use concrete actions rather than broad labels.
Instead of “advanced contact form,” describe:
For analytics, identify the events that matter. A useful list might include:
For integrations, identify the exact services and confirm that the required accounts or APIs exist.
The developer may eventually need access to:
Do not paste passwords or private keys into an ordinary enquiry form.
Use separate accounts, invitations, temporary credentials, or a password manager when possible. Grant the minimum permission needed. Record who owns each account and remove access that is no longer required after the project.
Fast projects need clear approval.
When several people give separate feedback, the developer may receive contradictory instructions. Choose one person to:
This does not exclude stakeholders. It gives their input one coherent route into the project.
Good feedback connects a requested change to a reason.
Compare:
The second comment is easier to evaluate and may reveal a better solution than the exact change first imagined.
Group feedback into the included revision round rather than sending isolated comments throughout the day. Label each comment by page and section. Distinguish corrections from new requirements.
A desired launch date is useful only with context.
Explain whether the date is connected to:
Then work backward. Content, brand assets, account access, review time, payment, DNS changes, and final checks all need space.
An advertised “first version in two days” does not mean a project can start while essential content is still unknown. The clock should begin after the agreed prerequisites are ready.
A budget range helps the developer recommend an appropriate scope.
It is acceptable to be unsure. It is less useful to request a ten-page site, custom integrations, extensive copywriting, and a complex content system while withholding every indication of budget.
The developer should respond honestly too: explain what fits, what does not, and which feature should be deferred if the budget is fixed.
Before requesting an estimate, prepare a document containing:
This brief does not need to be beautiful. It needs to be accurate.
If you have most of these answers, you are ready to request a project estimate. The form will organise the details and preserve the boundaries that keep a fast project realistic.
Discuss your project
Tell me what you are trying to build, and I’ll reply with the clearest next step.
Contact Mahmoud