One of the most common sources of anxiety for anyone about to commission a website is simple: not knowing what's actually going to happen after they say yes.

Will the agency disappear for weeks and resurface with something unrecognizable? Will the timeline they quoted hold up? Will there be endless rounds of revisions, or none at all? Who do you talk to if something needs to change? What happens if you don't like the design?

These aren't unreasonable concerns. They come from real experiences: the freelancer who went quiet, the agency that delivered something nobody asked for, the project that was supposed to take six weeks and took six months.

This post is that process, laid out in full. Here's exactly what happens when you work with WRTeam, from the first conversation to the moment your site goes live and what happens after.

Step 1: The Brief and Initial Conversation

Every project starts with understanding what you actually need, not what we assume you need based on a one-line inquiry.

If you've already written a detailed brief, that document becomes the starting point for this conversation. If you haven't, we work through the same areas with you directly: your business and what this website needs to achieve, who it's for, what functionality it requires, your design direction and any existing brand assets, your content situation, any technical constraints or integrations, and your budget and timeline.

This conversation is not a sales pitch. It's a scoping exercise. The goal is to understand your project well enough to give you an accurate picture of what it will take in time, cost, and effort before anything is agreed.

If your project would genuinely be better served by a different approach than what you initially asked for a landing page instead of a full site, WordPress instead of custom development, a phased build instead of everything at once that gets discussed here, openly, with the reasoning explained.

Step 2: Scoping and Proposal

Based on the brief conversation, we put together a project specification, a written document that captures exactly what's being built, how, and on what timeline.

This specification covers the page structure and functionality agreed, the platform and technical approach (and why), the design direction and number of revision rounds included, the content responsibilities what we provide versus what you provide, the project timeline broken into phases with milestones, and the cost, structured around milestone-based payments rather than a single upfront sum.

This document is the reference point for the entire project. If a question comes up later about what was included or agreed, this is where the answer lives for both sides. Nothing about the project should come as a surprise to either party once this specification is signed off, because everything that matters has already been written down and agreed.

This is also the point where, if your budget and our scoped recommendation don't align, that gets addressed directly. Sometimes that means adjusting scope. Sometimes it means a phased approach building the essential first version now, with additional functionality planned for a later phase. What it doesn't mean is quietly underscoping the proposal to win the project and dealing with the gap later through change requests. 

Step 3: Design Wireframes First, Then Visual Design

Design happens in two stages, and both involve you directly.

Wireframes

Before any visual design begins, we produce wireframes structural layouts that show how content is organized on each page, without colors, fonts, or finished visuals. Wireframes answer questions like: where does the navigation sit, what's the hierarchy of information on the homepage, how is the product page structured, where do calls to action appear.

This stage exists because structural decisions are far cheaper to change at the wireframe stage than after visual design is complete. A wireframe takes minutes to revise. A finished mockup with the wrong structure means redoing the visual design work as well.

You review the wireframes, provide feedback, and we adjust before moving forward. This is typically a fast cycle wireframes for a standard project are usually reviewed and approved within a few days.

Visual Design

Once the structure is agreed, we move to high-fidelity design the actual look of the site, applying your brand colors, typography, imagery direction, and visual style to the approved wireframe structure.

You'll see designs for key page templates, typically the homepage and one or two representative interior pages rather than every individual page, since most interior pages follow a consistent template. Reviewing and approving the template designs effectively approves the visual direction for the whole site.

Standard projects include two to three rounds of design revisions, as agreed in the project specification. This is enough for genuine refinement without becoming an open-ended process and it's specified upfront precisely so there's no ambiguity about what's included.

Step 4: Development

With designs approved, development begins. This is the phase where the approved designs become a working website.

For most business websites, this means building out the site on WordPress (or the platform agreed in the specification) implementing the approved templates, configuring the CMS so you can manage content independently, building out functionality (forms, integrations, eCommerce features, or whatever was scoped), and setting up the technical foundations, image optimization, and performance configuration from the start, not as an afterthought.

Development typically requires less day-to-day input from you than the design phase, but it isn't a black box. If questions arise during development of an edge case the brief didn't cover, a piece of content that doesn't fit the designed layout as expected, a decision about how a specific feature should behave, those questions come to you promptly, because resolving them quickly keeps the project on schedule.

Step 5: Content Integration

Once the site is built, your content copy, images, product information, anything else gets placed into the live structure.

If you're providing content, this phase moves at the pace content arrives. We'll have flagged content requirements early ideally at the brief stage specifically so this isn't a surprise late in the project. If content isn't ready when development reaches this stage, we can either proceed with placeholder content and complete this step once your content arrives, or adjust the schedule whichever keeps the project moving most sensibly.

If content creation copywriting, photography was part of the agreed scope, this is where that work gets delivered and integrated.

Step 6: Testing and Quality Assurance

Before anything goes live, the site goes through a structured testing process.

This includes checking the site across major browsers and devices desktop, tablet, and mobile, across the browsers your audience actually uses. Testing every form, checkout flow, or interactive element to confirm it works correctly and sends data where it should. Checking links, navigation, and redirects is particularly important if this is a redesign replacing an existing site, where broken old URLs can damage SEO if not handled correctly. Running performance checks against Core Web Vitals thresholds. And reviewing the CMS from the perspective of whoever on your team will be using it day to day confirming it's configured sensibly and that the content management experience makes sense.

Issues found here get fixed before launch, not discovered by your customers after.

Step 7: Launch

Launch day itself is typically straightforward if everything before it has gone to plan which is the point of every preceding step.

This involves final DNS and hosting configuration, SSL setup and verification, final checks on the live environment (some things only become visible once a site is in its production environment rather than a staging one), and for redesigns making sure old URLs redirect correctly to their new equivalents, protecting search rankings built up over time.

We monitor closely in the days immediately following launch. Real-world traffic occasionally surfaces when staging environments don't have a caching configuration that needs adjusting, a form that behaves differently under live conditions. Catching and resolving these quickly in the first days post-launch is part of the process, not a separate billable event.

Step 8: Handover and What Happens Next

Launch isn't the end of the relationship, it's the point where you take over day-to-day ownership with everything you need to do so confidently.

This includes documentation covering how to use your CMS for common tasks, a walkthrough session covering anything specific to your site's setup, and a clear discussion of ongoing costs and options including hosting, maintenance, and what happens if something needs updating six months from now.

If you want an ongoing maintenance arrangement, regular updates, monitoring, and a point of contact for changes and additions that's set up at this stage, with clear terms agreed upfront rather than negotiated reactively when something breaks.

What This Process Is Designed to Prevent

Every step above maps directly to a failure mode. Scoping before quoting prevents the budget surprises that come from vague initial pricing. A written specification prevents disputes about what was agreed. Wireframes before visual design prevent expensive late-stage structural changes. Defined revision rounds prevent open-ended design cycles. Milestone-based payment protects you financially throughout. Structured testing prevents launching with problems your customers discover first. And a defined handover and support conversation prevents the post-launch abandonment that leaves businesses stranded with a site nobody can maintain.

None of this is unusual or proprietary. It's what a properly run web development process looks like. The reason it's worth laying out explicitly is that, not every vendor runs a process like this and knowing what good looks like is the best protection you have when evaluating who to work with.

Typical Timelines Through This Process

For a standard business website with CMS, this process typically runs six to ten weeks from signed specification to launch, broken roughly as: one to two weeks for scoping and specification, two to three weeks for wireframes and design, three to five weeks for development, one to two weeks for content integration (running partly in parallel with development), one to two weeks for testing, and a few days for launch and initial monitoring.

eCommerce and more complex builds extend these phases proportionally. The phases themselves don't change the time within each one.

Starting the Process

If you're at the point of being ready to start a project or close enough that a detailed conversation would help you get there the first step is the brief conversation described above. If you've already drafted a brief using our guide, bring it. If you haven't, we'll work through it together.

Either way, the goal of that first conversation is the same: make sure that by the time anything is agreed, you know exactly what's going to happen, when, and what it will cost with no part of this process happening to you without your visibility into it.