How I Build SaaS Products In Days, Not Months – Part 1

This all started with a tweet storm that got a lot of attention. And while I think Tweet Storms are fantastic, they beg for longer form content to dive deeper. This post will be exactly that. I will get into the nitty gritty of my rapid process to create SaaS products. I will show you my thought process around prioritization, dev architecture decisions, design, hosting, vendor choices, marketing, operations strategy and much more. Everything from idea to launch, in as short a time frame as possible. I hope you enjoy it and use it to build something great.

Some backstory

To give you some background, I’ve been building software businesses well before I knew how to code. For instance, one of my first sites was concept called Cooler Than Yours. If you remember the FML website, it was a play on that. Where in our case instead of text it would be user uploaded images and the community would vote on them. In hindsight it was a stupid idea, but it was easy to wrap my head around technically. Despite the simplicity, I still was trying to find a technical cofounder. Here is an email from 2010 of me speaking to someone at an incubator about how to find a technical cofounder.

I never ended up finding that person, but instead, I taught myself to code and the rest is history. But that’s not the point of this post. The reason I bring up that story is to explain my drive behind learning to code. From the vey beginning I saw coding as a means to end to build a business. It was a tool that I needed to learn how to use and as I got better, starting and growing businesses got easier. This was my secret sauce and explains a alot around my ideology towards software dev or in the case of this post, Rapid SaaS Development.

Rapid SaaS Development

Through the process of starting/building 30+ software businesses and projects, I have come up with a methodology that I call Rapid SaaS Development.

The primary goal is to get from idea to product in as short amount of time as possible. Best case scenario, this is measured in days and if not days, then weeks, but definitely not months. That’s not saying that software can’t require months to build. It absolutely can, and I’ve been there, but for a new product that has a primary goal of getting to market to test demand, we don’t want to invest too much time into development. Especially if we don’t know if it will work.

I will briefly touch on some no code solutions. They are a fantastic option and one that I use frequently. But this post will mostly target how I develop quickly with custom code.

My process for building a SaaS app has many parts, here is how I am going to break it down:

• Mindset & Goals
• Priority Framework
• Backend Language
• Front End Language
• Software Architecture
• Database
• Queueing
• File Storage
• Authentication
• Emails
• Hosting
• Caching
• Testing / QA
• Monitoring
• Logging
• Payments
• Landing Page / Marketing Site
• Design
• Admin
• Reporting
• Operations
• Marketing

There is a lot here, let’s get started!

Mindset & Goals

Before starting a project it is important to set expectations of what we want to build and how we are going to do it. I will show you that it is beyond possible to build a minimal viable product (MVP) in a matter of days. It won’t require sleepless nights, although once you get going you might not want to stop. It will take effort, but the tools are out there and will make the process much easier. The hardest part will be paring down the scope, but I will help you with that.

Mindset

When I first set out to build a new product in a short time frame, I write down a list of the features that I want to launch with. This serves two purposes:

1. It gives me an opportunity to think through the MVP holistically and start to get a sense of how long it is going to take. If it feels too long, this is the time to start moving features to post launch.
2. It acts as a guideline to keep me honest. It’s likely that I will diverge from this list, which is fine. But when I do, I am now forced to make a conscious decision of adding to the original list or removing something that was already there. (We’ll discuss this more in the priority framework.)

Once I’ve made that list, I like to spend 20-30 minutes thinking through the feature set and playing devils advocate. The main question being:

“If I launched without X feature will the target user still find the app useful?”.

BTW this is why everyone says to solve your own problem. When you are the target user, this question becomes very easy.

If the answer to that question is yes, I don’t hesitate and move it to a post launch list. If the answer is maybe, then I leave it and will add it to the priority framework exercise (explained later) to help me make a decision on whether I need it.

It’s hopefully a given at this point, but my main goal with this process is speed. I know that I will be lacking features, I know that I will not please everyone and I’m ok with that. This is because it’s more important for me to get something to market and start getting data on usefulness before I invest more time. The first version of a product is just a bunch of assumptions duct taped together into some code and a frontend. If you have good intuition some of your assumptions will be right, but most will not be. This is why businesses takes time. We are constantly making assumptions, testing and iterating on them. So by launching quickly with a minimal feature set I remove a significant amount of risk and get to start testing those assumptions sooner. The faster the feedback loops the quicker you’ll grow.

Need For Speed

You will see throughout this that the need for speed has a direct impact on every choice I make. Even down to the language that I build with.

It’s common as creators for us to want to use the shiniest tools and if your goal is to start a business then I challenge you to resist the temptation. It’s important that you use technology that you are comfortable with and something that you can build with quickly. I don’t care if that’s JS, COBOL, PHP, Java or Ruby.

I can’t emphasize enough how insignificant language choice is in the beginning. The reality is that most of your projects will fail and thus most of the work that you put into them will be useless from a product perspective. Be deliberate with your goals. If your goal is to start a software business, build a business, don’t try to learn a new framework in the process. If your goal is to learn a new framework, then go do that, but don’t expect to launch a high quality SaaS product in a short amount of time. Be true to yourself about your goals and stick to them.

Goals

Here are a list of goals that I try to maintain throughout this process:

• Launch as quickly as possible
• MVP doesn’t mean a shitty experience
• It’s ok to push features to post launch
• Don’t reinvent the wheel
• Don’t over-engineer. Build something that works
• Don’t waste time on design
• Expect all of your assumptions to be wrong

Next up we’ll discuss how I assess priority.

Priority Framework

Now in terms of priority, there are lots of frameworks out there that will help you strategize around what features to cut. I tend to use a very simple prioritization framework and we will go through it below. There are plenty of more sophisticated ones out there. If you are interested in learning more I recently just read a great resource by Arvid Kahl on the different types of frameworks.

We are going to discuss how I assess priority with the main goal of cutting down build time. That means cutting features that have a low ratio of user value to dev effort.

Applying The Framework

Let’s use my framework above and look at an example that has come up recently. One of our products LeadAide helps manage followup for leads. The result of that is outcome and disposition data on leads and many of our customers are asking for a Zapier integration to help connect that lead outcome/disposition data within their CRM. The ideal and most robust way to do this would be to build a custom Zapier App which would live as a zap within the Zapier platform.

In our scenario where time is limited, this approach is not ideal. Even if you already knew how to create a Zapier integration and could remove the time needed to research, any external integration has the potential to bloat scope and cause downstream debt. Plus this is the kind of thing that needs to be approved by an external party (variable time). Secondly and probably more importantly, this kind of feature is ancillary to the core product. The data would be nice to have but the features to actually produce that disposition data is more important. In this example I see two options:

1. Cut the feature completely and build it at a later time
2. Build something smaller in scope

Punting on this feature is self explanatory and in the case of a weekend project I would absolutely go with option 1 of launching without it. But, for the sake of this exercise, let’s entertain the more interesting option of trying to get the same functionality with a smaller scope.

There are two ways we could tackle this:

1. Create an export of lead data and let the user import that into their CRM. This would work, but be manual and not a great experience.
2. Build a very simple webhook that would push the lead’s data to a webhook endpoint for a single event. This would require the user to setup Zapier webhooks and map that data to their CRM zap. The positives here are that it is less manual, would be almost real time and sets the foundation for eventually building a Zap later on.

We can now take these two approaches and apply the prioritization framework from above. Once the scores have been added you divide Value by Dev Effort to get your ratio percentage. With that you can compare the numbers.

As you can see above, the final scores are close. In this example it’s clear that while the webhook option is more dev intensive, it is also more valuable. I would ultimately conclude that building the webhook is the better option. While it is at least double the work, the value that it will bring the user is significant. There is also a 3rd variable, extendibility, which I use to tiebreak in some situations. In this case I would give the export feature a grade of 1 and the webhook feature a grade of 4 for extendibility. The webhook is a foundational feature and will setup the infrastructure for future webhooks, supporting other events to trigger calls, Zapier integration, etc. While the export can be extended to allow for customizable output and exporting of other resources, it really doesn’t set up that much relative to the webhook functionality.

Once you start getting the hang of quantifying priority, it starts to become 2nd nature. I only resort to this framework when I am having trouble making a decision. Otherwise I am doing this quickly in my head.

As I said earlier, in the case of Rapid SaaS building, if you are really struggling with priority, you are most likely overthinking it and should default to punting the feature until after launch. Focus on doing less, better.

Backend & Frontend Language

Next post I will dive into my thinking behind language choice and walk through the tech stacks that I have used for my projects. Javascript devs beware 🙂

If you liked this piece you can sign up below to get notified when the next one is published.

Follow me on twitter below and let me know what you think!