Website Development Process: How We Run a Project, Phase by Phase

The website development process is the ordered set of phases that takes a project from a first call to a live, maintained site. At Vezert it runs in six phases: discovery and planning, information architecture with UX and UI design, development, testing and QA, launch and handover, and post-launch support. Each phase ends with a named deliverable that you approve before the next one starts.

This guide describes how we actually run those phases, using the scope, steps and delivery windows published on our services and pricing pages. For each phase you get the goal, what our team does, what we need from you, the exit criteria, and how long it usually takes on a landing page compared with a web portal.

The six phases stay the same whatever the size of the build. What changes is depth. Discovery for a landing page is a 30-minute intake call; discovery for a portal is a paid two-week sprint that ends in a signed statement of work.

A website development process is a written order of work: who decides what, in which sequence, and against which deliverable. People also call it the website development life cycle. Most published guides list seven steps: information gathering, planning, design, content, coding, testing, and launch with maintenance. We group the same work into six phases, because planning and the sitemap belong with discovery and design, and content runs as its own track next to design and build.

Without that order, a build turns reactive. Decisions arrive late, priorities move, and the result drifts away from what the business asked for. The failure modes repeat across project sizes: scope that was never written down and keeps growing, approvals with no named owner, deadlines set before anyone counted the pages, and features nobody on the business side asked for.

A written process also gives you somewhere to stand. At any moment you can name the current phase, the open decision, and the date the next deliverable lands. That is how you tell a schedule that is behind from one that is waiting on you.

The table below is the short version of the whole process. Each row is one phase, with the goal it serves, what we deliver, what you provide, and the exit criteria we use to close it. A phase closes only when its deliverable has been approved in writing, which lets the next phase start on a fixed date instead of a hopeful one. The sections after the table go through each phase in detail.

Discovery turns a business goal into a written scope before any design or code. According to Nielsen Norman Group, the discovery phase is preliminary research into the problem space: framing the problem and gathering enough evidence to decide what to do next. In our process that research ends in a document both sides work from, and that document is what makes a fixed price and a fixed date possible.

How deep it goes depends on the project. For a landing page it is a 30-minute intake call that leaves us with the offer, the audience, the single success metric and the traffic source. For a corporate website it means stakeholder interviews with marketing, IT and procurement, plus an AI-assisted audit of the current site, its SEO and the competitors. For a portal it is a paid two-week discovery covering the problem statement, user personas, information architecture and a security and compliance plan, and it ends with a signed statement of work.

From you we need your goals and how you measure them, the existing materials (current site, analytics access, brand files), and one person who can approve decisions. If you already have a brief or an RFP, send it. Our guides on writing a website brief and what to put in a redesign RFP cover what helps most.

The phase closes with a written scope listing pages, functionality and integrations, a first sitemap, a dated milestone plan and a price. Scope, timeline and cost are agreed in writing before work starts. That written scope is also what makes competing proposals comparable while you are still choosing a web design agency.

On a landing page, discovery is day one. On a portal, it fills weeks one and two.

The second phase decides structure before style. We fix the sitemap and information architecture first, then the user flows and wireframes, and only then the visual design. Moving a section in a wireframe takes minutes. Moving it after the pages are built means rework in code, so most of the revision budget is either saved or spent here. This is the work our UX/UI design team runs on every project.

On a corporate site, the UX lead approves the final information architecture, while Claude Design generates three to five candidate structures to test it against. A senior designer then curates the template system and the art director sets the visual direction. On a landing page we produce three to five wireframe directions, narrow them to one, and you see a Figma link by the end of day three. On a portal, the phase delivers a design system, 15 to 30 high-fidelity screens, a clickable prototype and a WCAG 2.2 AA accessibility audit.

For how a sitemap gets planned, see our guide to website structure types. Smashing Magazine's website planning guide is a good outside reference on sitemaps, URL structure and deciding who produces which content.

From you we need brand assets in editable formats (logo files, fonts, any guidelines) and feedback inside the agreed review window. On a landing page you review the design twice, once at the midpoint and once at the end. The phase closes when the sitemap, wireframes and visual design are approved, and nothing goes to development without that sign-off.

On a landing page with copy variants, design runs from day two to day six. On a portal, it takes weeks three and four.

Development builds the approved design into a working site on a staging URL you can click through. It is the longest phase on most projects and the one where a frozen scope pays for itself, because every change that arrives now touches code instead of a wireframe. AI coding tools draft parts of the work, and a senior engineer reviews and owns every line before it is merged.

Pages are built from reusable components, content goes into the real structure, and integrations such as CRM, analytics, payments or single sign-on are wired and tested. The stack is agreed in discovery. Next.js is our default for corporate sites and portals, and landing pages can also ship in Webflow or WordPress. On a portal, code agents scaffold the React and Next.js components and the backend APIs, and a tech lead validates security and runs a code review before merge. Our guides to AI-first web development and custom web development cover the working method in more depth.

From you we need final page copy, images, product or service data, and credentials for every integration. Pages built around placeholder text tend to get reworked twice: once when the real copy arrives, and again when it does not fit the layout.

The phase closes with a feature-complete staging build. On a landing page with copy variants, development runs from day five to day eight, and the staging link arrives on day eight. On a portal, the build takes weeks five to seven.

Testing checks the staging build under real conditions before anyone outside the project sees it. We combine a manual walk-through on real devices with automated sweeps for accessibility, Core Web Vitals and broken links, and the findings come back as a shared fix list with owners. Treating QA as its own phase, with its own exit criteria, is what separates a launch date from a launch guess.

Performance is measured against Google's Core Web Vitals thresholds: Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint within 200 milliseconds, and Cumulative Layout Shift of 0.1 or less. We also check responsive layouts across devices, forms and analytics events, and baseline WCAG accessibility at the 2.2 AA level. Corporate builds get regression checks on every commit. Portals add Playwright end-to-end tests, SAST and DAST security scans and, on compliance-heavy projects, an external penetration test. Our website quality checklist lists the pass thresholds we hold a build to.

From you we need one review of the staging build, with change requests collected into a single list instead of arriving one at a time over two weeks. The phase closes when the fix list is empty and you sign off the staging build.

On a landing page, QA takes days eight and nine. On a portal, testing runs inside the build weeks and finishes with the security sign-off in launch week.

Launch moves the approved build to production and hands the project over to you. The work is infrastructure rather than design: DNS, hosting, redirects from old URLs, analytics and search console, and a final pass over metadata. It is the shortest phase and the one with the least room for improvisation, so it runs from a checklist. Our website launch checklist is the version we work through before go-live.

A project manager coordinates the cutover. On a redesign, the redirect map from every old URL that had traffic is easy to skip and expensive to forget, because it is what protects existing rankings; our website migration guide covers it step by step. After go-live, an AI agent watches Core Web Vitals, 404 errors and crawler errors through the first week, and a person acts on what it reports.

Handover documentation ships with the site. On a landing page that means architecture notes, the analytics event schema and a 10-minute recorded walk-through. On a portal it means written documentation and a recorded knowledge-transfer session.

From you we need domain and DNS access, analytics and search console accounts, and your legal pages (privacy policy, cookie notice, terms). Missing access is a common reason a launch date moves for reasons that have nothing to do with the build. The phase closes when the site is live, redirects and analytics are verified, and code, design files and accounts are in your name. On a landing page with copy variants that is day ten; on a portal, week eight.

Launch starts the measurement period. Once real visitors arrive, the site produces data that no planning session can supply: which pages get read, where forms are abandoned, which devices struggle. Every package on our pricing page includes a support window after go-live: 7 days for a landing page, 2 weeks for a corporate website and 1 month for a portal.

After that window, ongoing work moves to a separate, optional agreement. A website maintenance care plan covers uptime, security, backups and updates. An SEO retainer covers search visibility. On landing pages, a conversion retainer has an AI agent read heatmaps and GA4 data every week, and a senior CRO specialist approves which experiment ships next. Design and development is a one-time fee, and nothing recurring is bundled into it.

From you we need business context for the numbers and a decision on priorities for each cycle. A dashboard nobody acts on is just storage. On a retainer, the work is reviewed in a monthly report rather than closed by a single sign-off.

Content is the input most likely to hold a schedule up, so we treat it as its own track that runs next to design and development instead of a single step after them. The sitemap from phase two tells you which pages need copy, and the wireframes show roughly how long each block should be. Copy written against the wireframe tends to fit the first time.

There are three ways to handle it. You write it, and we agree a date for final copy before development starts. We write it: copywriting is an add-on in our pricing, and on landing page bundles a copy agent drafts three headline and CTA variants that a senior copywriter edits and signs off. Or the work is split, which is common on corporate sites: we write the conversion pages, and your team supplies the specialist pages only it can write. Our guide to website content covers what each page needs and who usually writes it.

Whichever route you choose, settle it in discovery. A content decision left until development is one of the most reliable ways for a build to slip.

Feedback happens at fixed points rather than continuously. Each phase has a review tied to its deliverable: the scope, the wireframes, the visual design, the staging build. You get a review window, you send one consolidated set of comments, and we revise. On a landing page package, for example, you review the design at the midpoint and at the end, and the copy includes one round of revisions.

A change request is anything that adds to or alters the approved scope: a new page, a new integration, a feature nobody mentioned in discovery. It is a decision with a price and a date attached. When scope changes mid-project, we agree the adjustment in writing before the work starts, and each addition (extra pages, animations, copywriting, languages, integrations) carries a defined add-on cost listed in the proposal. You can also move up to a larger package at any stage.

Two habits keep rounds short. Collect comments from every stakeholder before sending them, so the team does not get three conflicting notes on the same page. And comment on the deliverable in front of you: a wireframe review is for structure and order, not for colors.

You do. Code ships to your repository, design files move to your accounts, and any AI-agent prompts developed for your project are yours to keep. On portals, delivery includes full source code, deployment rights and IP assignment, so you can self-host, change cloud provider or end the engagement and the portal keeps running. We retain no exclusive rights over your brand assets.

Ownership only holds if the accounts are in your name, so the handover covers more than code. Before launch, confirm who holds each of these: the domain registrar account, DNS, hosting, the code repository, analytics and search console, and every third-party integration with its API keys. We usually deploy on Vercel, and hosting through us is optional. If any agency holds one of these under its own login, ask for the transfer in writing before the final invoice.

AI drafts and people decide. Vezert CEO Lena Tarhonska describes the rule this way: "The split is simple: humans decide, AI drafts." In practice we use Claude Design to propose wireframe directions and component variants, AI coding assistants to draft components and tests, and QA agents to sweep accessibility, Core Web Vitals and broken links. Every AI output passes through a senior reviewer before it reaches you.

Architecture, security, information architecture, final design and sign-off stay with named people. For portals, our process page estimates the AI share by phase: about 30% in discovery, 55% in design, 60% in build and 50% at launch, where it mostly writes test suites and documentation. On corporate projects we redact personal data before any model call and can route AI workloads through EU-region endpoints.

You can also opt out. A corporate site built fully by hand moves from 4 to 8 weeks to 8 to 14 weeks and costs roughly 25% more. On portals, Traditional Mode costs 25% more and takes about 1.5 times as long. People often ask whether ChatGPT can build a website. A general chatbot can write the code for a simple page, but the work in this process that carries risk (scope, structure, review, and accountability for the launch) still needs people.

At our standard delivery windows, which are included in the base price, the process takes 2 to 5 days for a landing page, 2 to 4 weeks for a corporate website and 6 to 12 weeks for a web portal. Larger tiers run longer, and rush delivery under 48 hours is possible on small scopes for 25% extra. For what moves a schedule and how our windows compare with industry ranges, see the website development timeline guide.

Those windows assume content and approvals arrive on the dates in the plan. On corporate projects, the split by phase is committed in writing at the end of discovery, before design work starts.

Three inputs unblock the whole first half of the process, so prepare them before the first call. You need a named decision-maker who can approve a wireframe without convening a committee, a decision on who writes the content, and brand assets in editable formats. Everything else can be gathered during discovery. The table shows what each phase needs from your side and what happens when it arrives late.

When you compare proposals, ask about the process rather than the portfolio. Both a structured team and an improvised one can show a good-looking page. Only one of them can tell you in week two what will be true in week six. These questions separate them quickly:

• Which deliverable closes each phase, and who signs it off?
• How many feedback rounds are included, and how are change requests priced?
• What do you need from us, and by which date?
• Whose name will the domain, hosting, repository and analytics accounts be in at launch?
• Where do you use AI, and who reviews its output?

Vezert runs the same six phases on every project, from a single landing page to a multilingual portal. Send us your page count and target date, and within 24 hours you get a written quote with the phase plan and a date against each milestone.