Website Development Process

Simple websites While websites for different purposes and scope will have different processes, it generally follow the following steps:

  1. Initiation
  2. Plan
  3. Design
  4. Develop
  5. Test
  6. Deploy


The very first step in the process is the project initiation stage.  This is where you define the goals or objective of the site, who the target audiences are, and how it fits within the overall business strategy of your organization.  Stakeholders and/or sponsors are identified.  

  • Who is the site for?  Who are the audiences?
  • What is the primary purpose of the site?  Is it to inform, sell, or increase awareness?
  • How much time do we want visitors to spend on the site? What do we want them to do when they are on the site?
  • What core message do we need to deliver?
  • How will the site support our overall business objectives?

This is the most important step in the overall process – any changes to answers to above questions can have a cascading impact on later stages of the process.  You should make sure to spend enough time during the initiation stage to all answers.

If you are part of a larger organization and building the organization’s primary website, there can be multiple stakeholders.  Stakeholders can affect or can be affected by the website.  Make sure to keep them involved from the initiation stage and keep them informed throughout the process.  

In this stage, you do not have to go into details about the website or how it is built.  Those should be discussed in the next stage, Plan.  Your stakeholders may be non-technical and you should be able to talk to them without going into specific details or using technical lingos.  

Key outputs: project charter, statement of work, work proposal, etc.


After you have established the need to build a website, the next step is to plan.  This stage includes identifying requirements, establishing scope and timeline, and putting a team together.  You can start putting together a sitemap that will serve as a foundation for the design and development stages.  The sitemap should start with the home page and lay out all different pages and subpages.  The sitemap will help you understand how pages or content are related to each other as well as establishing scope for the website.  

Figure 1. Sample sitemap
Figure 1. Sample sitemap

During the Plan stage, you can also look at building wireframes.  Some consider it part of the design stage and some include it in the plan stage.  It doesn’t really matter as long as you do it at some point and do it before the design stage.  Wireframes are very important and are a stepping stone between the sitemap and designs.  I have seen many organizations skipping the wireframe stage and they paid the price later on during the design and development.  

Wireframe is basically a visual prototype of a website that focuses on layout and behavior. It usually doesn’t include any styling, color, or graphics. It’s like a blueprint to a house that shows the plan for plumbing and electricity without the interior design.  Layouts are usually divided into header, content, and footer.  Header section usually includes a logo and a navigation bar with menus.  Content includes the actual content for each page. Footer includes additional navigation, copyright, social media links, and contact information.  During the wireframe process, try to stay away from using the real content – or, if possible, just keep the text and images off from wireframes.  Try focusing on the layout of logo, navigation, content, and others as well as navigation between pages – how or where users will click to get to another screen.  I have seen that the more actual content or styling you include during wireframe, more distracted stakeholders will be from focusing on what the wireframes are really meant for.

Key outputs: requirements document, schedule, sitemap, wireframes


During the design stage, styling, colors, and graphics are added to wireframes.  A key output of this stage is a set of designs for all pages of the website that can be handed off to the developers to start building the site.  At this stage, there should not be any major changes to the layouts and behavior such as adding or removing sidebar menus, centering or left-aligning navigation menus, etc.  Those are locked down from the planning stage during the wireframe process.  

Depending on the purpose and size of the website, it may be recommended that you create a style guide.  Style guide identifies colors, font types and sizes, buttons and spacing so that all the pages of the website will be designed and built with consistency.  For example, a page may have heading, subheading, and body text.  You would not want the heading to be 26px on one page and 24px on another page or a call-to-action button to be blue on one page and light blue on another.  If your organization manages multiple websites, which is typical these days, then having a style guide helps you maintain consistency across all the websites.

Key outputs: style guide, mock designs

Figure 2. Sample from style guide
Figure 3. Another sample from style guide


When the designs are finalized and approved, the next step is the development.  Oftentimes, this step takes the most amount of time and resources – therefore, you must make sure that all sponsors and stakeholders approve the plan and designs before the development starts.  Once the development starts, any changes to the requirements, wireframe, or designs can cause significant time or resource.  

The development effort is usually broken up into frontend and backend development.  Frontend encompasses HTML, CSS, and JavaScript and includes pages, components, or widgets that interact with the end-users.  The backend includes interacting with the database for storing data, business rules and validations, and interaction with third-party systems through API.  The term “full stack developer” refers to a developer who does both frontend and backend programming.  Depending on the scope of your website, one full stack developer can build it alone or it may require a dedicated frontend and backend developer.  Sometimes there can be multiple frontend and multiple backend developers.  If the development requires a large team of developers, there should be a lead developer who integrates everything together.

Sometimes, depending on the scope of the project, I like to work on the frontend first and then move onto the backend rather than working on them together at the same time.  The benefit to doing this approach is when the frontend development is complete, you will have a working prototype of the website that can be clicked and navigated and tested on various different mobile devices.  The designs alone should show you what the final website will look like but if you have a tangible site that can be tested in a browser and can be shared with other stakeholders, you will have an opportunity to make changes and other improvements.  You may also notice that what you thought would work well from the designs may actually not be what you really envisioned when you have a working prototype of a website.

It is also important that the developers fully understand the requirements and have access to all the key deliverables generated from previous stages.  In fact, the developers should be involved from the planning stage to provide feedback and research for the best mix of tools and technologies to build the website.  

The output of this stage is a fully working website – with both frontend and backend – deployed to a test server where team members and other stakeholders can have access to from their computer.  At this point, the site is not public and is only visible to those with direct link or within VPN if the server is on the company network.  The site is built based on the approved designs, addresses all the business requirements, and has all the business rules and logic in place.  

Key outputs: fully working website on a test server


While developers conduct testing during the development, they are so deep in the weeds, ensuring that all the requirements are met and the site is developed in accordance with approved designs, that oftentimes they can miss very simple things.   They have been working on the site for weeks or months that they are so used to what they are seeing every day that they miss the most obvious things.  That is why for the testing stage, it is good to have a fresh set of eyes.  If you have the resources to hire a dedicated tester or an external agency to help with testing, that’s great.  If not, you can still form a testing team with resources you already have.

When I put together a testing team, I usually go for non-technical users who have not been part of the development or design teams.  If the testers are closer to the end-users in terms of demographic and profile, that is even better.  The testers should be given some direction from the project manager or lead developer on how the test should be conducted.  Usually called “testing script”, it lays out steps on properly testing a feature, component, page, or the entire website.  In a large organization or more formal setting, this process is also called the User Acceptance Testing or UAT where the customer or stakeholders formally sign off on acceptance of the website, indicating that everything works accordingly and meets all the requirements.


When the website is fully tested and free of any issues and bugs, then it is ready to be deployed to the production environment.  Some people get confused between testing and production environments.  Basically, if a site is published in a testing environment, the intended target audience is testers, design & development teams, stakeholders, and sponsors.  It is not ready to share with the entire world yet.  On the other hand, if the site is published in a production environment, it means that anyone can see the site from their browser from any location.

Deploying the site requires pushing the code and other assets such as images, scripts, stylesheets, to a publicly-accessible server.  In the old days, I used a FTP client to upload files to the server.  But these days, I prefer deploying using git push which makes things so much easier.  With just one command, you can push an entire website to a server.  Web hosting providers these days are supporting git push and, if the option is available, I always go with git push.  Git push is much faster and less error-prone than manual FTP upload.  

After pushing the site to a server, your team may want to do another quick round of testing on the public website to make sure that it is working correctly.  What used to work in a testing environment may not work correctly in a production environment.  You may also add analytics tracking code, submit the site to search engines, optimize the site for faster performance, and update any environment-specific settings.  For example, if your site has an e-commerce component, you may have been testing credit card processing using test API keys from a payment processing company.  After the site goes live, you want to replace those with live API keys.  Developers usually take care of those – last thing you want is a site in a production environment with all the test API keys.

Post-deployment Checklist:

  • Browse the site for any gotchas
  • Ensure API keys are pointing to the live services
  • Set up SSL (Secure Socket Layer) – https
  • Add analytics tracking code such as Google Analytics
  • Submit the site to search engines to be indexed
  • Ensure any test pages are removed
  • Ensure sitemap.xml is updated and available
  • Set up site monitoring tool to receive notifications when the site crashes
  • Communicate to everyone – internal teams, stakeholders, sponsors – that the site is live

Key outputs: website in a production environment

Leave a Reply

Your email address will not be published. Required fields are marked *