A useful business website starts with a decision: what should the right visitor do next? Define that action, the customers you want to reach, the pages they need, and the systems the site must connect to before asking a developer for a price. A clear brief makes proposals easier to compare and reduces avoidable changes during the build.
This guide is for business owners commissioning a new website or replacing an existing one. It includes a brief you can copy and a launch checklist you can use with your developer.
1. Choose one primary business outcome
“We need a modern website” describes an appearance. It does not tell a developer what the website must accomplish. A stronger objective is “help commercial customers request a cleaning quote” or “let existing customers book their next appointment.”
Choose a primary action for each important page: request a quote, book a call, buy a product, or submit a project enquiry. Supporting actions, such as reading a case study, should help a visitor reach that decision.
For example, a property maintenance company might need visitors to identify the right service, confirm the areas covered, explain the job, and attach a photo. That suggests a service page and a practical enquiry form. It does not automatically require customer accounts or a mobile app.
2. Describe the customer and the buying situation
Give the developer more than an industry label. Write down who buys, what triggers the purchase, and what they need to know before contacting you.
- Customer: a business owner, operations manager, consumer, or existing account holder.
- Trigger: a new location, a broken system, an upcoming event, or a recurring need.
- Main concern: suitability, reliability, delivery time, scope, support, or price.
- Proof needed: relevant work, a clear process, qualifications where applicable, or genuine customer feedback.
- Next step: the exact action that starts your sales process.
For an international audience, specify the countries you can actually serve, working language, currency, and how remote delivery works. Avoid creating dozens of near-identical location pages for places where you have no distinct offering.
3. Build the page list around customer questions
Start with the smallest useful structure. Add pages when they answer different questions or support different services.
| Page | Customer question | Useful content |
|---|---|---|
| Home | Is this business relevant to me? | Clear offer, audience, proof and next step |
| Service page | Can you solve my problem? | Scope, process, deliverables and exclusions |
| Work or case study | Have you done relevant work? | Real project context, your contribution and verifiable results |
| About | Who will I work with? | People, expertise and working approach |
| Pricing or quote guidance | What determines the cost? | Package scope or the inputs needed for an estimate |
| Contact | How do I start? | A short form, contact options and what happens next |
A blog should support these pages with useful buying and implementation guidance. It should not become an unrelated collection of popular topics. See the companion guide on turning organic traffic into qualified leads.
4. Separate essentials from later features
Every feature creates work beyond the visible screen. A booking system may need cancellation rules, staff availability, reminders, permissions and a way to resolve failed bookings. An online store needs product data, payment handling, delivery rules and order support.
Use three labels in your brief: required for launch, useful after launch, and undecided. Ask the developer to explain the dependencies of anything marked required.
For a first release, a reliable enquiry form may be enough. For a business already handling repeated transactions, self-service tools may be worth including. If you are unsure whether to build an app, use the website versus mobile app decision guide.
5. Agree the content and ownership responsibilities
Identify who writes the copy, supplies photographs, approves claims and checks product information. A page can be technically complete while still waiting for content that only the business can provide.
Also agree who owns the domain, hosting account, source code, analytics property and third-party subscriptions. Record which licences can transfer and which require renewal. Ask for a handover that another competent developer could understand.
When comparing proposals, compare the same scope. A low initial quote can exclude content entry, integrations, migration, testing or maintenance. Request these as explicit line items rather than assuming they are included. My pricing page gives starting packages; a project estimate should still confirm the actual requirements.
A website brief you can copy
Use the following outline when contacting a developer:
- Business and customers: what we sell, who buys, and the markets we serve.
- Primary outcome: the action we want a visitor to complete.
- Current problem: what is missing or failing today, with examples.
- Launch pages: the pages and languages needed in the first release.
- Essential features: forms, bookings, payments, accounts or integrations.
- Content responsibility: what we can supply and what needs producing.
- Existing systems: domain, hosting, CMS and tools that must be retained.
- Design references: a few examples and the specific qualities we like.
- Constraints: budget range, target launch date and approval contacts.
- Acceptance and support: how we will test the site and maintain it after launch.
Do not include passwords in a project brief. Account access can be arranged separately when required.
What to check before launch
Test complete customer journeys on a phone as well as a desktop. A working homepage is not enough: submit a test enquiry, confirm receipt, check error messages, and verify that the responsible person knows how to reply.
For a replacement site, map valuable old URLs to their new equivalents. Check page titles, canonical URLs, sitemap entries and whether important content is readable by search crawlers. Google's SEO Starter Guide explains the foundations of helping search engines discover and understand pages.
Agree how performance will be measured. Google's Web Vitals guidance distinguishes real visitor experience from laboratory testing. A single test score should not replace checking the actual tasks your customers need to complete.
FAQ
Can I request a quote before I have finished the brief?
Yes. Send what you know and label the uncertain parts. Ask for an initial scope discussion before treating an estimate as a fixed commitment.
Should I choose WordPress or a custom website?
Choose around editing needs, workflows, integrations and maintenance. A content-led site and a custom customer platform have different requirements. Ask the developer to explain why their proposed approach fits yours.
Do I need to prepare every blog post before launching?
No. Prioritise accurate service information, working enquiries and useful core pages. Publish supporting articles when they answer real customer questions and you can maintain them.
Discuss your website project
I build business websites and web applications with React, Next.js, Laravel and WordPress, alongside deployment and ongoing support. Based in Malta, I work with clients worldwide. Send your brief or describe your current website, and we can identify a sensible first release. You can also review my services and background.