Skip to content
Gallery
Magic Growth
Free Nuggets
More
Share
Explore
Free Nuggets

icon picker
How to build a SaaS product

I built a SaaS product that did $20,000 in the first 30 days. This is how I plan, build, and launch SaaS products.
This guide assumes you already have a validated idea.
If you don’t, save your time & money until you do.
PSA: I’m working on a guide to validating your business ideas, but it’s not done yet.

Secret Shortcut

Building software can take a long time.
But it doesn’t have to.
My philosophy is this: ship the MVP (minimum viable product) as quickly as possible.
To do this, I build all of my software with no-code.
If you don’t know what no-code is — think of it like an easy programming language.
I use lots of different no-code tools:
⁠
Bubble
⁠
(my go-to)
⁠
Xano
⁠
⁠
⁠
Zapier
⁠
⁠
⁠
WeWeb
⁠
⁠
And others
No-code is awesome because you can build products fast without paying developers thousands of dollars!
I’ll walk you through how I plan, build, and launch SaaS products with Bubble.

Plan

This is the order of operations that I use for building SaaS:
App layout (pages & workflow mapping)
Database
Primary features
Secondary features
Administrative functionality
Design
Fine tune
Internal Test
Beta Launch
Full Launch

App Layout (pages & workflow mapping)

Before I do anything, I want to see my app from 30,000 feet.
What are we actually trying to accomplish?
This is critical because it’s easy to get sidetracked with a never-ending list of features.
When shipping an MVP, build the core product and then launch.
We’ll use Instagram as an example.
The thinking goes something like this:
“I want users to share photos and videos with friends. When someone opens my app, they should immediately see content from their friends and other people they follow. Users need to be able to like, comment, and share posts they enjoy. Obviously, they need to be able to share their own photos and videos as well. It’d be cool if they had a collection of their own content, too. So we’ll add a profile page. And then users need to login and logout and all that other administrative stuff.”

This helps me understand a few things:
The primary features we need to build for the MVP
How the app pieces fit into the puzzle as a whole
How I should organize my database efficiently

I then map out the pages I think I’ll need.
It’d look like this for a simple version of Instagram:
Main feed page
Profile page
Upload page
Login / Logout page
Settings page
Something like that.
Then I start building the database.

Database

The database is important.
Very important.
It’s difficult to change your database down the road when you have thousands of users and hundreds of thousands (or millions) of data points.
You want your database to be as efficient as possible.
Otherwise, data storage gets expensive & your app performance will suffer.
A database for instagram might look like this:

User
Name
Birth date
Profile photo
Bio
Photos
Videos

Photo Post
Image path
Description

Video Post
Video path
Description

(you get the idea)

I could talk for hours about database “best practices.”
If enough people want that, maybe I’ll make a doc for that.

Primary Features

Next, I build the primary features.
These are the features I can’t live without.
For Instagram, this would include:
Uploading a photo
Liking someone’s post
Seeing your own feed on the profile page
It’s critical to only include MUST-HAVES in your MVP.
Don’t waste time building supplemental features.
You’ll have plenty of time for that later.

Secondary Features

Here’s my rule for supplemental features:
If it takes me less than 20 minutes to add, I’ll build it.
If not, I save it for post-launch.
This ensures that I launch as quickly as possible without spending time on unnecessary features my customers don’t care about anyway.
Speed is the name of the game.
Don’t build new features until your customers are telling you exactly what they want.
This will save you boat loads of time.
And make you more money.

Administrative Functionality

Then I add the boring stuff.
Login, Logout, settings pages, etc.
Once you’ve built enough apps, you can plug-and-play these pieces for the most part.
For launch, keep them dead simple.
Your first customers won’t care about a SICK login page.
They’ll care that your app works and that it solves one of their problems.
“Good enough” is the name of the game for administrative functionality.
Important: this also includes privacy settings to ensure that people are seeing the information they’re supposed to see, and not seeing the information they’re not supposed to see.

Design

Once the app works, I put a pretty wrapper on it.
Colors, buttons, copy, backgrounds, etc.
Typically, I go for simple & clean.
I spend all my design “juice” on the marketing site (the one that sells people on my product).
Just don’t let the design hinder user experience within your app.
As long as it’s easy to understand and navigate, design can be simple for your MVP.

Fine Tune

Then I’ll run through a quick fine tune on each page.
Are the workflows set up?
Does the design look clean?
Did I miss any copy sections?
This acts as a last runthrough before I begin testing.

Internal Test

You never want to push your app live without proper testing.
It’s a recipe for disaster.
The first test I run is an internal test.
I’ll have team members or friends use my app and tell me what doesn’t work.
Things like, “This button doesn’t do anything” or “I can’t see my profile feed.”
Best to get these out of the way first.

Beta Launch

Then I’ll run a beta launch.
This is especially important if you’re expecting a lot of traffic from the start.
If you’re not launching to a large group of people who are likely to sign up instantly, you can probably skip this step.
The beta launch is a small group of real users who can try the product early.
The key here is to let them know that it’s still being fine-tuned, and ask them to relay any bugs or issues they have when using the product.
Beta launches typically include free-trials or discounts.

Full Launch

Once I’m confident the product is ready, I’ll launch!
Heads up, though — ask any developer...
Launches almost never go as planned.
Things will almost certainly go wrong.
The very things you tried to prevent (like buttons not working) will happen.
It’s part of the game.
Expect it.
I recommend being full devoted to solving these issues on launch day.
Clear your schedule.
Spend the whole day on alert, ready to fix bugs ASAP as they arise.

And there you go!
That’s how I plan, build, and launch a SaaS product.
I’ll add other documents in the future about how I market SaaS products.
Until then, go build some awesome apps 🤟

⁠

👋 Have a question about building SaaS products?

Shoot me a DM →
@imjackkruger
⁠
⁠
Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.