Website Development Process At a Glance
- Discovery and strategy
- Information architecture and content planning
- UX design and prototyping
- Visual design
- Development
- QA testing and accessibility review
- Launch
- Post-launch optimisation and support
Most website projects start well. There’s genuine enthusiasm, a clear brief, and a shared sense of purpose. Then, somewhere around the third round of design revisions, the project stalls. Scope expands. Timelines slip. The stakeholder who wasn’t in the room during discovery has strong opinions about the homepage. The launch date moves again.
This is not unusual. And it is almost never caused by a technical failure.
The root cause is almost always process — or the absence of one. Most people commissioning a website have never been walked through what actually happens between the initial brief and the site going live. Without that map, it is genuinely difficult to manage expectations, make timely decisions, or tell which problems are normal and which are signs of something going wrong.
This guide explains every phase of a professional website development process: what happens, what you as the client are responsible for, and what to watch out for at each stage.
What Is the Website Development Process?
The website development process is the structured sequence of stages required to plan, design, build, test, and launch a website. It typically includes discovery, architecture, design, development, testing, launch, and ongoing optimisation. Most professional projects follow 6-10 distinct phases depending on scope and complexity.
International standards for software and website engineering including ISO/IEC/IEEE 23026:2023, which defines engineering and management requirements for the full website life cycle formalise this as a series of managed phases rather than a single sprint. A good process is not bureaucracy. It is the mechanism by which projects stay on track and deliver what was originally promised.
Why process matters more than tools
A common mistake is focusing on the technology stack which CMS, which platform, which framework before the process is established. The choice of tools matters far less than whether the project has a clear discovery phase, explicit sign-off points, and a shared understanding of who decides what and when.
The two dominant process approaches are waterfall and agile. Waterfall moves sequentially each phase is completed and signed off before the next begins. Agile works in iterative cycles, with continuous feedback and adjustment. Most professional website projects use a hybrid: structured discovery and design phases (waterfall logic) with iterative development and testing cycles (agile logic). The right balance depends on scope, team maturity, and how well the requirements are defined at the outset.
Phase 1: Discovery and Strategy
Discovery is the most important phase in the project. It is also the one most often rushed.
The purpose of discovery is to define with precision the business goals, audience needs, technical constraints, and success metrics for the site before a single wireframe or line of code is produced. A typical discovery phase includes stakeholder interviews, competitor analysis, user research, technology selection, and the definition of measurable KPIs.
The decisions made in discovery shape everything that follows. Architectural decisions made without clear requirements create rework. Design decisions made without audience insight create aesthetically pleasing pages that do not convert. Technology decisions made without IT input create integration headaches six months after launch.
Research on software life cycle management — including ISO/IEC/IEEE 12207:2017, the international standard for software life cycle processes — treats requirements definition as a foundational activity precisely because errors caught at this stage cost a fraction of what they cost to fix after development has begun.
Your role as the client at this stage: bring the right people into the room. The marketing manager who owns the brief, the IT lead who will manage the platform, and the CEO or business owner who has ultimate sign-off authority on scope and budget. Disagreements that surface in discovery are productive. Disagreements that surface in the visual design phase are expensive.
Not sure where to start with your website project? Butterfly’s discovery process gives you clarity before a dollar is spent on design or development. Request a discovery session →
Phase 2: Information Architecture and Content Planning
Information architecture (IA) is the structural blueprint of the site. It defines which pages exist, how they relate to each other, how users navigate between them, and what content lives where.
A sitemap produced at this stage is not just a list of pages. It is a statement of how the organisation wants users to move through its digital environment from landing to conversion, or from question to answer. Getting this right before any design work begins prevents one of the most common and costly problems in web development: retrofitting content into a design that was never built to accommodate it.
Content must be defined before design begins. Not written in full, necessarily, but defined: what is the purpose of this page? What does the user need to learn, feel, or do here? What existing content can be repurposed and what needs to be created from scratch?
The common mistake: designing before the content is ready
Designers working without real content use placeholder text to fill space. The visual hierarchy they create — the relative prominence of headings, the length of introductory paragraphs, the size of call-to-action buttons — is built around a fiction. When the real content arrives, it rarely fits. Sections that were elegant with placeholder copy become cluttered with the actual message. Images that worked as placeholders don’t work with the real brand assets.
The fix is straightforward: lock the content model before locking the design. You do not need every word written, but you need to know what each element of the page will contain and approximately how much of it there will be.
Your role as the client at this stage: provide source material existing documents, brand guidelines, approved messaging, product or service descriptions. Make stakeholder alignment decisions early. If there are internal disagreements about what the site should say or prioritise, surface them here, not in the design review.
Phase 3: UX Design and Prototyping
UX (user experience) design translates the information architecture into a testable skeleton of the site. The primary outputs are wireframes — structural layouts of each page that show content placement, navigation behaviour, and interaction flows — and interactive prototypes that allow stakeholders to experience the site before a single visual design decision has been made.
This phase exists because feedback is cheapest when it is acted on earliest. A wireframe can be revised in hours. A fully designed and developed page takes days or weeks to change. Reviewing a prototype with the right people before the visual design begins prevents the single most common cause of design rework: a stakeholder seeing for the first time, in the visual design review, what the site actually does.
Your role as the client at this stage: bring specific, structured feedback to prototype reviews. “The navigation does not reflect our service structure” is actionable. “I don’t like the feel of it” is not. Identify which stakeholders have decision-making authority over UX sign-off and make sure those people, not peripheral observers, are the ones reviewing the prototype.
Phase 4: Visual Design
Visual design takes the approved UX prototype and applies the organisation’s brand expression — typography, colour, imagery, iconography — to produce a fully designed layout. The output is typically a style guide and a component library: a documented set of reusable visual elements that the development team will build from.
A well-executed visual design phase produces designs across multiple breakpoints: desktop, tablet, and mobile. This matters because a layout that works at 1440 pixels wide may be entirely non-functional at 375 pixels. Signing off on a desktop design without seeing the responsive states is one of the most common client mistakes in this phase.
Your role as the client at this stage: clarify who has final sign-off authority before the review begins. Design feedback is most useful when it is consolidated from all stakeholders into a single round of revisions, not delivered sequentially from multiple people with conflicting priorities.
Phase 5: Development
Development translates the approved designs into a working website. This involves both front-end work — the visual layer that users interact with and back-end work the systems, databases, and logic that power the site’s functionality.
Most professional projects also involve CMS configuration (the system that allows content editors to manage the site without developer involvement), and integration with third-party platforms CRM systems, marketing automation tools, analytics platforms, accessibility monitoring services.
Your role as the client at this stage: your direct involvement is limited, but timely delivery of final content and assets is critical. Delays in content handover are one of the most consistent causes of timeline overruns at this stage.
What accessibility means in web development
Accessibility is not a feature to be added at the end. It is a quality standard built into every layer of development.
For Australian organisations in government, education, healthcare, and not-for-profit sectors, WCAG compliance carries legal weight. The Australian Human Rights Commission is clear that WCAG is the accepted international standard under the Disability Discrimination Act. In 2025, Australia formally adopted WCAG 2.2 Level AA as the minimum benchmark for digital accessibility. A 2026 guide to DDA compliance confirms that web accessibility complaints and legal actions are increasing, and that all public-facing websites are expected to meet this standard.
What this means in practice: developers must write semantic HTML, provide text alternatives for non-text content, ensure keyboard navigability, maintain sufficient colour contrast, and build interfaces that work with assistive technologies including screen readers. These are not cosmetic considerations. They are functional requirements that affect whether a portion of your audience can use the site at all.
Accessibility built into the development phase costs significantly less than accessibility retrofitted after launch.
Phase 6: Testing and Quality Assurance
QA is the systematic verification that the site works as intended across the full range of devices, browsers, user scenarios, and technical conditions. A thorough QA phase covers cross-browser and device testing, performance benchmarking, security review, and a structured accessibility audit.
Accessibility testing is not a checkbox at the end of QA. It is a distinct activity that requires testing with real assistive technologies not just automated scanning tools, which catch a subset of issues but miss many others. Automated tools can identify contrast failures and missing alt text. They cannot tell you whether a screen reader user can actually navigate and complete a task on the site.
Your role as the client at this stage: user acceptance testing (UAT). UAT is your formal opportunity to verify that the site meets the agreed requirements before launch. It is not an opportunity to redesign or expand scope. You are being asked to verify that the site does what was agreed. Document and submit issues clearly, with descriptions, screenshots, and the device or browser on which they were observed.
Phase 7: Launch
Launch involves the technical transfer of the site from a staging environment to the live server — updating DNS records, activating the SSL certificate, configuring redirects from old URLs to new ones, and completing the final deployment sequence.
Pre-Launch Checklist
- UAT sign-off completed
- 301 redirects configured (if replacing an existing site)
- Google Analytics / GA4 configured and verified
- Search Console submitted and site crawled
- SSL certificate active
- Accessibility audit completed and critical issues resolved
- Performance benchmark recorded
- Backup of staging environment retained
A soft launch — releasing to a limited audience or with restricted promotion before full go-live — is useful for high-stakes projects where real-world testing at scale is preferable to a single hard launch event. A hard launch is appropriate for most projects where UAT has been thorough and the client is ready to drive traffic immediately.
Your role as the client at this stage: formal written approval of the launch, and a communications plan. Existing audiences, email subscribers, and social channels may need to be notified. Internal teams who manage content or respond to enquiries from the website need to be briefed.
Phase 8: Post-Launch Optimisation and Support
Launch is not the end of the project. It is the beginning of the optimisation cycle.
A live site generates real data GA4 analytics, Search Console performance reports, heat maps, user feedback that a staging environment cannot. The first 60–90 days post-launch are the most valuable period for identifying how real users are actually navigating the site, which pages are underperforming, and where the gaps between intended behaviour and actual behaviour are widest.
Post-launch support covers bug fixes, minor content updates, CMS training, security patches, and ongoing accessibility monitoring. A support retainer provides a structured, predictable way to manage this. Ad hoc fixes, by contrast, are slower to action and typically more expensive per hour when urgent.
For organisations with active SEO goals, the post-launch period is also when Search Console data begins to reflect the new site’s indexing status, keyword coverage, and crawl health.
How long does website development take?
Timelines vary significantly based on scope, complexity, and most importantly how prepared the client organisation is. Practical analyses of web project timelines consistently show that focused custom marketing sites with clear scope tend to complete in roughly 8–12 weeks, while projects with deeper UX work and system integrations typically require 12–20 weeks.
Broader industry benchmarks break down as follows:
| Project type | Indicative timeline |
|---|---|
| Simple brochure or landing-page site | 4–8 weeks |
| Mid-complexity organisational site | 8–16 weeks |
| Enterprise platform with integrations | 4–12 months |
These are guides, not guarantees. Industry data on project complexity consistently identifies the same two variables as the primary drivers of timeline overruns: content readiness and stakeholder feedback speed. Both are within the client’s control.
Website development milestones — what to track
These are the formal decision points in a well-managed project. Each represents a sign-off that gates the next phase:
- Discovery completion and strategy sign-off
- Sitemap and IA approval
- Wireframe and UX prototype approval
- Visual design approval (across all breakpoints)
- UAT completion and sign-off
- Pre-launch checklist verified
- Launch approval
Tracking these milestones — not just the overall delivery date — gives you visibility over where the project is at any point and makes it straightforward to identify if and why a delay is occurring.
Agency vs In-House vs Outsourced Development
For organisations without a mature in-house development capability, the choice is typically between building a team or engaging an agency.
In-house teams offer institutional knowledge and direct alignment with organisational goals. They are effective when digital output is frequent, varied, and sufficiently complex to justify full-time headcount. They are less effective when capability gaps exist particularly in specialised areas like accessibility, security, or CMS architecture or when the organisation’s digital needs are project-based rather than continuous.
Agencies provide process maturity, a breadth of specialist skills, and post-launch support capability that most in-house teams take years to build. For compliance-sensitive projects government platforms, healthcare portals, education environments an experienced agency’s familiarity with WCAG standards, privacy obligations, and security frameworks is a practical risk reduction, not just a procurement preference.
The decision should be based on capability and risk, not simply cost. A poorly executed in-house build that requires a complete rebuild two years later is more expensive than a well-scoped agency engagement from the outset.
Frequently Asked Questions about Website Development Process
The website development process typically includes: discovery and strategy, information architecture, UX design and prototyping, visual design, development, testing and QA, launch, and post-launch optimisation.
Timelines vary by complexity. A straightforward organisational website may take 8–16 weeks. A complex enterprise platform can take 4–12 months. Content readiness and stakeholder feedback speed are the most common causes of delays. On average, every phase in website development could take:
Data gathering – 1 to 2 weeks
Planning stage – 2 to 6 weeks
Design phase – 4 to 12 weeks
Development stage, including content and coding phase – 5 to 15 weeks
Testing phase – 2 to 4 weeks
Launching – 1 day to 2 weeks
Maintenance – ongoing
Discovery. Before any design or code begins, a structured discovery phase defines business goals, audience needs, technical requirements, and success metrics. Skipping or rushing discovery is the most common cause of project failure downstream.
Discovery, information architecture, UX design, visual design, development, testing and QA, and launch. Most professional projects include an eighth stage: post-launch optimisation and support.
Cost depends on scope, complexity, integrations, and the experience of the team. Contact a web development agency directly with your brief for an accurate estimate. Generic price lists rarely reflect real-world project requirements.
For organisations without a mature internal development team, an experienced agency provides process rigour, specialist skills, and post-launch support that in-house teams often cannot match particularly for compliance-sensitive projects requiring WCAG or security expertise.
Accessibility in web development means building sites that work for people with disabilities including those using screen readers, keyboard navigation, or other assistive technologies. In Australia, WCAG 2.2 Level AA is the minimum standard expected under the Disability Discrimination Act for public-facing websites.
The Project Is Manageable. The Process Makes It So.
Website projects do not fail because web development is inherently unpredictable. They fail because the process was unclear, the right people were not involved at the right stages, or critical decisions were deferred until they became crises.
A structured process does not remove complexity. It makes complexity visible and therefore manageable. You know what decisions are coming, when they need to be made, and what happens if they are delayed. That is a very different experience from the project that starts well and then quietly derails.
If you are planning a new website or a significant rebuild, the most valuable investment you can make before the project begins is a clear picture of the process — what will happen, when, and what will be asked of you.
Ready to build a website that performs? Talk to Butterfly about your project. We will walk you through our process and give you a clear picture of scope, timeline, and investment. Get in touch
