Michael Washburn Jr.

Software Engineer

Most Recent Post


Building a Web App From the Ground Up: Getting Started — Part 1

So you want to build a web app. Well what’s stopping you? If you’re reading this, you’ve probably already been programming for some time, but you’re just missing some of the steps. I’ve been there before. I know how frustrating it can be to know 70% of what you need to do to build a killer web app for an idea you have, but not have enough knowledge to take the idea from beginning to end.

In this series of posts I’ll review the steps I take to build a simple web application using the Django and React frameworks. From start to finish, I’ll cover everything you’ll need to know to get your web app out there. The following is an overview of the topics that I will cover (in order).

  1. Getting Started
  2. API Development
  3. Front-end Development
  4. Deployment & Continuous Integration

Getting Started

A lot of tutorials like this will take you right into programming your project without a lot of lead-in. However, this is never the first I actually do when I decide I’m going to build a new web application. Once you have an idea for a web application and have decided that you’re going to build it, you should make some repository to put project-specific documents in. When I say repository, it doesn’t have to be a git repository or other source code control system. In fact, I’m not a huge fan of putting non-source code in their GitHub repositories. I prefer Google Drive or OneDrive for non-source code documents.

Problem Statement

Once I’ve setup a new project folder in a service like Google Drive, I write my problem statement. It’s important to put down in words exactly what you want your application to do. It should become your mission to accomplish this statement. Anything else your application may do should come secondary to this overarching theme.

I tend to write my problem statement as a single sentence of the form “I want to build a ____ that lets _____ [verb] _____.” Throughout this tutorial, I’ll be building an example web application. I’ll define the problem statement for this example application as such: I want to build a web application that lets anyone create and manage todo lists. It wold be awesome if this application also integrated with your calendar, sent email/text reminders of your todo list items, etc.. But, the primary goal of this application is going to be to just let users create and manage todo lists.


After I narrow down the problem I want to solve, I try and identify the requirements that I have in order to best solve that problem. At this point you might be thinking “I’m just doing a personal project. Do I really need to outline the requirements?” You might be surprised to hear that I do this for my personal projects a lot of the time. However, I keep these requirements high-level, and generally don’t write down more than 10. For larger projects (and when dealing with clients), I think it’s important to try to define all of your requirements as granular as you can. But for me, I find I can define a small number of high-level requirements, which helps keep me focused during development.

For our example app, I’ll define the following requirements:

  • The app shall allow users to create todo lists.
  • The app shall allow users to add any number of todo items to a list.
  • The app shall require users to log in to create or edit todo list items.
  • The user shall be able to mark todo lists as public so that users can view

This is a pretty basic app, so some of these requirements are still more specific than I might have for other applications. For larger projects I’ll try to define the key components of the application that should exist, as well as key features of the application.


It is also important to think about the process by which you will develop your application before you dive into coding. If you’re building a web application by yourself, you’re probably not going to follow a strict development process with 2 week sprints and daily stand-ups. This is an important thing to do while in a team, and if you are a apart of a team, I would urge you to look at formal software development processes.

If you’re developing a web application solo, you should still think about the general process by which you want to build your application. Do you want to build it from the bottom up? The top down? In vertical slices? I try to pick one of these general ways to create my app based on what suits the specific situation best.

Bottom-Up Development

I find this development method best for applications where most of the requirements are known and the data model heavily drives the rest of the application. This allows you to flesh out your data structures and relationships between models early, making developing the UI later super easy.

For the sake of this tutorial, I’ll be building the application from the bottom-up. I think this makes the most sense to beginners, as you can see how the data is defined, how it’s transferred from the API to the front-end, and lastly how it’s presented. I learned the most by building applications this way.

Top-Down Development

I really like taking this approach for applications where I’m not quite sure how they will work or what requirements will surface. It is also especially useful when working with clients. You can build your UI first, using mock data and stubbing out features requiring interaction with your API. Then, your client can review your work periodically, and provide crucial feedback, which may have required you to refactor the API had you not done a top-down approach.

Vertical Slices

Building your application in vertical slices is a great alternative to either of the above. Using this method you define key sections of your application which can be built separately. You want to completely build one section of your application before starting the next. The best part about this method is that you can also choose to build each section from the top-down or bottom-up. Another key benefit is that you can deliver fully functioning software quicker. Even though it may not have all the functionality that the finished product may have, it’s always good to have a slice of your functionality completely working. This is a hallmark of good software engineering in my opinion.

Choose Your Tech

I think it’s important to decide on technologies early in your project’s lifetime. Even though you may not be developing your API or your client-side application right away, choosing early will give you time to think about your choice, and to change your mind if necessary.

For this example, I chose to use the Python framework Django to build my API. I chose this because Django is great for creating and managing a data model and creating simple CRUD endpoints (Create, Read, Update, Delete). I think it’s a great choice for beginner developers, and also a great choice for RESTful, data-focused APIs.

For the client-side application, I will be using React, a JavaScript framework with a component-based architecture. If you do not have much experience with modern JavaScript frameworks, this will be a great introduction. React is easy to use, and pays off with the amount of reusable code you can create.

Set Goals

Lastly, I try and set attainable goals for myself when starting a new project. These can be very simple. For example, one goal

Action Items

Before we start actual development in the next part of this series, I challenge you to:

  • Stop and think about what you want to accomplish.
  • Create a problem statement.
  • Identify some of your key requirements.
  • Think about how you’re going to develop this application.

However, this is by no means a process that’s set in stone. I highly recommend the steps I mentioned above, but you have to do what makes sense for your specific situation. If you’re particularly unsure of the key aspects of your application, try making a domain model. If you feel like you don’t quite understand how the data model is going to look, try your hand at creating an Entity Relationship Diagram.

The next part of this series, API Development, will be available next week on Tuesday, August 22nd.

Please comment below if there is something specific you would like me to cover in this series.