Before you build an online store, agree these five things

1. Understand the products

Start with the products you intend to sell at launch. Record the names, descriptions, prices, images, categories, and stock information needed to present them clearly.

Sizes, colours, bundles, personalised items, and subscriptions introduce different requirements. Describe them before estimating the store. A small, accurate product set is easier to review than an incomplete catalogue.

2. Agree the payment journey

Decide which customer locations and payment methods the store needs to support. Confirm who owns the payment-provider accounts and who is responsible for setup and verification.

Discuss currency, failed payments, refunds, and the notifications the customer receives. The design should support the actual checkout flow rather than assume that every payment requirement is already solved.

3. Define shipping or collection

Write down where you deliver, how charges are calculated, and which products need special handling. If you offer collection, explain the available locations and the information the customer needs.

Shipping rules can depend on product size, weight, destination, or order value. List the required scenarios so they can be scoped and tested. The business should supply approved commercial policies and any tax or legal requirements from its appropriate advisers.

4. Prepare the information customers need

Product photography and descriptions need to explain what the customer is buying. Include dimensions, materials, care information, or compatibility where relevant.

Prepare approved delivery, returns, privacy, and contact information. Agree who supplies the content and who verifies it. Do not wait until launch week to discover that a required policy or product detail is missing.

5. Plan what happens after an order

A store is also an operating process. Who checks new orders? Who updates stock? Who fulfils, cancels, or refunds an order? Which emails and integrations does that team rely on?

Test the agreed journeys before launch, including successful orders and the key failure scenarios. Confirm the handover, account ownership, maintenance responsibilities, and recurring costs.

The best store brief connects the customer’s purchase to the team’s next action.

These decisions give the build a clear scope and help your team understand what the store needs to do behind the scenes.

Describe the build, not just the appearance

A polished design file is a strong starting point. A development brief connects that design to the way the finished website needs to work.

Describe the WordPress stack, required page templates, content structure, and integrations. If a decision is still open, mark it as a question. A visible question is easier to resolve than an assumption discovered during review.

Good handover information reduces the number of decisions that have to be made halfway through a build.

Make the responsive and interactive details visible

Share approved desktop and mobile layouts where available. Call out menus, hover and focus states, accordions, forms, and any scroll effects. Explain what a component should do when the content is longer than the sample.

When a design only shows one screen size, agree how the missing layouts will be interpreted and who approves them. Keep animations specific: what moves, when it moves, and how the page behaves when a visitor prefers reduced motion.

Plan the content and the editing experience

Clarify whether the copy and assets are final, who supplies them, and who checks permission to publish. Identify pages that share a template and sections that will be reused.

Describe what the client should be able to change. Text and image updates are different from rebuilding a layout. Agreeing the expected editing workflow helps decide which components and fields the website needs.

• List the content needed for each page or template.
• Identify reusable sections and repeatable content.
• Mark unfinished copy, missing assets, and owner responsibilities.
• Describe the everyday edits expected after handover.

Agree how reviews and changes work

Define milestones, review rounds, and acceptance checks before development. Collect feedback in a shared place and provide a consolidated set of comments for each review.

Distinguish corrections to the approved scope from new requirements. A new integration or changed page structure can affect cost and timing. Agree the change before asking the development team to implement it.

Make the white-label relationship explicit

Agree who can contact the end client, how the work is attributed, what confidentiality applies, and which accounts the development team can access. The agency’s client relationship should be clear from the start.

Define the launch and handover tasks: final approval, domain and hosting responsibilities, editing guidance, documentation, and any support period. Starting with a small paid pilot can help both teams understand the collaboration before discussing ongoing capacity.

Start with the job your website needs to do

A first website does not need to tell every possible story about your business. It needs to help the right visitor understand what you offer and decide what to do next.

Begin with a simple question: when someone arrives, what would make the visit useful? For a local service business, that might be checking whether you cover their area and requesting an estimate. For a studio, it might be seeing relevant work and arranging a conversation.

A useful first website answers the customer’s next question, then makes the next step easy.

Build the essential pages first

The right structure depends on your business, but a focused starting point often includes:

• A homepage: a clear introduction to what you do, who you help, and the next action.
• Service information: explain the work you offer, what is included, and what a customer needs to know.
• An introduction to the business: your real story, approach, and experience.
• A contact route: an enquiry form, phone number, or agreed booking flow.

Some businesses can combine these into fewer pages. Others need separate service pages. Agree the structure around the information visitors need rather than a page-count target.

Use the content you can stand behind

Gather your service descriptions, coverage area, contact details, logo, and any photography you have permission to use. Customer questions are a useful source for clear website copy: explain the answers in the same language you would use in a conversation.

Use genuine project examples and customer feedback only when you can verify them and have permission to publish. A small set of relevant, honest examples is more useful than a large collection of vague claims.

If content or photography is missing, identify that during scoping. Agree who will prepare it, how it will be reviewed, and whether it adds cost or affects the launch date.

Decide what can wait

A booking system, product store, large resource library, or advanced integration may be valuable. It may also introduce recurring fees, more content, and extra support work. Add a feature because it solves a defined need.

Write a short “later” list. Launch with the information and contact route your business needs now, then revisit that list using real questions and feedback from customers.

Check the practical details before launch

Review the website on a phone as well as a larger screen. Read the copy, follow the navigation, and test the contact route. Confirm that an enquiry reaches the right person and that someone is responsible for handling it.

Agree who owns the domain and hosting accounts, how everyday edits work, and what maintenance is included. These decisions make the handover easier and avoid uncertainty after launch.

A website provides a place to explain your business. How people find it and how you respond to enquiries are separate parts of the plan. Define those next steps alongside the build.