Website development stages: what to check from brief to launch

The designer is waiting for copy. The writer is waiting for an approved structure. You are waiting for the design to work out which photos to find. Everyone is busy, the hosting bill has been paid, and there is still nothing to put on the service page. This is a common hypothetical situation, not an account of a particular client.

Website development stages matter because they show which decision must be made before the next job begins, who supplies the materials and what you are asked to approve. Design and code can delay a project, but bottlenecks often appear earlier: products, copy, photos, terms, access and the person authorised to approve them have not been defined.

We’ll follow the work from the brief through the first 30 days after launch. The real example is GrandMa’s work on Ratner Beauty, a perfume-decant store we built from the ground up, including catalogue structure, measurement and an editorial system. The case shows why a website is more than a homepage design. Its recorded results appear at the end, clearly separated from sales figures the evidence does not provide.

The order can vary by site type and contract; some work can happen in parallel. Every stage still needs an input, a result and someone to accept it.

Use this table to read a quote. If it says “turnkey website” but does not say who writes the copy, uploads products or checks the forms, nobody yet knows who is holding the key.

A useful brief does not need thirty pages of general wishes. It should answer: who comes to the site, what they need to understand, why they might not contact you and which action we want to make easy. In a store, that could be finding a product, comparing sizes, placing and receiving an order. For a service, it may be checking experience and terms before getting in touch.

Ask to see a page map before the first decorative design. Where are the categories? Do different needs have separate pages? How will someone reach the relevant product from search rather than always landing on the homepage? For Ratner Beauty, we established the offer and audience, site architecture, product structure, measurement and search foundation early. That is the documented scope. There is no reason to invent meeting counts, prototype counts or approval times absent from the case evidence.

A prototype sets the order of information without the final styling. A product page needs a name, variants, terms, an action and answers to questions that might prevent a purchase. You can check this route before design makes changes more expensive. I want someone to be able to find what they need on a phone without touring the entire site.

Not every project needs a large standalone prototype document. A simple site may need only a diagram of blocks and links. The check of content and route is still useful. Otherwise the debate over whether you need a “Delivery” page begins after the footer has been built.

A writer can make copy clear but cannot know your stock levels, minimum order, returns terms or delivery area out of thin air. A designer can lay out a catalogue elegantly but cannot decide your product taxonomy for you. Decide at the outset who gathers facts, who writes, who checks and who gives final approval.

Product structure formed part of the Ratner Beauty store’s foundation. With many brands and variants, poor classification reaches the menu, filters, product cards, analytics and search. That is why content structure and technical SEO belong before bulk content entry, rather than being added afterwards.

Photos need a decision too. Ask for a shot list by page: cover, product, detail, team and evidence of work. Clarify format, size and rights to use each image. Do not plan a page around five large photos if the business has one blurry messenger image. And do not fill the gap with unrelated AI images that explain nothing about the product.

Review more than the first screen. Ask to see a long page, product card, form, error message, empty search result and mobile layout. If the text is enlarged, can someone still read and use the controls? Is keyboard focus visible and the action accessible? The W3C WAI preliminary checks help spot basic barriers; they do not replace a full accessibility audit.

During development, the design becomes HTML, pages, forms and integrations. You need a staging address where you can walk through three important scenarios. First, a visitor reaches the relevant page and finds an answer. Second, they submit a form or place an order. Third, something goes wrong and the site explains the next step. A “Thank you” message does not prove an enquiry was delivered; trace it to the inbox, CRM or other actual recipient.

If important content appears only after JavaScript runs, check whether search systems can reach it. Google explains how it processes JavaScript. Technical access alone cannot guarantee indexing or rankings, but it is necessary to check before SEO work.

1. One main site goal. What should happen after a visit: an enquiry, order, booking or price request?
2. A list of products or services. Include variants, limits and what you do not sell yet.
3. Buyer questions. Use real emails and conversations, not a competitor’s invented FAQ.
4. Sales terms. Price or pricing method, delivery, geography, timing, payment and returns.
5. Trustworthy facts. Cases, reviews, documents and work photos you can publish, with their sources.
6. A content owner. Someone who can verify facts and answer an editor promptly.
7. A decision maker. Someone who signs off on structure, copy and design rather than running endless votes.
8. Access and ownership. Know who controls the domain, hosting, email, analytics and ad accounts.
9. Current website URLs. If replacing a site, list important addresses for a redirect map.
10. An acceptance plan. Decide which journeys to test, who receives the test enquiry and who fixes defects after launch.

Some of these items may be missing at the start. That is manageable when the plan names who will prepare them and when. It becomes a problem when, three months in, everyone asks for the first time who has the domain password.

How to approve work without waiting three months for copy

Appoint one person to collect comments from the business and send the provider a single decision. If sales, accounts and the owner all comment on the design in separate chats, the team receives three incompatible versions. Agree on one document for changes, a reply date and a person who resolves conflicts. That does not remove disagreement; it keeps it visible.

Set a delivery date and format for each material. For example, provide category names before prototype approval, real images and specifications before designing the product card, and delivery rules before content entry. If the business cannot prepare something, say so at the start. The provider can include that work in scope or change the order. It should not pretend a temporary placeholder is finished content.

At each acceptance point, ask to see the specific result in the table above. “We worked on structure” is difficult to approve. A page map, list of product types and three visitor journeys give you something concrete to discuss. If the task changes, document the new scope and its effect on timing and cost before the next stage. Then a delay has a stated cause rather than turning into mutual claims of “we thought you would do that”.

Before switching the domain, make a backup of the current site and agree on how to restore it if the switch fails. Record who may change DNS, server settings and forms. A backup helps only when you know where it is and how to restore the site. Ownership matters here too: our guide explains what a business should retain if a contractor disappears.

After the switch, follow this short checklist:

• Open important pages on phone and desktop; check the menu, links, images and error messages.
• Submit a test form and trace delivery, notification and the responsible person. Test invalid input too.
• If it is a store, test payment or checkout in the agreed test mode.
• Check page titles, descriptions, canonical URLs, indexing settings and a sitemap. Google says submitting a sitemap is a hint, not a guarantee of crawling or indexing.
• If addresses changed, check the old-to-new URL map and redirects. Google has separate guidance for a site move with URL changes.
• Confirm analytics records the required events, while keeping a button click distinct from a delivered enquiry.
• Hand the owner real access and a short support guide, not just the admin URL.

If the pre-launch check finds a crawling or indexing problem, a technical SEO audit can help prioritise the fix. Repair the critical route before adding ten more pages of copy.

After launch, real people and devices arrive that did not take part in testing. At least once a week, check forms, errors, important pages, customer questions and the team’s ability to reply. If many visitors ask the same thing, a key condition may be hidden or unclear. If enquiries arrive but never reach a manager, the problem is not visitor volume.

For Ratner Beauty, the documented result of the search foundation over 1 July 2025 to 30 June 2026 was 156,379 clicks and 7,283,598 impressions in Google Search Console. GA4 recorded 170,606 organic sessions over the same period. Those figures describe a measurable acquisition channel over twelve months. They do not establish revenue or the number of purchases; the public case does not provide those figures. Nor do they promise the same outcome for another site after launch.

If you are planning a site, GrandMa’s website and e-commerce service explains how we handle structure, design and launch. For a smaller task, you can see a free homepage mockup for our Ukrainian-language UAH 9,900 website offer before discussing the direction in detail. That promotion has its own scope; a larger project starts with a separate agreement on the work and decisions required. A site is ready when a real buyer can complete the journey and the business can see and manage its result.