7 Steps to Creating a Web Application

A developer with headphones, 3 monitors maybe coding a program

We examine 7 steps to creating a web application. Consider these 7 steps for your next web application build.

Creating a web application is a multistep process that can be managed in different ways, typically one of two ways. The two main project management approaches used are: the waterfall approach and the iterative approach. When building iteratively, one may use an agile approach or some other method, but the end result will always be building the application by designing, developing, deploying and testing in iterations.

Waterfall

The waterfall method involves setting clear goals and deliverables at the outset of the project with limited changes made during the creation of the entire web application.

Iterative

In an iterative approach, the application is built a piece at a time, such as by features. This method has become increasingly popular due to its ability to get more immediate feedback on the usability and applicability of a particular change. As changes come in, the project sponsors and users are able to more easily understand how the changes impacted the web application. With that understanding, changes can be easily made since they are not entrenched in a rigidly structured specification that is not designed to be changed.

The Winner Is?

While both methods can be used to successfully develop a web application, many find that using an iterative software development approach is a great way to ensure application quality while also reducing the amount of resources necessary for successful completion. By breaking down projects into smaller tasks and cycles that are implemented over time, developers can make relatively small adjustments on each successive iteration. This makes it easier to identify issues early in the process, which ultimately reduces costs associated with finding and fixing errors later in the project when features are added atop previously created features.

Whether using waterfall or an iterative method of managing the creation of a web application, there are similar steps taken. The main difference lies in the scope of the changes. For a waterfall development project, the entire application is usually created all at once. The steps we’ll look at here in a moment are to be completed in succession and not reiterated.

By utilizing an iterative approach to development, a web application is built by following similar steps, iteratively, each time until it contains the required features for its intended use case (the full application is built). This method of construction ensures that the application provides all the desired capabilities and is capable of achieving some desired business outcome.

Here are the steps that are typically taken to create a web application (linked sections):

Contents

Step 1

Gathering and defining the requirements for the project

Step 2

Selecting an appropriate technology stack

Step 3

Designing the user interface of the application

Step 4

Designing the backend and data storage for the application

Step 5

Programming against the design

Step 6

Testing and deploying the newly created solution to ensure its proper functioning

Step 7

Maintaining and improving it over time with new features or bug fixes

Now we will consider each of these steps in turn.

1. Gathering and defining the requirements for the project

Two people discussing with post-it notes and whiteboard

Requirements Consideration

Regardless of your development approach, requirements are always necessary. Based on the needs of the team, the scope of the amount of work to be done, the complexity of the requirements and any other considerations the team wants to place on the requirements standards, there may be many approaches to documenting what needs to be done.

Another advantage to developing a web application iteratively is that the consequences of poorly conceived standards are much less because the team can acknowledge shortcomings and make adjustments with future iterations.

With the waterfall approach, there will be a much longer requirement definition phase to the project. In such a project management approach the requirements will be for the entire web application, so it will take time to plan for all the requirements and ensure that any potential issues are addressed before moving forward in development.

User Stories

When determining the specifications for a feature, the user story is a frequently used approach. A user story is a specific format for capturing the user’s needs and desired features for the web application. It typically has an “As a (user role), I want (desired functionality) so that (benefit)” format. It defines the feature in the words of the user and provides a framework for developers and other stakeholders to understand what is going to be built and for what reasons. This helps to reduce confusion and increase the understanding of the intention for the development effort. In a perfect world, it helps to reduce the disconnect between business people and the technical team.

Complimenting this user story, we might also include a list of acceptance criteria, which will help to ensure that the web application meets all the necessary requirements. Acceptance criteria are conditions that must be fulfilled in order for a feature or requirement to be considered “done”. This can even go as far as defining test cases and scenarios.

Visuals

We might also include mock web pages, wireframes or prototypes to help illustrate the desired features. A prototype is an initial version of a web page that is used to demonstrate and iterate on design concepts. Some of these elements may well have been created in the proof of concept to establish the business case for needing the web application.

These types of visual elements are more necessary with a waterfall approach. By creating them, the designer is able to minimize the impact of not having iterations in the development phase of the creation of the web application. The iterations are actually happening during the design phase.

I would argue that it is more profitable, regardless of the type of project, to do this type of work before entering the development phase. Undoubtedly, iteration on development projects will help to address problems with original concepts and be less expensive than making the same mistake in a waterfall type of project. It is always less costly, however, to make adjustments to drawings rather than rewriting software programs.

2. Selecting an appropriate technology stack

The Main Language

Once the requirements are identified, the next step is to select an appropriate technology stack for building the web application. The team should take into account their own competencies and the popularity of a programming language when selecting the programming language.

A popular language may be easier to use by existing team members, but it also comes with additional considerations such as finding support materials that could help developers out of a jam. One may also find it easier to find software developers, both now during the initial project build, and later if additional personnel are needed.

This language is considered “the backend” of the application and is used to interface with the database.

Data Storage

The data storage approach is also important. There are different types of databases that provide different types of functionality and better solve certain use cases. One may decide to use a document storage solution for a web application, or portion of a web application, whereas a relational database may be better suited for a web application, or portion of it, with more complex data relationships. Some databases merge the two ideas and offer both capabilities. One must weigh a number of factors in making the best choice.

Frameworks

Third-party libraries and frameworks will also need to be utilized to build a modern web application. It is important to research these thoroughly in order to ensure that selected frameworks can meet the web application’s requirements. This would include not only the functional requirements but non-functional requirements must be taken into account as well.

Frameworks are almost like their own languages. I like to think of them as being like a friend. As with a friend, it takes time to get to know your friend, but once you understand each other, a bond is formed. You want to hang out together. It feels natural and easy.

Also like friends, you can sometimes also have a falling-out and desire to seek the company of another. Sometimes it is necessary to develop a new relationship.

Lastly, like a friend, the framework should pull out the best in you as a developer. When there isn’t good compatibility (usually because of inapplicability with the use case), then it makes sense to make a different choice.

Front-end Framework

The frontend framework should be selected for developing frontend components that represent the web pages. There are many open source web frameworks that have been developed to provide web developers with tools for creating SPA web applications and other style applications.

As users call for quicker and more interactive web-based services, the SPA web application became a standard approach to delivering web applications. By swapping out content on a page with information from the server instead of retrieving the whole page’s content and reloading it, we are able to reduce loading times and improve user experience. Only the portions of the page that need updating are updated.

Popular web frameworks that can build SPA applications include React, Angular and VueJS. Each of these web frameworks offers a different approach to web development, although there are many similarities in approach as well.

Deploying

There is also the consideration of how the application will be deployed. There are various cloud-based ways of hosting web applications, such as using a traditional dedicated or virtual server; multiple servers for web application and database support, or even using various container-based solutions that use Docker and Kubernetes. Each approach has its advantages and disadvantages that need to be taken into account before making a decision on how the web application will be deployed.

Don’t just pick what is “cool” or the latest thing. Pick it because it fits the use case. If you don’t, then you might find yourself paying more for development and cloud services. In many use cases you may actually reduce your ability to scale the application! Choosing the right cloud technology to use to deploy your application is as important, and sometimes more important, than some other decisions we discussed previously.

Consider, for example, an article from AWS that discusses impacts of poorly configuring Lambda function, one of AWS’ serverless compute offerings. As in the first example they share, if you aren’t regularly evaluating what you are doing, issues may sneak up on you. Sticking with AWS for the moment, the decision to use Lambda in the first place, versus using an EC2 instance or AWS Fargate, are decisions that require careful consideration.

An Often Skipped Step

I will discuss it again in step 5, but it should be understood that the selection of a technology stack is not typically iterated. In other words, once the technology stack is selected, it will generally be used the same in all future iterations. Some iterations may require additional technical design, although most iterations will not deviate significantly in the technologies used.

In a waterfall approach, it will be necessary to consider the technical design of the entire web application, although there can be some opportunity for making some of these decisions later when needed. Regardless of the approach, it is helpful to have a general technology vision so that you don’t paint yourself into a corner.

3. Designing the user interface of the application

Man drawing a user interface on a whiteboard

Tie to Business Requirements

Once the technology stack has been selected, the web application designer needs to design the web pages and user interface of the web application. This involves creating visual artifacts that accurately portray what users will see when using the web application.

It is important to iteratively review these designs with stakeholders in order to ensure that web pages are designed in a way that reflects the web application’s business requirements. The web designer should also consider user experience principles when designing web pages - making sure they are visually attractive and user-friendly and meet the desired business outcomes.

Part of Proof of Concept?

Many of these considerations may have been addressed during the proof of concept phase. During that time, prospective customers, or early adopters were questioned about their needs and how well the design meets those needs. The web designer should use this feedback as reference when designing the web application interface and deviate only when it is very clear that such deviation will be helpful. Any changes at this point might also require going back to the users for validation.

Complete the Design

Not all user experience considerations were necessarily covered during the proof of concept phase. Any portions that were not completely fleshed out will need to be finalized. In an iterative development approach, the user interface is designed at the beginning of each iteration.

Technical Design

The design will also need to include a technical design as to how the frontend will interact with the backend. It is important to ensure that web pages contain the necessary functionality and components for interacting with the web application’s server-side technology. This communication should be designed in a way that is secure and consistent with web application standards and delivers the necessary information to the right components.

4. Designing the backend and data storage for the application

The Data Model

In coordination with the frontend design, web designers need to define the data model. The development of the application to support the business usually involves mapping the components that define it. This creates a representation of the application’s data in a format that is logical to software developers that are familiar with the business concepts.

Service Layer

The web designer should develop a web service layer to facilitate communication between the web application and the backend web services. This layer will be responsible for validating data, transforming data from one format to another, merging or otherwise manipulating data, looking up other data and finally storing results.

Storage Structure

The web developer must consider how data needs to be stored and retrieved. How web pages are built influences the services that are used to store, retrieve and query web application data. An API, the interface between the frontend and the backend, or any other consumer of the services of the web application, is defined together with the web application’s data model.

Non-functional Concerns

The web designer must also consider scalability, performance and security considerations when designing the service layer. Non-functional requirements may dictate what cloud services are utilized.

For example, an application that required the ability to support a large number of users during peak periods, but only a small number of users most other times, may require the web designer to segment certain portions of the backend services and deploy them in a different set of cloud services from other parts of the application in order to accommodate such scaling.

5. Programming against the design

Man at a restaurant using his Mac and appearing frustrated

Consider the Technology Stack

Only after all such design considerations are considered will it be time to actually get down to programming the web application. In an iterative development approach, design of the technology stack may not require being revisited as previous iterations may have answered many of the design questions.

The first iteration probably addressed the technical requirements for many of the iterations that follow. Some iterations may come along that require a different approach. In such cases, there would be more time spent in design for that particular iteration, and therefore less programming time.

For example, there may be a portion of the application requires significant scaling. Suppose it is an isolated machine learning portion of the application. That section of code may require a different deployment, or the overall technology stack may need to be very different. It is important to not just be on autopilot with regard to the technology stack. It is also important not to change the technology stack for no reason as well.

Fullstack Development

Assuming that programming is moving forward, there will be a need to develop on the frontend and backend of the web application. This can be one single developer doing all the work, or could be multiple developers on the frontend and multiple developers on the backend.

The way modern web apps are created, it is easy to have teams programming simultaneously. Web application frameworks and source control make it easy to divide up the programming of web application components into small, focused tasks and the output of that work can be integrated together as needed.

6. Testing and deploying the newly created solution to ensure its proper functioning

A woman in front of a computer, possibly testing software

Types of Testing

Regardless of the project management approach, each bit of software that is created needs to go through a testing phase. There are different types of testing, such as unit testing, systems testing, integration testing, performance testing, web security testing and user acceptance testing. There may be other kinds of testing requirements depending upon the problem domain being considered.

Testing Techniques

Each web application component must be tested to ensure that it is functioning as expected before being deployed. Different techniques might be selected for conducting tests. There’s white box testing, where the developers themselves test functionality, or they develop the tests with knowledge of the various execution paths. Using knowledge of what the underlying code is capable of doing, or should be doing, the developer is in a unique position to advise on what the tests should look for. This can also be a hindrance though and is where black box testing comes in.

Black box testing is where components are tested without any knowledge of what the web developer intended it to do, but with knowledge of what the requirements say it is supposed to do. This would typically be developed by a testing professional and since this individual is not familiar with the inside workings of the program, their decisions about what tests to perform are not informed by the programming, and therefore they are often more likely to uncover errors that the software developer was not even considering.

There is also gray box testing that combines elements of both black box and white box tests. With partial knowledge of the application’s internal structure, this type of testing has the potential of increasing the quality of the application due to software developers offering input into the testing process that is primarily being conducted by testing professionals who are unaware of the internals.

The people conducting tests need to design tests that cover various scenarios, verify the performance of different components (and other non-functional requirements), and determine if the web page elements created by web developers show up as expected.

7. Maintaining and improving it over time with new features or bug fixes

Man by a workbench maintaining something

Upgrades, Bug Fixes and Enhancements

Once the web application has been released and put into use in a production context, it is important to maintain the web application over time. This could involve refactoring of code as we move through development iterations. It could also include upgrading as changes occur or when older technologies begin to become outdated or are replaced by new ones.

It also includes maintenance such as bug fixes, adding new features and enhancements, updating web page elements, making sure web pages load quickly, and ensuring web applications are secure.

Retesting

These changes also need to be carefully tested before deployment to make sure they don’t introduce any issues or caused code that previously worked to now no longer work properly. This is known as a regression. As such, it is necessary to include regression testing as another testing type that is needed.

This is one advantage of the waterfall approach. Regression testing is not necessary until there is functionality that has been validated that is working properly. This does not happen until the end of the project when the entire application is deployed and put into service. In an iterative development approach, regression testing is necessary at multiple times during the course of developing the web application.

My Takeaway

All Steps Together

Creating web applications is a complex process that requires many individuals from different disciplines or a single person with lots of experience in multiple disciplines. Software developers, operations professionals, application architects and designers, testing professionals, and the overall business and technical teams all come together to create web applications.

It is most often an iterative process that involves multiple steps such as design and architecture, coding, testing, maintenance and improvement over time. This process must also include testing of web applications to ensure they are working properly, both before and after the web application is released into production.

After release, there are needs to upgrade, bug fix and make changes to address evolving needs for the web application.