In this post, I’m going to show you EXACTLY how to make a web app.
In fact, this is the process I’ve used, revised and perfected over the last 5 years.
I’ve used this exact process, or a version of it to build over 15 applications of all shapes and sizes. For me, this is 100% the best way to build web applications.
But, before we start the tutorial, a quick recap on what we define as a web application at Budibase.
An interactive computer program, built with web technologies (HTML, CSS, JS), which stores (Database, Files) and manipulates data (CRUD), and is used by a team or single user to perform tasks over the internet.
There is a lot of confusion around what exactly is a web app. For the purpose of this post, we feel our definition above simplifies what a web app is. If you’re still unsure, we’ve included examples of what we believe are web apps, and what are not, below:
Ok, now we’re on the same page, let’s jump into prerequisites.
To make a data-centric web app from the bottom-up, it is advantageous to understand:
If you don’t have any experience with the points above, don’t worry. You have two options:
Moving on. The time has arrived to quickly dive into the 12 steps for making a web app.
Are you ready? Let’s do this!
1. Source an idea
2. Market research
3. Define functionality
4. Sketch your web app
5. Plan your workflow
6. Wireframe the UI
7. Seek early validation
8. Architect your database
9. Develop your frontend
10. Build your backend
11. Host your web app
12. Deploy your web app
Before making a web app, you must first understand what you intend on building, and more importantly why?
The idea process for many is the toughest part.
Your idea should stem from solving someone’s problem. Ideally, your own problem.
It’s important that you choose an idea which interests you. Interest is key to fuelling motivation which is crucial when making a web app. It takes effort building web apps and it’s important you have fun during the process.
If you are having a hard time finding ideas, here’s 6 micro saas ideas.
Once you’ve chosen your idea(s), it’s important to research the market to see:
The number 1 reason startups fail, is down to the failure to achieve product-market fit.
Marc Andreessen defined the term product-market fit as follows:
“Product/market fit means being in a good market with a product that can satisfy that market.”
To quickly find out if a similar web app exists, use the following tools to search for your idea:
If a similar product exists, don’t worry. This can be a sign a market for your idea exists. Your future competitors have laid the groundwork, educated the market. It’s time for you to swoop in and steal the thunder.
If a similar product does not exist, it’s a possibility you’ve struck lucky - you masterful innovator 👍.
On the other hand, it’s a possibility someone before has ventured down this path and hit a dead-end 👎.
Nobody wants to experience that, so it’s important to dive deep into the market and source the wisdom of:
Your Web App’s target market - Share your web app idea on forums related to your target market. If you know anyone who works within your target market, explain your idea to them. The more you talk and receive validation from your target market, the better.
Google Trends - A quick search of your web app idea will reveal relating trends.
SEO tool - I’d recommend MOZ/Ahrefs. Google’s keyword planner will suffice. Write a list of keywords relating to your web app. If it’s an ‘OKR tool’, use the tools to search ‘OKR tool’, ‘OKR app’, and ‘objectives and key results software’. If the SEO tool indicates there are lots of people searching for your keyword terms, this is a small indicator you have a target market.
Social Media - Jump over to Twitter/Facebook groups and present your idea to your target market.
Events - If there is a local event in your area attracting people from your target market, go to it. Share your idea and record the feedback.
After completing the above steps, you should have enough information to understand if there’s a market for your product.
If there is a market for your product, and there’s also established competition, it’s important to research them.
You’ve got your idea, you’ve validated the market, it’s now time to list everything you want your app to do.
A common mistake here is to get carried away.
Your web app is NOT a swiss army knife. It won’t have all the features and functionality of Salesforce and it doesn’t have to.
I repeat, don’t get carried away. The more functionality you add, the longer it will take to build your web app. Quite often, the longer a web app takes to build, the more frustration you’ll experience.
One of the most important aspects of making a web app is having fun, enjoying the ride, and celebrating the small wins.
Only define functionality which solves your target markets problems.
I promise I’m not here to kill your dreams. Remember, you’re web app is a work in progress and the first goal is version 1. It will still have cool features and delight your users, but you must keep things simple.
For direction, I’ve included a list of basic functions required for a simple CRM app.
The above list will help you define your features. Once you’re done, roll up your sleeves.
It’s time to get creative!
Moving from the Ideation stage, to design stage.
There are multiple stages of designing a web app.
The first stage is sketching.
My favourite and the quickest way is to use a notebook (with no lines) and pen/pencil. Old school!
After step 1,2 and 3, you should have an idea of what your web app is, who your users are, and the features it will have.
Sketch out the wireframe of your web apps UI - it doesn’t have to be exact - this is just a sketch.
When sketching, consider the following:
Sketch different versions of your web app. Consider how your web app’s functionality will affect the overall design.
Annotate your sketch and outline how your app should work.
Taking notes will help you clarify and understand why you’ve designed certain elements at a later stage.
Once again, don’t get carried here. Your sketch is for communicating and experimenting, not selling. Overcomplicating the design at this stage will only lead to frustration.
After sketching your app, it’s time to move on to step 5.
It’s time to put yourself in the shoes of your user. In step 5 we’re going to plan your web apps workflow.
Now is the time to go back to step 2 and look at your market research. Take your list of competitors and sign up to their free trials. Have a quick play around with their product.
Write notes on what you thought was good and what you thought was bad. Pay particular attention to the workflow.
After you’ve finished analysing your competitor’s web apps, it’s time to write down different workflows for your app. Consider the following points:
All of a sudden our one-page web app turns into a 10-page web app.
Write a list of all the different pages your web application will have.
Consider the different states of pages. For example, the homepage will have two states; logged in and logged out. Logged in users will see a different page than logged out users.
Ok, it’s time to turn those sketches and that new-found understanding of your web application into a wireframe/prototype.
Wireframing is the process of designing a blueprint of your web application. Prototyping is taking wireframing a step further, adding an interactive display.
The decision is to wireframe or prototype is down to you. If you have the time, I’d recommend prototyping as it will make it easier to communicate your web app when seeking validation.
You can prototype/wireframe using the following tools:
I recommend you create a design system / style guide first. You can find inspiration at UXPin. Design systems improve design consistency. But it’s not required.
You’ve now got a beautiful wireframe/prototype which visually describes your web app.
Digital high five ✋.
It’s time to show your beautiful wireframe to the world. At this stage we want constructive feedback.
Simply asking your friends would they use your new web app is not enough.
You should start with a small number of representative users. Go to your target market’s forums, watering holes, their places of work and verify the problem with them, and present your solution.
Try to build a rapport with these representatives as they could become your customers.
I like to use this stage to test my sales pitch - the ultimate tokens of validation are pre-launch sales.
Takes notes and document all feedback. The learning from these meetings will help direct the development of your MEP (Minimal Excellent Product).
Ok, now you’ve got great feedback and product validation. It’s time to start building your web app.
Before we make our web app, I would like to share the following tips:
It’s time to consider your database.
So, we know roughly our web application’s functionality, what it looks like, and the pages required. Now it’s time to determine what information we will store in our database.
A database is simply a collection of data! Data can be stored to disk, or in memory on a server, or both. You could create a folder on your hard drive, store a few documents, and call it a database.
A Database Management System (DBMS) is a system that provides you with consistent APIs to (most commonly):
What data you need to store and what your users need to do, will determine the type of database required to run your web app.
There are many types of database for many different purposes. A web app will most commonly use one of the following:
You should use a SQL database if your data is very relational. Your data is relational if you have multiple, well defined record types that have relationships between them. For example, a “Customer” may have many “Invoices” stored against their record. Typically, you would create a Customer table and an Invoice table - which could be linked together by “Foreign Key” columns. E.g. Customer.Id = Invoice.CustomerId.
SQL databases have an extremely powerful query language that allows you to present your data in all sorts of useful ways.
They have been around for decades, are very well understood, and usually a safe choice. MySQL, Postgresql, Microsoft SQLServer are some of the most common - along with many more modern offerings.
The downside of SQL databases is that you must declare all your tables and columns up front. There can be a lot of overhead to manage. If you have never used one before - you’re in for a pretty steep learning curve. However, there are plenty of learning resources available, and it’s always a great skill to have.
You should use a document database if your data is not very relational. Document databases store “documents”. Each record in your database is simply a big blob of structured data - often in JSON format.
If you need to store relationships between your records, you will have to write code to manage this yourself. However, many other aspects of using document databases are much simpler. Your database can be “schemaless” - meaning that you do not have to declare your records’ definitions up front.
Generally speaking, the bar to entry to a document database is much lower. They also tend to be much more scalable than SQL databases. They usually offer some querying capabilities, although sometimes not as powerful as SQL.
Examples of document databases are: MongoDb, CouchDb, Firebase (serverless), Dynamo Db (AWS). There are many.
Each of your clients has their own, private dataset. One of the worst things that can happen to your app is for one client’s data to be seen by another client.
Even if there is only a small amount of non-sensitive leaked data, and no damage is done, an event like this will massively erode trust in the security of your app.
You must architect a solid strategy for segregating your clients’ data to make sure that this never happens.
Broadly speaking, you have two options - Physical Separation and Logical Separation.
Every one of your clients has a separate database (although could share a database server with others). This makes it much more difficult to make a mistake that leads to data leakage.
For example, listing all Invoices in a database will only return Invoices for one of your clients. In order to get another Client’s invoices, you need to connect to another database.
Since each of your client’s data is in its own database, you can easily spread them all across many database servers, without the need for “sharding”. Your app will be much easier to scale this way.
The code you will need to write:
When creating a new client, you need to create a new database and populate with any seed data.
You need to keep a record somewhere of all your clients, and how to connect to each client’s database.
If you need to upgrade your database (e.g. add a new table), you need to code to upgrade each separately.
If you need to query all your client’s data into one, you need to pull the data out of each and aggregate it.
All of your clients are stored in one giant database.
Every time you need to get data for a single client, you must remember to include a filter for the client. E.g. ‘select’ from customers where customerClientId = 1234”
You now only have one database to manage. Setting this up and connecting to your database is easy. Your speed to market increases.
When you need to upgrade your database, you can do so with a few clicks, or by typing a few commands. It’s very easy to add new features.
As you gain more users, your database will grow to millions of rows. Put some effort into how your database handles this extra volume and load. You will have to start tuning your queries.
When you’re under pressure, it is so easy to forget to include that “where clientId = 1234” filter.
Doing so could result in a business ending data breach.
You should look into best practices for securing your particular database. Some databases come with a default administrator login, which people often forget to change. This could leave your data open to the world.
From the start, you should create a login with “Just Enough” access. If your app only reads and writes data, then it should authenticate to your database using a login with only data reading and writing access.
Note: In reality, you will build your backend and frontend at the same time. But for this post, we’ll keep it simple.
If using server pages, getting started is super easy. Your backend framework is all set up and ready to start building. This is where the huge benefit lies with server pages.
With SPA, it’s a little trickier.
First, you need to set up your development environment. The components of this will be:
A compilation, and packaging framework:
This is also used for serving and “Hot Loading” your application at development time, on a nodejs web server, running on localhost.
A frontend framework (strictly not necessary, but highly advised unless you are an experienced frontend developer):
The list is endless!
Configuring your packaging tool to talk to your backend - which is most likely running on a different port on localhost. Usually, this is done using Node’s HTTP proxy. Most packaging solutions have this option built-in, or available as plugins. This point commonly gets people stuck, and may need a diagram. Remember - if you write your backend API in C Sharp (for example) then at dev time, you will be running it on a local web server, through your code editor. I.e. your frontend and backend are running on 2 different web servers, in dev. However, in production, your frontend should (probably) be running on the SAME web server as your backend - mainly because you want them to run under the same domain.
This means a few things
There is always a significant time required to set up your dev environment for a SPA. There are plenty of boilerplate templates out there for your frameworks of choice. However, I have never written an app that has not eventually needed some custom code on top of the boilerplate.
Still, I always choose a SPA.
You should now have a better idea of how to setup your frontend and define the look and feel of your web app. In most cases I build the fontend and backend together.
Moving on to the backend.
The backend is typically what manages your data. This refers to databases, servers, and everything the user can’t see within a web application.
Building your backend is one of the toughest parts of web app development. If you feel overwhelmed, a tool like Budibase can take away many of the complexities - including the follow tasks.
If you feel confident, continue on.