In June 2011, I was doing freelance work for several e-commerce companies and a few of my clients asked me to build them a store locator for their site. I ran the idea of turning that into a Micro-SaaS through the meat grinder and determined it had potential. Once you get an idea that looks worth doing, you should carve out time to build a Minimum Viable Product (MVP) as soon as possible. Getting hung up on an idea that you never execute is worse than having no idea at all.
About three weeks later, I had a flight from San Francisco to Buenos Aires. Somehow I was able to book a first class flight with frequent flyer miles by adding a stopover in New York, so I was looking at 30+ hours in a comfy first class seat or an airport lounge. I decided to build the entire first version of the product on that flight. So the moment I got on the flight, I put on headphones and fired up the text editor. Thirty hours later I landed in Buenos Aires. The first thing I did was go straight to my hotel and pass out for ten hours because I had about a dozen glasses of free champagne and eight cups of terrible airline coffee.
But as soon as I woke up I deployed the site and my Micro-SaaS was live.
I emailed all of my previous e-commerce clients and within 48 hours we had five customers paying five dollars a month. Storemapper went from a sketch of an idea to paying subscribers in less than 72 hours.
This is a classic testament to Parkinson’s Law: that work will expand or contract to fill the time allotted to it. If you give yourself an unlimited time horizon to launch a product you’ll likely never finish it. Setting a defined period of time, and drastically cutting whatever you need from the scope to make it happen, is the best way to launch a small product.
Shipping a Minimum Viable Product
This chapter is going to focus primarily on the concepts of shipping a Micro-SaaS MVP. I frequently get more tactical questions looking for specific resources on how to learn to code, or which frameworks to learn, and so on. I learned to code almost five years ago now and the software world moves quickly. Many of the resources that I learned from are now stale or defunct. I’m not an avid programmer. I think of myself as an entrepreneur who codes or someone who likes to quickly hack together something that works and is valuable. I don’t stay that up to date on the actual programming community and I’m just not the best person to answer specific questions on what resources to use to learn to code at this point.
Build first or Pre-launch?
I want add my opinion to a common debate in the world of minimum viable products. Should you pre-launch or build a working product first? Pre-launching usually means some kind of effort to build a launch email list by blogging about the topic, reaching out directly to potential customers, doing consulting and case studies or basically anything else besides writing code. The goal is to build trust and a list of potential customers so that you can have a big launch and quickly get to a decent level of recurring revenue. The big benefit from this, aside from having your first customers ready on day one, is that you can refine the idea with your target market and get closer to product-market fit without having to write code.
I think that products that are pre-launched are more likely to succeed, BUT I believe that pre-launching is not the right strategy for most people.
The main reason is that pre-launching is a long game. It requires patience and commitment and you don’t know if this is a viable business idea yet. Yes, a well pre-launched product will probably do better all things being equal, but all things are not equal. It’s a huge time investment to pre-launch a product. Your primary mission at this point in the game is not orchestrating a splashy product launch. Rather you want to get to paying customers, and thus real feedback, as fast as possible. Pre-launching just delays this.
Another common reason not to bother with a pre-launch is that the target market for most good Micro-SaaS ideas is just not interesting enough to pre-launch with a blog or podcast. We still don’t really have a blog for Storemapper because there just aren’t that many interesting aspects to store locators. It does a job, simply and cost-effectively, which is the best kind of Micro-SaaS. There is probably a correlation between ideas that are too boring to blog about and good Micro-SaaS ideas.
My recommendation for most entrepreneurs is to follow the tips in the rest of this chapter to massively pare down the scope of the MVP and just launch it fast.
What I mean by “MVP”
The idea of what counts as an MVP has been the subject of considerable debate since Eric Ries popularized the term in the Lean Startup. A full discussion could be (and probably is somewhere on the internet) its own ebook series. But my opinion is that for Micro-SaaS an MVP should actually do the job it purports to do.
The publication of the Lean Startup has lead to a rash of tactics that supposedly allow you to learn whether customers would buy your product without the hassle of actually building a working product. The most common variation is simply building a landing page with a demo video explaining how the product works and asking people to input their email to “sign up” – then after they submit their email, surprise, you tell them the product is not quite ready yet, or they are on the waitlist, and you’ll notify them when the product is ready. You use that data on email signups to decide if you have “validated” the idea.
The Lean Startup introduced these ideas as an alternative to the dominant methodology for venture-backed startups prior to the book’s publication in 2011. Startups at the time would raise millions of dollars on an idea, spend a year or more building a perfectly working version of the software and then run a huge product launch campaign. Most of the time it was only then, after a year or more and millions of dollars spent, that they would discover nobody actually wanted the product. Lean tactics are a compelling alternative to that VC startup approach, but Micro-SaaS products are not even remotely in the same category.
I think the data you get from an email opt-in experiment is mostly garbage. In SaaS the only thing you ultimately care about are customers that will pay you money month after month. You can’t learn anything about whether you have a product that customers will pay for on a recurring basis until you start charging them and you really can’t start charging them until you are giving them some form of value.
So I firmly believe even the MVP for Micro-SaaS should actually do what it says on the label so you can start providing value and charging customers right from the beginning. Note that this does not mean that I think everything must be solved with code, see the section below on making features by doing manual work by hand behind the scenes.
What if you can’t code?
I’m going to be honest, I have not met many people who have successfully bootstrapped a SaaS business that were not themselves developers. You don’t have to be a wizard ninja coder – I had only been writing code for nine months when I built the first version of Storemapper – but your odds will be substantially better if you are able to build and launch the business yourself.
But, if your plan is to hire a developer, the rest of this chapter will help you really refine the scope of the first version so you can minimize your upfront cost and start getting paying customers earlier in the process.
Building an MVP: Don’ts
The first version of Storemapper was hilariously bad. It lacked many features that anyone designing a SaaS app would deem essential.
You can download screenshots of the original app by dropping your name and email in the form here. These 5 images represent almost the entire app at the time of launch.
Mature SaaS apps are complicated beasts but lots of what they do is not part of the core value, not part of the job the customer is hiring the app to do, but ancillary features. If you use a lot of SaaS products it’s easy to accidentally include these in the first scope because of course you need them right? Wrong, most can be left out for the launch. Here are a few broad categories that you can aggressively trim in order to ship quickly.
Only build for new users
Do not build features that only current customers would need after months of using the product. Focus only on delivering value to new users because that’s all you will have at first.
You can comfortably skip the following features for an initial launch:
- Change billing method. One valid credit card is all you need at the beginning.
- Change subscription level. Hopefully you only have one plan, but otherwise you can change plans manually for customers on request.
- Update account info, reset password, change login details. Again, do this manually when needed
- View past invoices. Customers will request this feature when it’s necessary (tax season) wait until then.
- Leave out a button to cancel their account. Just put an email link so customers can request to close their account. The main benefit here is it gives you the opportunity to ask follow-up questions about why they are canceling.
Go very light on branding
Good branding is important for a software business but it is most valuable when potential customers’ first impression of your business is visiting your website without any prior contact. Early on you will be acquiring your customers manually so you can build trust and explain that the app is under development. All you want to to do with launch branding is reassure people that this is not a scam and it’s safe to enter their credit card details.
- Do not hire someone to make you a logo. Use plain text and a free webfont, unless you are a designer and can crank out a logo in minutes.
- Do not build a fancy landing page with slider images, testimonials (because you don’t have any yet), pricing tables and gorgeous full-page stock images. Grab a cheap SaaS landing page theme and tweak it if you must.
- Do not spend hours in CSS building a custom UI framework. Use something off the shelf like Twitter Bootstrap. Tweak the color scheme if you absolutely must but I did even bother.
- Do not hire someone to make you a hand-crafted narrated “explainer video”.
Other common features that you can skip
Below are a few larger features that can be skipped. This is not an exhaustive list. The broader point is that almost every aspect of SaaS besides the core job to be done can probably be cut for the MVP.
- Multiple plans and pricing options. Almost all SaaS products have multiple plans with a nice table laying out the features at each plan level. This is a great strategy for segmenting your customers and maximizing your revenue. But it is not something you should include in the MVP because the code required to segment certain features and allow users to upgrade/downgrade plans is substantial. Whatever features would be in the top tier plan should be the only plan.
- A free tier (or freemium). This is so important I’m going to have a whole section on it below.
- Multiple payment options. Pick one (I suggest Stripe) and ask for a credit card upfront. If customers like your product but want to pay you by check or Paypal, tell them sorry, it is really not worth the hassle.
- Multiple users per account. In mature SaaS you will come across valid situations where the billing receipts need to go to accounting, the main email notifications go to the manager but a three people on the product team will be using the product day to day. There is value in adding clear support for this as the product matures but in the early days just tell them all to use the same login.
It’s impossible for me to predict every single SaaS feature that won’t be necessary for an MVP but try to generalize the principle as much as possible, reducing any bit of SaaS trappings that do not directly add to the core superpower you are trying to give your customers.
Leave out everything that you can do manually.
An MVP should be a lot like the Wizard of Oz. It looks like a big monolithic entity but behind the curtain is a person pulling the strings and levers to make it all work. It’s increasingly possible to launch “software businesses” without writing any code at all. You can string together some services like Unbounce, Typeform and Zapier and customers can sign up and pay through your site but behind the scenes you just have humans doing the work that appears to be software. With SaaS it’s generally not possible to completely avoid building an app but if a certain feature can be done manually and customers would be fine with a 24-hour turnaround, do it manually.
For example, there were tons of edge cases and bugs in the process for uploading a CSV file in Storemapper. All I did was recover from any error with a note along the lines of, “Sorry something went wrong! Please email this file to [email protected] and we will upload it for you ASAP.” I would re-format the file, make bug ticket, and upload it manually. It took months of coding, little bug fix by bug fix, to finally get that feature where it would work most of the time but most customers were perfectly satisfied with early manual process.
Avoid the faux professionalism
When you are selling to businesses there is a temptation to want to make your “organization” seem more professional than just one person hacking something together. While I’ve certainly fallen for that myself, in general I have found avoiding this kind of thing is both faster to launch and has some surprising benefits. As Storemapper grew a few competing apps surfaced that purported to be larger companies, either with highly corporate landing pages or listing a dozen people on their team page (which I can still can’t believe). But many customers explicitly told me they preferred to support an “indie developer” or solo entrepreneur and became some of my best customers. Even better, the kind of customers that would really prefer a more professional sheen to your product are likely to be the most annoying kind, asking for paper invoices and all kinds of custom work. Save time and avoid all this nonsense.
- Don’t bother with email addresses at your custom domain if it will take you more than 30 minutes to setup. Use a gmail account.
- Don’t use a fancy help desk app in the beginning. Just reply to the emails.
- Do not for the love of god put your phone number on the website. Some entrepreneurs may disagree here, arguing that phone calls with customers are a valuable resource. But for me, flat out refusing to do phone calls was the only way to keep focused on building a great product for all customers.
Eventually I decided to take this process one step further and explicitly brand my app as a small business. The footer of every main screen of the app has my face and the quote below. Which may seem a bit weird but a lot of customers like it.
Building an MVP: Do’s
The biggest thing to battle in the stage of the game is scope creep: an ever expanding list of things you need to do before launching. The most important part of this chapter is the Don’ts above that will help keep that scope pared back. But here are some things that I recommend doing.
Use (and pay for) existing services
I can’t emphasize this enough. Re-inventing the wheel is the enemy of the MVP. Today in software there are so many open source or affordable building blocks out there, mostly the result of developers trying to scratch their own itches. Time is by far your most limited resource. My triage for any new feature idea/request looks like this:
- Don’t build it.
- Really, just don’t build it.
- Okay, fine, look for some existing service that can get you a good enough version of it.
- Really, there’s nothing? Go look again?
- Still nothing? Okay, code the simplest possible version of it from scratch.
You want to use services with the fastest time to ship, even if they are not the most scalable or most cost-effective in the long-term. I used Ruby on Rails, hosted on Heroku, with Stripe for billing and Cloudflare for SSL. Whatever their relative merits to their competitors, each one is unequivocally the fastest-to-done in their category. I still use all of these by the way.
As the product has matured, I rolled my own solutions and cut out reliance on certain paid products, but Storemapper still leverages over a dozen bolt-on services. The net cost is a few hundred dollars a month and it’s completely worth it. The full list is here on Medium.
Separate your app and your landing page
Of the many things I did wrong on my first Micro-SaaS, one of the most annoying was this to setup a separate WordPress installation for the landing page and other “content.” I recommend having your root domain (your-biz.com and www.your-biz.com) point to a WordPress site with your landing pages and your blog at your-biz.com/blog. Then have your actual application hosted at app.your-biz.com or some other sensible subdomain.
There are literally tens of thousands of great SaaS landing page WordPress themes for very cheap that you can drop in but not nearly as many good landing page themes for Rails/Angular/Meteor. Later on if you want to have a designer work on the landing page, you will find almost all of them can get in and directly edit a WordPress site themselves but many will not be able to work on or deploy a Rails application.
It will also be much easier later on to add additional landing pages or a blog. This is all the kind of content you want at your root domain and indexed by Google for optimal SEO. I did not do this at the beginning and it is both a big pain to go back and change later. I recommend setting this up from the start.
Do ask for credit cards upfront.
Do not allow people to sign up without a credit card. There is a lot of debate in the SaaS world about whether requiring a credit card upfront or after the end of a free trial is the more optimal approach. But this debate is irrelevant when it comes to an MVP.
You will see a lot more signups without requiring a card upfront, but a huge chunk of them will be time-wasters and not serious buyers. The onboarding process will be very manual and support tickets per customer very high at first. If you let in the time-wasters you’ll be doing 10x the support work for a few percentage points more long-term paying customers.
Once the product is more mature and the onboarding flow more automated, it may make sense to test whether asking for a card upfront generates more long-term revenue, but in the MVP stage it is a nightmare and should be avoided.
Lastly, it is also a huge hassle to code a workflow to bother customers to add their card after their free trial expires, freeze their account if they don’t, and so on. Skip all that and ask for the card right at signup, set it up to automatically assign them to a plan after the free trial end unless they cancel.
In a similar vein I really recommend against a free plan. This the same reasoning behind requiring a card upfront. At this stage you are still maximizing for information and feedback. You want to know for sure that the product adds value to every single customer you bring on and the only way to judge that is people continuing to pay.
One of the big benefits of the no-freemium, card-upfront structure is that you can always keep your costs under control preventing any explosions in free trials or free plan usage. If you’re still not convinced, read about freemium almost caused Baremetrics to implode.
If you look at your product and you are convinced that freemium is the way to go, you might want to consider whether this idea is in fact a good fit for Micro-SaaS. The cost structure of freemium is risky, do you have deep enough pockets to actually lose money on your business in the short term if free users grows too rapidly? If people need to use your free product for months before they consider upgrading, I would question whether the product provides enough immediate value to be a Micro-SaaS business, though it may be a good fit for a funded startup.
Use a single price point.
Every successful SaaS business you’ve ever seen has a fancy pricing table showing all the different plans. But I would strongly recommend against this at the MVP stage. One monthly plan is plenty.
The business logic behind offering multiple subscription levels, prompting people to move between them and limiting access to certain features is immensely time-consuming to build. In the beginning you are just throwing darts at the wall on pricing. Your pricing will be wrong and you’ll need to change it dramatically as you go, so I don’t think you gain much by segmenting your first customers by different totally random price points.
Storemapper started with a single price point, $5/month. In retrospect this was ludicrously low as our average revenue per user in recent cohorts is around five times that. But I still think it was a pretty good move. You can always raise prices and find ways to upsell customers later. In hindsight I would have started with something between $9-15/month and raised it as the features were ironed out. More on adjusting pricing later.
Admin Login: The one bit of code your app must have
This is one feature you might be tempted to cut in your quest for a truly minimal product launch. But you must give yourself superpowers to swoop in and use the app on behalf of your customers. Your answer to almost every question from early customers should be to just login as them do it for them. Then send them screenshots or a screencast of how you did it so they learn next time. You need an admin screen that let’s you view all your users and then login as them.
It’s literally five lines of code in Rails with Devise and it can make or break your onboarding process early on.
It’s becoming more common in some SaaS apps, but you cannot imagine how magic it seems to customers who email support asking “How do I do X” and you respond with, “Here’s how you do it, also I already did it for you.”
Shipping a first version of the product is the biggest hurdle in the entire journey to a profitable software business. When I talk about my SaaS business I constantly meet people who have one pretty decent app idea that they go years without bothering to make a specific scope and carve out the time to build and launch something. Having one idea that you constantly talk about, but never execute on, is the biggest trap in entrepreneurship. Use this chapter to pare back an idea to it’s essence, schedule the time and ship it. I’ll leave you with some awesome Hemingway on Coding quotes that always get me in the mood to get to work.