The Web Development Process: From Brief to Launch and After

When you commission a new website or online store, the hardest thing to picture isn't the price. It's what happens after the contract is signed. Web development isn't one big job that is suddenly finished one day. It's a series of stages, and each one needs your decisions, your content and your access to things.

This post walks through the web development process as it usually runs with us: from discovery and content through to testing, launch and maintenance. For each stage we say what we do and what we need from you. If you're still deciding whether a custom site makes sense at all, start with our guide on custom website vs template.

The stages at a glance

Stage	What happens	What we need from you	Result
Discovery	Goal, audience, page structure, integrations	A brief, access to existing systems	Agreed scope
Content	Copy, images, product data	Content, or a decision on who creates it	Content the design can be built on
Design	Key pages and the main user flow	Feedback through one person	Approved design
Build	The site built in a staging environment	Answers to questions, test data	A working site in preview
Testing	Speed, accessibility, phones, forms	Trying it yourself	A fixed list of issues
Launch	Domain, redirects, analytics, Search Console	Access to domain and accounts	The site is live
Maintenance	Updates, fixes, further development	An owner who flags changes	The site stays healthy

Here's each stage in more detail.

1. Discovery: what the site has to do

Before anyone draws or writes anything, we agree on what the site is for. One main action: a booking, an enquiry, a purchase, a call. Everything else on the site supports it.

In discovery we settle:

• the number of pages and languages;
• the steps of the main user flow;
• which systems are already in use (booking or till system, e-commerce platform, CRM, accounting) and whether the site needs to connect to them;
• who will edit the site afterwards, and how often;
• what goes into the first version and what waits for later.

That last point matters most. Most projects that drag on do so because the scope quietly grows along the way. It's better to launch a smaller site on time and add the rest later.

What we need from you: a brief (the questions to answer are in our custom website vs template guide), access to your current site and systems, and one person who makes the decisions.

2. Content before design

This is the stage people underestimate most. A design built around placeholder text falls apart when the real copy is three times longer or the photos don't exist.

Content includes:

• copy for every page, in every language;
• photos and video, with the rights to use them;
• logo and brand colours;
• product data, prices, opening hours, contact details;
• legal text: privacy policy, cookie information, terms of sale.

If the content doesn't exist, decide early who will create it. If it's you, by when. If it's someone else, who, and on what budget. The most expensive option is content that "comes later", so the design has to be done twice.

On a multilingual site, every language is separate content. Machine translation can be a decent first draft, but only publish what a fluent speaker has read.

What we need from you: the content, or a clear decision on who produces it and when.

3. Design

We design the key pages and the main user flow first. Not every subpage separately, but the templates the rest of the site is built from. The mobile view is part of the design from the start, not added at the end.

When a site relies on motion, like our demo site Lõke (a made-up restaurant brand we built as a sales demo, not client work), we test the motion early in a real browser. A static image can't tell you whether the scrolling feels right.

One practical tip on feedback: collect it through one person. If five people send separate, conflicting comments, someone has to reconcile them anyway, and it's better if that's you rather than the developer.

What we need from you: consolidated feedback, and sign-off on the design before the build starts.

4. Build

During the build we develop the site in a staging environment and give you the address. You see progress in a real browser and on your phone, not just in screenshots. Staging is closed to search engines.

We pick tools to fit the job. Lõke is built with Vite, GSAP, Lenis and OGL, with no large framework. The AMPSU shop and recipe platform run on Next.js, Medusa, Directus and Stripe. Our other demo, 3D House Demo, shows a five-apartment house straight from its Revit model, with live section cuts. It's also a demo, not a client commission.

Integrations (payments, delivery, bookings, CRM) are built and tested in test mode before they touch real data. On AMPSU, the recipe platform was tested in a separate preview environment against the real shop back end, so the live shop was never disturbed.

What we need from you: quick answers to questions, test accounts or data from the systems we connect to, and consistency. New wishes go on a list, not straight into the build.

5. Testing: speed, accessibility and phones

Testing isn't the last day before launch. Some of it runs throughout the build, but before launch we do a dedicated pass.

Speed and Core Web Vitals

According to Google's Core Web Vitals guidance, a good result is LCP within 2.5 seconds, INP of 200 milliseconds or less, and CLS of 0.1 or less. We measure with Lighthouse and PageSpeed Insights, and also on a real phone over mobile data, because a developer's laptop is always fast.

After launch it's worth checking real-visitor data as it builds up over time. Lab scores and real user experience aren't always the same.

Accessibility

At minimum we check that:

• every action can be done with a keyboard, and focus is visible;
• images have meaningful alt text;
• text has enough contrast against its background;
• form fields have labels and error messages make sense;
• visitors who have reduced motion turned on get a calm version instead of the animation.

This isn't only good practice. Since June 2025, EU accessibility requirements also cover many online shops and other web services (with exemptions for micro-enterprises). It's worth checking the exact requirements for your sector.

Phones and browsers

We test on real iOS and Android devices, not just the browser's mobile view. Especially forms, payments and anything that depends on touch or scrolling.

What we need from you: go through the main action yourself, as a customer would. You'll notice things the developer can't, because you know how your customers think.

6. Launch checklist

Launch is short, but it's where the most expensive mistakes happen: lost search rankings, broken forms, enquiries landing in the wrong inbox. Our list:

• Redirects. If old URLs change, every old address points to its new one with a permanent (301) redirect. Google covers this in its site move guide.
• Indexing allowed. Staging noindex tags and robots.txt blocks are removed.
• Search Console. The site is verified in Google Search Console and the sitemap is submitted.
• Analytics and consent. Analytics works and only fires once the visitor has consented.
• Forms and notifications. Every form has been tried, and messages reach the right inbox.
• Integrations in live mode. Payments, delivery and bookings are out of test mode, and one real transaction has gone through.
• Titles and descriptions. Every page has its own title and description; a multilingual site has correct language tags.
• Domain and SSL. DNS is switched, HTTPS works, and the www and non-www addresses lead to the same place.
• 404 page. A missing address leads to a helpful page, not a blank error.
• Backup and rollback. Everyone knows how to go back to the previous version if needed.

We launch at the start of a working day, not on a Friday evening. That way we can react the same day if something unexpected happens.

What we need from you: access to your domain settings, Google accounts, and live accounts with payment or delivery partners. We recommend that every account is in your name and we only have access.

7. After launch: maintenance and further work

A website after launch isn't a finished building. It's a working tool. Dependencies need updates, partner APIs change, content goes stale.

In the first weeks we check:

• in Search Console, whether new pages are being indexed and old URLs redirect correctly;
• whether forms and bookings are bringing in enquiries;
• whether any page is slower than it seemed in testing.

Longer term, agree who is responsible for updates and security fixes, and how you'll request new changes. The code, domain and hosting should belong to you, so you can change developers if you ever need to.

What we need from you: one person who tells us when something in the business changes: a new product, new opening hours, a new partner.

When we're not the right fit

This whole process makes sense when the site is part of how you sell. That isn't always the case:

• You need a simple business card. Three pages and a contact form can be done well on an off-the-shelf platform, probably for less.
• There's no content, and nobody will create it. Then even the best build won't save the site. Start with the content.
• The deadline is next week. Proper discovery, testing and launch take time. When people rush, it's usually testing and redirects that get dropped.
• You want to edit everything yourself, every day. Then pick a platform whose editor you already know, or raise it right at the start in discovery.

Summary

A good web development process is predictable: discovery, content, design, build, testing, launch and maintenance, each with a clear result. The biggest delays usually come from missing content, scattered feedback and growing scope, not from the code. When you know up front what's expected of you at each stage, the project moves faster and the site reaches launch in good shape.

You can open and try the sites we've built in our work. If you're planning a new site or a rebuild, get in touch. We'll go through what your site needs to do and tell you honestly whether it needs a custom build.