Chapter 7: Retention & Customer Support as a Solo Founder

<< Chapter 6: Thriving in the Long, Slow, SaaS Grind

Churn is the biggest threat to a new Micro-SaaS business. Perhaps the toughest challenge of running a SaaS business by yourself is consistently retaining customers. However, keeping happy customers with a high retention rate makes every other part of running a Micro-SaaS progressively easier so it is critical to get your support and retention strategy dialed in early on.

If I had to point to a single thing that has so far made Storemapper a success it would be its incredibly low churn rate. Successful SaaS businesses of all types – bootstrapped or funded, large or small – will typically see monthly churn of 5% – 8%. Churn much higher than that will usually kill a SaaS business. Storemapper’s churn rate through five years of growth has consistently stayed around 1-2% per month with a substantial number of months showing negative net churn, where additional revenue from existing customers (upgrades) bring in more money than the loss from churn.

In this chapter, we’ll take a look at all the ways high retention and low churn makes every other challenge of Micro-SaaS easier. Hopefully, I’ll convince you of its importance. We’ll look at the attitudes and opportunities when handling support as a single founder and how to balance support with your other priorities. I’ll dive into my favorite tools and introduce the idea of automating empathy: a series of tactics I use for effective, automated, proactive support.

Lastly, we’ll look at a few tips for staying sane through what can be one of the most stressful parts of building a Micro-SaaS business. So let’s get started with perhaps the most important chapter in the book.

Why retention is so important

A larger organization might break down certain aspects of support into separate responsibilities like pre-sales, onboarding, inbound support requests, and tracking bugs. In a Micro-SaaS, with just one person or a small team, all these aspects are grouped under the broader topic of support. Improvements in one area will cause associated improvements in other areas. Great support (using my broad definition) has a direct effect on a number of key business metrics.

Conversion from free trial to paid users: An intuitive onboarding process and fast, useful answers to common questions will maximize the percentage of your free trials that decide to become paying customers. This is particularly important if you have competitors that they might be evaluating concurrently. A single unsolved support ticket during the free trial can be enough to tip a potential customer toward a competing app, even if it would be a worse option for them in the long run.

Churn: Repeatedly frustrating customer support interactions are a great way to increase the number of customers canceling each month. At Storemapper the primary reason customers would cancel their subscription is that they themselves were closing their business.

Expansion Revenue: Great support includes surfacing various features of your app at the right moment of need. Getting this process dialed can also be a great way to upsell existing customers to premium plans and increase the revenue from existing customers (called Expansion MRR). As an example, we do our best at Storemapper to make the process of uploading a CSV file as easy as possible; but it’s a notoriously difficult UI across all SaaS apps. Right there on the page is a small but convenient pitch for our “sync from Google Drive” premium feature for any customers who find the process too frustrating. This has the double effect of providing a solution at a common point of friction and increasing our Expansion Revenue for the customers who decide to upgrade at that point.

High retention rate and great support also have indirect effects on almost every other key metric for your business. Happy customers stay customers for longer, increasing your lifetime value (LTV). Keeping more of your free trial customers for longer reduced your customer acquisition cost (CAC) allowing you to confidently invest more time or money on each new free trial customer. Customers who have just had a spectacular support interaction with you are substantially more likely to provide referrals to other customers.

High retention means you can justify growing more slowly because you’re not putting new customers into a leaky bucket. There’s less pressure to constantly add customers. You can justify high touch “concierge” onboarding for new customers because you know it’s unlikely that effort will be wasted. Strong retention means that once your business matures, your revenue becomes more predictable month to month and you can rely more on that revenue to pay your own bills or employee salaries.

Have I gotten your attention yet? Support is important.

Customer Support as a Solo Founder is hard

Support is a difficult but important gig. There is a reason startups have begun upgrading the title (customer success, customer happiness guru) and trying to attract higher quality talent to these positions. Good support is critical to onboarding and retaining paying customers.

It can be challenging to balance providing great support to existing customers with further developing the product to attract new customers. If you did a minimum viable product (MVP) launch correctly, your product currently lacks a ton of features and has more than a few bugs. You will be getting a lot of bug reports and feature requests (and occaissional feature demands) from customers who are at times frustrated and confused. If you launched really well, the backlog will be much more than you can reasonably handle.

Navigating support as a solo founder can be a minefield and it’s important to have a strategy before frantically wading into the queue of emails and tickets.

The Guiding Principle: Every support ticket is an opportunity

But there’s hope. It’s too easy to view support tickets in a negative light. It’s a long task list that you need to check off before getting back to work on product. It’s a stream of grumpy users who can’t even read the dang instructions you so clearly wrote out inside the app.

But this is completely the wrong mentality because the reality is that every support ticket is a massive opportunity. Your worst customer is not the one sending you a support email every day for two weeks, your worst customer is the one who signs up for your app, then cancels without ever giving you a word of feedback. Customers who take the time and energy to write you a support email have now taken a vested interest in getting your app to work for them. It’s important to listen to them, ask follow-up questions and not just view the goal as getting the customer from A to B as quickly as possible.

The apex of this principle is that customers who have an amazing support experience will become more loyal, and more likely to recommend your app, than customers who are just happy with the app from the beginning. An apology, done well, is a powerful thing. It’s embarrassing when your software breaks. It can be tempting to try to cover up or smooth over issues but you’ll be missing out on a key retention opportunity by not giving your customers an open answer and an honest apology.

I can’t fully explain why it works this way, but customers who encounter a small bug but then receive a sincere apology and full explanation often become more avid customers than those who had a bug-free experience. Sure, if their onboarding experience is a disastrous maelstrom of bugs, they may get frustrated and leave, but a small bit of friction followed by a personal email explaining why that happened often leads to customers more likely to stay on board for longer and even more likely to refer new customers. I’m not qualified to speak to what’s going on there psychologically but I think they feel more a part of the experience – like they are helping you build the product together – and are thus more invested in your long term success, even though they are still the ones paying you money.

So view every support ticket, not as some drudgery that you need to plow through, but a list of opportunities to create lifetime fans of your product. Act accordingly.

Attitude hacks: Providing great support as a team of one

Don’t use the Royal We

When I first started answering support requests on my product I used the Royal We:

“We are working hard on that issue for you. Please bear with us…”

But I’m not the Queen of England and there was only me working on the issue. Instead of trying to give the impression that you are a big company with a massive support team, I am of the opinion you should just use “I” and be exactly what you are. There are more customers out there who are excited to support a small, indie, startup company than ones who absolutely prefer to purchase their software from a MegaCorp.

Seriously, it’s okay to be honest

Somewhere along the way, I decided not only to just use “I” but to be more or less completely honest about what kind of a product and company my customers were interacting with. I put a picture of my face and a little intro that I was the sole operator of the product and a traveling, independent entrepreneur. I started this blog, being totally transparent about the process of building the product. I removed any veneer that implied Storemapper was a big professional product run by a team of seasoned software veterans.

At the time I thought it was risky but it has so far worked great. Many times I’ve had customers say they are going with Storemapper over some other solution because they prefer to support independent developers and entrepreneurs.

This is in the footer at all times inside the Storemapper app if you can believe it.

But don’t overshare

Honesty can be taken too far into the realm of oversharing. I used to give very detailed responses to customers about why things weren’t working a certain way. Unless you are an API business and your customers are all developers themselves, detailed technical responses to customer inquiries can be time-consuming to write and often more confusing than helpful. Give the truth, but edit it down to a need to know basis. It’s the difference between:

Sorry about that, we upgraded our Resque gem which caused Bundler to update our pg gem to a version that’s incompatible with Heroku. We had to rollback the deploy and our last database migration.


Sorry about that, upgrading a component of our software stack caused a temporary issue. Everything should be working now. Anything else I can help you with?

Apologize often and empathetically

It easy to get sucked into viewing support inquiries as an onslaught of attacks. If this sounds absurd to you then you’ve never woken up to dozens of angry ALL CAPS customer emails about stuff that you totally already explained in the FAQ if they would just bother to take a second and look it up…

It’s important to stay zen and apologize frequently. Even if you don’t mean it. Even if you’re on the 15th email with a customer with a mind-numbingly obvious question. Say you’re sorry and repeat back to them how frustrating this must be for them. A little empathy goes a long way.

Do it > Show it > Tell it

Email is an imperfect medium for explanations. The most important feature to build after an MVP is a back-end admin panel that lets you log in as your users. If they are having trouble finding a setting, log in for them and change it (Do it) and then explain how to do in the future. Sometimes you need to “teach a man to fish” but most of the time it’s an issue that the customer only needs to do once anyway, so it’s not critical they learn how to do it for themselves.

Use Skitch to show with marked up screenshots or better use Screenflow to make a quick screencast showing how to do certain tasks (Show it). These have the benefit of being more explanatory and more readily re-usable than a typed out email. Your medium of last resort should be a long-form written out instructions (Tell it). Your customers are busy and just want to move on as quickly as possible. Do It is better than Show It, which is better than Tell It.

Ping customers even when you have no updates

Let’s say you get a bunch of customer emails about roughly the same issue. You look into it and discover there is a pretty tricky bug that might take you a day or two to fully fix and push live. Your first reaction may be to dive right into the code and get to work on the fix, then come back to the customers triumphantly explaining that the bug is fixed now and all is well. Stop.

Customers really don’t like silence on the other end of the line when they submit a support ticket. A better approach is to immediately email all of the customers to let them know you received their email and are working on a fix and will let them know when it’s ready. If a day goes by and you still haven’t fixed it; send another round of short notes letting them know you haven’t forgotten about them and a fix is still coming soon.

This kind of little thing is the difference between the adequate support that will retain most customers and excellent support that will turn them into champions of your product.

The One Weird Trick: Massively over-deliver value

Throughout the lifetime of Storemapper, I consistently underpriced the service relative to its value. The starting price of $5/month was almost ludicrously low but the first version was so buggy that I just wanted to charge something other than zero.

Successful SaaS entrepreneurs will often advise you to raise your prices. This is typically good advice. Folks launching their first products, particularly programmers, have a tendency to undervalue their products so much that you can often raise prices with no negative effect on the number of new customers. This dynamic is true for most SaaS businesses up to surprising levels. You keep increasing prices by 50% and you see slightly fewer customers sign up, but net revenue continues to rise.

But there can be a hidden downside to pricing your product almost exactly at your customers’ willingness to pay. Providing great support is primarily about beating expectations. High prices often come with high expectations. Raise your prices by 50% and every single new customer now comes with those higher expectations. This can quickly ratchet up the stress level of every support interaction. The customer feels they are paying quite a lot of money and only just barely getting enough value for it. Any little hiccup, bug, or delayed response can become infuriating for them.

By contrast, keeping your prices low-to-reasonable may leave a little revenue on the table, but allows you to massively over-deliver value. If most of your customers would happily pay twice as much for your product, they will be much more relaxed with their support inquiries, and much happier to wait a few days for their issue to be resolved.

At several points with Storemapper I tested higher prices and found it would generate more revenue, but I decided to revert prices back because I felt it wasn’t over-delivering value. I Immediately felt a relaxation in the tone of conversations with customers who signed up at the lower prices.

Tools of the trade

When I first started writing about Storemapper I strongly advised against getting a lot of tools for customers support. I tested out all the major support desk products and found they were over-kill and cumbersome for what you need solo or as a small team.

The minimum set of tools you need for good customer support breaks down into three simple solutions: a single inbox to queue requests, a way to reuse common responses, and a searchable help desk site.

If you’re on your own then a shared inbox can just be a dedicated email account. There are dozens of Gmail plugins with the ability to create re-usable templates for common replies, but I like to use TextExpander because it works across all apps.

Even though there are many apps offering a help desk platform as a service, I think a simple WordPress install is the best route to go for FAQs and support articles. The main reason is that every dedicated help desk SaaS I found lacks a feature that I consider critical: a way to create internal support posts that only your employees can view and a single search form that looks across both external (for customers) and internal (for employees only) posts. This is very important as you start to build a support team and if you set up the structure right at the beginning you will save yourself the hassle of migrating hundreds of support articles later.

I recommend setting up a simple WordPress install and buying a “help desk” or “FAQ” theme for a few bucks. The KnowHow theme is the one Storemapper still uses. Then you can install any of the 1,000s of membership plugins that allow you to tag posts as visible only to members, or people logged in with a WordPress user account. As you start building out your library of support articles, you can always document some common quirks or bugs or other things you don’t necessarily want to fully share with all your customers. Tag them as members-only to hide them from your customers. When you bring on your first customer support employee, all you need to do is give them a user account for the WordPress site and like magic, they will be able to search both internal and external posts as they work through support tickets. This is incredibly useful for onboarding your first customer support employee and worth setting up from the beginning.

That’s all you need to get started.

A dedicated email, a way to create reusable responses and cheap WordPress site are all you need in the early days.

Once Storemapper was a little more mature I added Intercom as our primary support tool. We still use WordPress for the support articles but everything else runs through Intercom. I’ll go into more detail in later chapters on how we use it to collaborate on our queue of support tickets and generate all kinds of helpful automated messages to pre-empt common support issues, but in my opinion, Intercom is overkill until you have enough revenue that you are adding employees to do support.

Tactics: Automate Empathy

Ok. I’ve been going on and on about attitudes and mindsets, but let’s dig into some actionable tactics for providing great support. My overall methodology is to create a feedback loop between each support request and small tweaks to the product to make that issue less likely for future customers. You want to make each point of friction for your customers incrementally less likely over time. The most effective tool for this is empathy. Viewing a support ticket not just as a problem to resolve, but as an opportunity to get another person’s perspective on something you missed in your product. With each ticket try to understand how and why this became an issue and evaluate whether you can make a small change to the product to preempt this issue.

I call this process automating empathy, deeply understanding and learning about what your customers might struggle with in your product and building automated processes that either solve the problem entirely or provide context-specific help at exactly the right moment.

Automating empathy is a tactical framework for retaining customers. It involves regularly using your own app and really putting yourself in the shoes of your customers. Using a variety of analytics and conversations to deeply understand the points of friction for your customers. And surfacing the solutions to those automatically and in the appropriate context. My interpretation of Automating Empathy goes against a considerable number of design principles in fashion right now so you’ll have to decide on your own which one makes more sense.

Here are a few:

In-app screencasts

Any complex page of your app should have a short screencast demonstrating how to use it. For busy people (your customers) this is the fastest way to digest how to a product. Embed it right there on the relevant page. It’s very vogue these days for UX designers to say “If your product needs an onboarding video then it’s too complicated and you should just make the interface simpler.” This is BS in general and completely inappropriate for Micro-SaaS. Maybe if you have a six-person interaction design team and a budget to run usability focus groups all day, you can afford to do the iterations to get to that stage but in Micro-SaaS just use a freakin’ screencast. I use Screenflow to record screencasts with audio of myself using the product and upload them to Youtube or Wistia. It doesn’t need to be fancy or well-produced, just short, clear and useful.

Helpful UI Empty States

Onboarding is the most critical time for preventing churn and the most common source of support requests. During onboarding, your customers will encounter a lot of UI “empty states.” Their dashboard which should be full of tasks, contacts, stats, etc, currently has none of that stuff. So what should you put in the UI when the datasets are empty? A lot of designers these days love the Skeleton UI where you fill it up with a kind of mocked up sketch of what the UI element will look like when it’s full.

the ‘very fashionable’ skeleton UI for empty states

This is elegant but unhelpful. A better idea is to have the empty state show how to fill it up with data. This is a great spot for a nice in-app screencast but visual information or a link to a relevant support article can also be helpful. In Storemapper the main app page is a list of your current database of store locations, however, whenever that list is empty it reverts to an embedded screencast reminding the user how to add/upload store data.

Storemapper’s empty state: a helpful Youtube video on how to add data. A little ugly, but much more useful.


It isn’t the most aesthetically elegant of design solutions, but it works wonderfully well at pre-empting customer questions: this thing is empty now, here’s how you fill it up.

Custom Onboarding Flow

An even more advanced version of better empty states is a custom onboarding flow. This is becoming more common with good SaaS businesses. After sign up, rather than dumping you directly into the main app screen and throwing a comprehensive walkthrough of tooltips and popups at you, a custom onboarding flow takes the user through a series of squeeze pages (single-purpose pages without the usual navigation menus) that walk the users through the primary onboarding steps one by one so that by the time they arrive at the primary app pages empty states have been bypassed altogether. In Storemapper we found that an important first step was installing our code snippet on the customer’s website. We surveyed our users to find all the common platforms they used (Shopify, Bigcommerce, WordPress, etc). Then made short custom onboarding screenshots for each. The first page after sign up now is a squeeze page that asks the user which platform they use and provides a custom walkthrough for installing or snippet before moving on to the rest of the app. This kind of hand-holding onboarding does wonders for getting customers to key milestones in your app where you can begin providing value. You will find a small number of people signing up are just trying to test out the app for a client or future research purposes. Make sure there is some way for these customers to bypass the squeeze pages and get directly into the full app.

BCC support on critical error emails

Most B2B SaaS apps will have some kind of background processes and some method of emailing the user that “hey, something went wrong.” BCC your support inbox on these emails. Not every user will take the time to email support. Sometimes they will just try the same thing ten times, get the same error message, and cancel their account and look elsewhere. BCC’ing support on error messages lets you monitor the frequency of errors and at least gives you the opportunity to reach out and help the user. This is a quick win along the general principle of making your support process more proactive, rather than exclusively reacting to inbound tickets.

Better Error Messages

Another quick win along the theme of providing helpful information in the right context is better error messages. So often I see apps where the error message is something infuriating like “Postgres Error: record failed to save to db.”

Your error messages should follow this pattern “Sorry, but [actual thing] was not saved. The most common issue is [common issue]. You can find more info on how to [current task] here [link to support article]. Or contact support [direct email link or chat button]”

  • Humanize the language. Avoid generic programming words like
    “record” in favor of the actual thing in question.
  • Use full sentence structure.
  • Suggest the most common problem
  • Provide helpful links
  • Provide one-click way to reach support

Track and trigger off errors key progress metrics

Once the number of customers reaches a level where it becomes hard to keep track of each one individually, it’s important to start automatically tracking errors and key progress metrics. Errors are less about actual application errors in your code, but points of failure where something is going wrong in the user experience. For example, your application code may correctly handle someone entering their credit card details incorrectly and provide feedback, but you should setup something to track if this happens five times in a row and trigger a message connecting you with the customer to provide assistance. Similarly, you should setup a way to track your users through the key steps of your onboarding funnel and trigger an alert when they get fail to pass a key milestone.

How to stay sane

Customer support is hard work. It’s very easy to end up frazzled and exhausted just getting through the day’s support tickets, much less having energy in the tank to switch modes and work on the product. Here are a few tricks I’ve developed for staying sane and productive while handling all your own support tickets.

Last In, Last Answered

Answer the most recent customer questions first. The main reason for this is that customers will often fire off a support question and then, given time, figure out the answer themselves. They will almost never follow up an initial support request with “never mind, I figured it out.” You may spend 15 minutes digging into a three-day old support ticket only to find out the customer already solved it.

Remember you can only do your best

Answering a deluge of support questions can feel overwhelming and discouraging but remember it’s actually a pretty good sign. It means:

  • Lots of customers are interested in your product
  • You’re probably doing things right in terms of MVP, building just enough to keep growing customers and iterating on the product.

This means that if you are doing things really well by launching early and often, you will almost certainly generate a support request queue that you can’t satisfy entirely. You’re no longer some cog in a giant machine, being handed only enough tasks that it’s reasonable for one person to do. I had to constantly keep reminding myself, and in some cases explicitly to customers that I’m just one person and I’m doing the best that I can.

Set a time cap, then get back to product work

Great customer support is important, but if you are building Micro-SaaS or any early stage product, continuing to improve the product is fundamentally more important in the long run. It is critical not to wake up, spend 16 hours on support emails and then cry yourself to sleep. You have to set aside time and energy to work on the product to keep the business moving forward. Set a maximum daily time cap on support time and stick to it. Block off certain days where you ignore the support queue entirely. Work on product first thing and don’t start on support until the afternoon. Be proactive by prioritizing product work first. When you switch to support mode, provide excellent support, but recognize that you’ll need to set it aside sometimes to keep the overall business moving.

Chapter 6: Thriving in the Long, Slow, SaaS Grind

<< Chapter 5: Getting Your First Customers

So you’ve run dozens of ideas through the meat grinder, launched a few that went nowhere. Finally, you launch one that starts to attract paying customers. Congratulations, you’ve made it far farther than most.

What happens next?

Most SaaS businesses will at some point encounter “the long, slow, SaaS ramp of death.” Take a look at two examples. Baremetrics was a rocketship (by bootstrapped SaaS standards) going from idea to $8,300 in monthly subscriptions in just six months. As a solo founder, this is about as good as it gets for a SaaS launch. As the revenue poured in they raised a bit of money and staffed up for the hockey stick revenue growth to come. However, most revenue charts end up looking like this:



Baremetrics almost ran out of cash because of slow grinding revenue growth, but after making some tough changes, they found their way to profitability1.

Convertkit, an email marketing app, had almost the inverse experience. Nathan Barry spent over a year and a half with monthly recurring revenue (MRR) hovering around $2,000. His long, slow, grind happened right at the beginning because eventually they found the right product/marketing combination and took off. Two years later Convertkit is running at $600,000 a month in subscriptions!

My business, Storemapper, was a grind in the beginning, in the middle, and basically still is. Revenue growth has been more or less linear since it’s late 2013 launch date. While I certainly wouldn’t complain about a period of hockey stick growth, a consistent grind is not entirely a bad thing. For one, it’s predictable. I haven’t had to deal with any of the cashflow crunches that fast-growing SaaS companies seem to inevitably run into. It has also allowed me plenty of time to develop strategies for managing, and thriving, in the long, slow, grind that is SaaS.

The power of SaaS is that recurring revenue compounds, eventually yielding a very predictable stream of revenue. But it can take a long time to get there. For many Micro-SaaS businesses, it seems to take at least a year before the revenue can meaningfully affect your lifestyle: either allowing you to work full-time on it or hire people to help you run it. Before you launch, consider how you will manage your life if you have to keep your day job and run a growing Micro-SaaS on the side for a year. Here’s what the first year looked like for me.

Year 1: From beer money to rent money

On my Micro-SaaS journey, this was the full year of 2014. Monthly recurring revenue chugged slowly upward from $150 (beer money) to $2,180 (rent money… yes, in Brooklyn that is barely rent money after taxes). The funny thing is that is actually pretty healthy month over month growth. By all accounts not bad, but still, more than a year later, nowhere near enough to live on in the US.

During that time Storemapper was a side project for me. My main focus was a solar energy startup, which was immensely time-consuming. I wanted Storemapper to grow, but I categorically refused to let it become my primary focus. Except for a few minor crises, I capped my time allocation at 15-20 hours per month. That’s product development, marketing, and support. This is a kind of extreme test case as most folks will not build a Micro-SaaS while founding another startup and will have more like 15-20 hours per week to spare.

In my case the time constraint was mandatory. I was working insane hours already and literally did not have the spare time and energy to put more effort into Storemapper in the early days. But I think it’s a great idea to put a time constraint on yourself even if you have more time to spare. Setting a limit of something like 15 hours per week is beneficial for a number of reasons:

  • You have set a manageable path for yourself. Telling yourself “I’ll do whatever it takes to make this successful” is a recipe for burnout.
  • It’s not mutually exclusive with having a life, a family or a day job.
  • You will build a tighter, simpler product and customer acquisition funnel.
  • You won’t be tempted to over-fiddle. A big part of being successful through this stage is making changes and then doing nothing. Just waiting to see what happens and not overreacting to every single new customer, bug or feature request.
  • Parkinson’s Law: if you allocate 60 hours per week (or unlimited hours per week) to this you will spend 60 hours per week, but 50 of them are unlikely to be very productive.

Most of the first year of Storemapper I spent refining the customer onboarding process. That meant setting up a little automated onboarding tips, making screencasts and FAQ docs, fixing endless bugs with the CSV upload process. It was a lot of individual customer support requests, devising a few technical solutions for scaling problems, and shipping maybe three or four major features over the whole year. For customer acquisition, I primarily doubled down on the few channels that had brought in the initial customers: posting in e-commerce forums and looking through freelance job postings. Over the course of that year, I launched two quick growth hacks. The first was adding the “powered by Storemapper” link to the bottom of the store locator app (a must for any embeddable product) and the second was integrating with the Shopify app store, which allowed us to be listed in their app directory. That was basically it for a year of work.

The rest of this chapter will focus on the mental strategies I developed and learned from others for staying sane through a period of long, slow, SaaS grind.

How to keep growing while staying sane

This is the part where you can easily drive yourself crazy. Relative to the actual value of the nascent business you’re building you will still spend a disproportionate amount of time dealing with grumpy customers, manually onboarding people, frantically deploying mission critical code at the last possible moment. Here are a few ways to keep sane during this period.

1. Don’t compare the hourly rate

If you’re transitioning from freelancing or consulting where you charge a healthy hourly rate, a great way to drive yourself bonkers is to start adding up the hours you’re working on your Micro-SaaS business and divide by the revenue you actually get from that customer. Do that arithmetic right in the middle of a particularly frustrating customer that is taking 4-5 hours of your time, spread out across two weeks to finally subscribe to a $20/month plan. Early on that number will be hilariously smaller than your hourly rate. Don’t do this math. It’s a complete apples-to-oranges comparison. When you do one hour of freelance work, you get paid exactly that hourly rate and that’s it. The hour is gone forever and you just have that cash. By contrast in SaaS, every single frustrating minute with a problematic customer in yields a better understanding of the onboarding process, shaving time and headache from every subsequent customer for the rest of time. Every customer that you successfully onboard is another happy potential referrer of new business. SaaS is much more scalable than consulting and every new referrer can compound nearly infinitely. Tell yourself that, then go back and edit your 35th email to that customer and make it just a little bit more polite and friendly 🙂

2. Become a stoic, mentally walk thru disaster

One benefit of building and launching a product extremely fast is that you don’t have much sunk cost, time and energy already invested. If the app explodes and everybody angrily demands a refund, you really haven’t lost that much. Remind yourself of that when things become really tough.

Take a moment and visualize just walking away from it all. Visualize it in detail, what would you do? Write a pleasant email to all your customers, thanking them for their trust and suggesting some alternatives. Add up how many refunds you would have to issue. What services you would shut down and so on. Then look at that, compare it to your current stress levels and decide which one you want to do. Maybe it’s shutting it down, but more likely you’ll convince yourself that it’s still worth it. Then get back to work 🙂

3. Don’t spend a dime on marketing

The very tired cliche that “marketing is like sex, only losers pay for it” applies in Micro-SaaS. Everybody who writes about SaaS startups will talk about how you calculate your customer lifetime value (CLV) and how much it cost to acquire that customer (customer acquisition cost, CAC). As long as CLV is some nice multiple higher — say 3x — than CAC, you should spend, spend, spend!

And this makes total sense… if you’re sitting on a pile of VC money with no other mandate than to grow as fast possible. But Micro-SaaS doesn’t work like that. To build a defensible and profitable business with reliable, low-risk income you want a CAC of $0.00 per customer.

I’ll admit, I am strongly biased here by my own experience. I was reading those growth-hacker blogs and I did think in terms of CLV/CAC. The appeal is that once you find one acquisition channel with a great ratio, you can breathe a sigh of relief. Nothing to do now but re-invest profits or pile more money into that channel and you’re golden. I wasted a lot of time looking at Adwords, Facebook and Twitter ads. After giving up myself, I set out on a hunt to find a consultant or partner to help with it. I cold emailed the most well-connected marketing and SEO blogger I could think of asking for help. To my delight, they sent back a few introductions and shortly thereafter I struck a deal with one of them to do Adwords marketing. We set a steep growth target, but if they succeeded, they’d get a bit slice of equity and revenue from the business. Five months later Adwords barely moved the needle over organic search and we shut the whole thing down.

Maybe it was coincidence, but every time I tried a strategy that involved buying customers I’d waste a few hundred dollars and dozens of hours to get nowhere. Maybe you’ll find a paid marketing channel that works great, but my experience is that it’s not worth the time and frustration, particularly at this stage of the business.

4. Don’t build features until there is a revolt

While building Storemapper, I kept a detailed backlog of features to build. Both things that I thought would be a good idea and things that customers requested. It was — and still is — hundreds of tasks long. This is intimidating but ultimately a good thing. Resist the temptation to grab a 4-pack of Red Bulls and power through everything in the backlog. Every new feature you build adds an exponentially larger time commitment to supporting and explaining that feature to new customers. It’s much harder to remove a feature than to never have it.

Don’t build a feature until a very large number of potential customers refuse to sign up without it, or a large number of existing customers threaten to cancel without it. That’s the very high bar for actually writing code. If your customers aren’t outside your castle keep with pitchforks and torches over the lack of a feature, it’s not the time to build it yet.

5. Don’t Pre-build For Scale.

Your Micro-SaaS business is not Kim Kardashian’s naked backside and it likely won’t #BreakTheInternet.

If you’ve done the work right to this point. The business idea is solid and the MVP delivers real value. The speed at which you get new customers increases linearly with their patience for scaling problems.

What does that mean? Well, Storemapper had some small scaling issues here and there that I had to solve quickly and under pressure. Store locators went down a few times. Our geocoding back-end was overwhelmed when our customers went from having 100s of stores to 1,000s. But it was clear to customers that this was the solution they needed. I emailed them and was open and honest about what was happening and thanked them for their patience. Almost universally these customers stayed paying customers and actually often would write me little notes of encouragement.

Pitfalls of running a growing side business

In this last section of this chapter, I want to go through a couple of problematic areas of running a growing side business. These are tangents that can suck up a lot of time and energy along the way if not handled correctly. As a side-business starts growing the most important thing is to keep focused and executing on the core business. Running a growing side business, particularly if it is your first real side business, has a number of distractions. I handled almost every one of these badly, so I guess you can make it out alive but you may as well learn from my mistakes.

Accounting, Bookkeeping, and Legal

This one is worth dealing with as soon as your business starts to get at the “rent money” level. Accountants will advise you to setup a separate bank account and business entity for every project from the very beginning. This is probably extremely impractical, especially if you are using Lean principles and expect to launch several MVPs that are likely to fail. But once you get to a decent level of revenue and it looks like the business will be around for a while, you should definitely get a basic checking account and bookkeeping started.

It is going to be very helpful to at least have all the revenues and expenses in their own accounts, separated from your rent and burrito transactions, even if they are not technically business accounts. I would recommend getting a separate checking account and credit card that you only use for transactions on any and all MVP businesses. Once you start to see real traction you can create a simple business entity and open accounts in the business’s name. I made the mistake of going about two years mixing business with personal checking and credit card accounts and the resulting bookkeeping was a huge nightmare once I finally started to clean up my books.

I’m not at all credentialed to give real advice on this topic so do your own research and talk to an accountant.


I made the decision fairly early on to be transparent and open about my business. That meant a steady stream of inbound emails of people looking to partner with me. Everything from cross-selling, affiliate deals, content marketing services and consultants. When your product is young and fast-growing lots of people will propose integrations and synergies and all kinds of strategic relationships that sound vaguely appealing at first glance.

On the whole, these were a giant waste of time for me. Partnerships are messy. Ideas that initially sounded sensible turned into a quagmire once we started digging into the weeds, discussing how risk would be allocated, and discussing in advance what would happen if the relationship didn’t work out. Most of the time people actively reaching out about a partnership of some kind are looking for a quick win or looking to get someone to agree to a disproportionate amount of work without realizing it. I would advise moving those discussions to the bottom of the To Do list or straight to the trash.

Acquisition Offers

I wasted a lot of time discussing potential sales of Storemapper. Partly I brought it on myself. I learned a lot about staying sane during the long, slow, grind but there were times where I did a bad job of it. Running it along side a startup was difficult and I often thought about selling it to re-focus my time on the startup company I was actively working on. I wrote a short post on a forum soliciting offers and quickly got dozens of responses. This turned into a continual giant waste of time for the next 12 months. Fairly early in the process, I figured out it was not worth my time but I kept taking the conversations out of a curiosity to see what buyers thought and what kind of valuations they had in mind. Let my pain be your gain and save you a ton of time.

There are many people in the business of “buying websites” that made their money flipping ad-supported sites or simple e-commerce and drop-shipping businesses. Those businesses have historically been available for as little as 6-12x monthly profit, less than one year of the expected revenue in your pocket. SaaS businesses are much more valuable and a good estimate of value is closer to 3.5x yearly profit. Although it’s slowly changing, many buyers are anchored to the old valuations and even though they sound very confident they can get a deal done, it turns out on the fourth or fifth call that you are miles apart on pricing a deal. If you are going to engage with a potential buyer, firmly mention your target valuation multiple early on in the first discussion.

If you have traction and good solid growth there is a huge mismatch between how much you value the business and a buyer’s willingness to pay. You see growth in revenue every month and all the possibilities for new features, new markets, new customers. You view holding on to the business and growing it yourself as an extremely low-risk way to pocket more profits and grow the value of the business. Your buyer, on the other hand, sees and unproven business without a track record. There are two likely situations where you would actually sell a Micro-SaaS side business. The most likely is that something changes in your life situation where you just don’t have the extra time for it. You’ll take a hit on the valuation but a reasonably priced Micro-SaaS side business is a very sellable business with many potential acquirers. The second possibility is a so-called strategic acquisition. This is where a larger business buys you not just for the cashflows from your existing business but because you either compliment their products or compete with them. In these cases, pricing is more about willingness to pay rather than a multiple of profits and likely much more attractive. These seem to be exceptionally rare in Micro-SaaS and the only recent example I can find is Drip, an email marketing SaaS, getting acquired by LeadPages.

The bottom line is that it is extremely unlikely you’ll get an attractive enough acquisition offer during this phase of your business to make it worth the time suck of talking to buyers. Much better to spend the time on growing your business.

  1. Props to Josh Pigford for putting all this out in public as a lesson for others entrepreneurs. It is much appreciated.

Chapter 5: Getting Your First Customers

<< Back to Chapter 4: From Idea to Building a Minimum Viable Product

Getting your first customers can be really challenging. I’ve spoken to a lot of entrepreneurs who thought of and built a first version of a SaaS product that seemed like a great solution for a certain niche, but they just couldn’t get that initial traction with customers.

From my research I have found a few common strategies that have worked. Most fall into the category of things that don’t scale. Some require that you do many months of preparatory work before you build the app.

In Chapter 2 I point out that knowing how will you find your first 25 customers is part of finding a good business idea. If you truly have no idea, you probably shouldn’t build the product. However you may also find it makes sense to work backwards from a group of customers to a business idea.

For example you might find that roofing companies are extremely easy to find: they advertise their contact info in business directories and you could easily meet 10 roofers per day just by hanging out in the right section of a hardware store. Now you know that if you had a SaaS product for them, it would be very easy to find the first 25 customers and beyond.

Keep working from both directions to refine or reject ideas, both working backwards from target markets of customers and working to find customers for certain ideas that otherwise seem valid.

In my experience, successful Micro-SaaS businesses consistently use one of the following strategies for acquiring their first customers.

Become a consultant

Storemapper’s first five customers came from a single email blast. Over nine months of freelancing for e-commerce clients I kept a spreadsheet of every client email, even for gigs that I didn’t end up winning. On launch day I emailed the list of about 30-40 targeted people and within two days there were five paying customers.

Consulting for e-commerce businesses was a fantastic way to learn about exactly what kind of products they needed, their willingness to pay for solutions and where the pain points where strongest. The real upside that you are getting paid the whole time. If you find yourself getting hired repeatedly for a similar job, you may be able to just “refactor” that job into a SaaS app that can scale.

Consulting-first also necessarily forces you to focus on a lucrative target market. If the businesses aren’t hiring consultants or freelancers to solve problems, odds are they will be tough customers for SaaS.

Forums and IRL conferences

Consulting in e-commerce gave me a big advantage in generating business ideas but it didn’t prove that many actual customers.

The immediate next phase for Storemapper was to find places where e-commerce merchants were looking for answers to stuff. Most of the big e-commerce platforms like Shopify, Bigcommerce, Volusion and WooCommerce have forums. So I searched the forums and tried to be helpful. Of course I jumped to the few topics specifically around store locators, but I also looked for popular threads on topics with lots of activity from merchants just setting up a new site (or migrating from another platform) — prime timing to choose a store locator app — and just added helpful comments. I would let my forum “signature” with a link to Storemapper do the marketing.

The generalized tactic is to find where your target market clusters and be there. This could be online in forums or the comments sections of an industry blog or in real life at meetups or conferences.

Aggregator sites and blogs

Hopefully your target market congregates somewhere online. If it’s software for developers, then you’re looking at Hackers News, Product Hunt and Reddit. Maybe there are niche blogs that cover the topic. Become a member, be helpful and without spamming folks, politely point them towards your app when it’s a relevant solution. If you’re knowledgeable on the broader topic, it can be helpful to invest some time answering questions not directly tied to your app to build credibility and not come off as a spammer.

Several successful Micro-SaaS businesses have been started by “blowing up” on certain popular sites. But it wasn’t just pure luck that they hit number one on hackernews or reddit. They had often spent years being helpful and cultivating the respect of the community that then responded when they finally launched a product.

Business directories (or hit the streets)

It will be easier to find customers in certain B2B markets than others. If you sell to plumbers, real estate agents, or attorneys you can just search any online business directory and put together a huge list of leads. Look through Yelp, Craigslist and Google local listings for local businesses. Give them a call and ask if that have any pain points in their business and politely introduce your software product.

A variation of this is if you can find your customer type by just walking around. Build an app for ice cream parlors, bodegas or drug stores and you can find customers by just strolling around your city and chatting with the owner. Bring a laptop, sign them up for a free trail and walk them through the setup process on the spot.

If your target customer business doesn’t have a storefront, a little bit of research will still almost always turn up a directory website.

Steal business from jobs boards and freelancer sites

If your Micro-SaaS replaces a job that your customers would typically hire a freelancer or consultant for — great fodder for business ideas — then jobs boards can be a fantastic place to find new customers. Setup a regular process to search for job postings on every site you can find and tell job posters they can “hire” your app instead.

I knew several of my freelance clients had been interested in hiring me to build a store locator so I figured that was probably happening elsewhere. I had previously used just one or two sites like oDesk and Elance (both of which are now, but now I created accounts on every one I could find. I would trawl the sites for jobs that included a store locator in the requirements, “apply” for the job and pitch them on using Storemapper instead.

While I was freelancing I discovered that two of the major programming freelance sites let you create an RSS feed for new jobs that matched certain search terms. So I made a feed for any new jobs that contained “store locator” and used IFTTT to trigger an email to me with the link. I’d quickly confirm it made sense, then paste in a standard pitch to the effect of “I don’t want to do this job but you should use my app for this part of the gig” totaling about 30 seconds are work with a pretty high success rate of getting new customers.

Ride the wave

Sometimes you can get bigger platforms to bring your first customers to you. In Chapter 3, I mentioned that a good way to find good Micro-SaaS ideas is to look at fast growing platforms and find an unmet need. You want the need to be large enough that a decent percentage of the platform’s users want it, but not so large that the platform itself is likely to build the solution themselves. If you hit that sweet spot, you may find that the people behind the platform will refer customers to you.

Justin Jackson calls this catching the big wave. Catching the big wave is all about timing. When I launched Storemapper in the Shopify app store, it was the only store locator solution. So we’d get all the app store searches, all the recommendations from customer support and all the discussion forum searches. Shopify was really blowing up at that time and we caught the big wave. These days the Shopify app store is quite saturated and even has quite a few copy-cat store locator apps. The big wave is likely over for Shopify. Since I’d like this chapter to stay relevant for more than a few months I won’t make a suggestion for where the big wave is right now, but it is a strategy worth remembering. If you initially built your SaaS as a standalone, rather than directly integrated to a platform, it may be worth some development time to build an integration with a growing platform if you think it will help you ride the wave.

The Parallel Track: Build the audience

The best and hardest method of acquiring your first customers is to carefully cultivate an audience over time, gain their trust, learn their pain points and build product for them. When you deconstruct a successful Micro-SaaS business you often find that they got their first customers through this kind of path. The downside to this approach is fairly obvious, it takes a lot of time and energy to produce content, interact with and cultivate an audience. You have to invest all that time before launching the product and learning if people will really pay for it. The upside is that if the product is good, getting your first customers will be smooth sailing.

Essentially this is a parallel track running through all of the previous chapters on finding a good business idea, building the first product and acquiring your first customers. You can build an audience on a reasonably broad topic, find out from that community what kind of product they need, build and launch it to that audience. In this track you can spend considerably more time on the first version of the product and you can also be a little less niche since you already have a good batch of initial customers.

Most of the tactics and criteria I have laid out can be relatively mixed and matched. But this strategy can’t really be remixed. The type of business, the target market, the way you validate it and they way you build and launch it all need to be dialed in for it to work (or to be worth the time and effort).

Also, this whole workflow does not work for a large number of businesses that might otherwise be good Micro-SaaS. Nobody would have read a blog about store locators. Building an audience around the idea of making e-commerce apps would not have brought the right audience: my actual potential customers are e-commerce shop owners, not developers.

I actually don’t recommend this approach for first-time Micro-SaaS entrepreneurs. Even though it is one of the more successful ways to launch and get your first customers, if the product fails you’ve invested far more time and energy to get to this point. It’s also much more difficult to ditch a business if you have an audience following your every move. It seems to take most entrepreneurs several attempts to find a Micro-SaaS business that really works so I would recommend targeting a niche, building a quick MVP and using one of the above strategies to find your first customers.

How NOT to get your first customers

There are a number of well-known customer acquisition channels that I think are particularly bad for early stage Micro-SaaS businesses. Here are the general things you want to avoid.

Any cost per acquisition: VC-funded SaaS companies are almost always cashflow negative. The wonderful magic of big, funded SaaS is that you can spend $100 to bring on a customer who pays $20 per month, and as long as you know that customer will stay around for a year or so, you are generating value for the company. But this cashflow formula means the more customers you add and the faster you add them, the more money you lose each month. This situation can be lethal to a bootstrapped business. Unless you have easy access to capital at generous terms and/or are very experienced with paid acquisition I would avoid any channel that has a discrete cost per acquired customer.

Compete with funded startups: I would avoid entirely almost any channel that involves bidding against or any degree of competition with funded startups. This is just not a fight you can win as a bootstrapper.

Heavy time investment: At the beginning of this chapter I argued for doing things that don’t scale. You shouldn’t be too stingy with your time in the early stages of acquiring customers. I strongly advocate channels where you can invest a little bit of time, get a new customer, and repeat. However I really recommend avoiding channels that have a big investment of time up front to get up and running. Do not underestimate the amount of upfront time it takes to negotiate an affiliate deal or set up a retargeting campaign. These kinds of things can turn into huge de-motivating black holes of time that end up distracting you from your real goals.

Un-vetted signups: In general you should be able to confirm that the type of customers coming in through a channel are in fact a good sample of people who should be interested in your product. This is why certain forums and directories are great sources. Channels that bring in a random slice of people on the internet should be avoided. You don’t want to flood your app (and support queue) with unqualified customers who are just poking around who will waste your time and then not sign up for a paid plan.

Some specific comments on a few common channels to avoid:

Adwords, Facebook ads, etc

For all the reasons above this is probably the worst possible way to get your first customers. It costs per customer. You are competing directly with every single company in the space, most of which probably have much larger budgets than you and vastly more experience bidding. There is also a pretty substantial overhead cost of time or money to get even a half-decent campaign up and running.

SEO tricks

I am not a big fan of SEO as a customer acquisition strategy. Partly this is because I just don’t fully understand it and I don’t feel like my bullshit radar is very well calibrated when dealing with SEO tips, tricks and consultants. If you are already an experience SEO ninja, great, ignore me. If you would be reliant on how-to articles or consultants to boost your SEO ranking I really advise against it as a way to get your first customers. First it’s a black box and an extremely vulnerable position if Google changes their algorithm. Second, it’s just so passive that you have no idea what kind of traffic you are driving to your site. You may boost your ranking for certain search terms but you really don’t have any idea who the people are that are searching and clicking to your site. I much rather cold call people I know are potential customers than sit there and try to divine whether or not this traffic is at all relevant to my product from Google Analytics.

Affiliate deals and partnerships

These can really seem like a great deal at first pass but I would strongly encourage you to avoid them. First, don’t fall for the survivorship bias. You may hear from a fellow entrepreneur about the amazingly successful AppSumo deal they ran last month. But nobody (except I guess me) is going to shout from the rooftops about all the affiliate deals they spent dozens of hours emailing, calling, negotiating that turned out to be a total waste of time. On top of the massive time overhead to set most of these things in motion, they are not repeatable and can also flood you with support requests.

Further Reading

If you’re looking for more tactics for acquiring customers, Gabriel Weinberg, the founder of Duck Duck Go, has put together an epic manual in Traction. Keep in mind that the book is aimed a little more at the funded startup scene, but there is a mountain of actionable advice in there.

Adii Pienaar, one of the founders of WooThemes and now Receiptful, has a great ebook and podcast aptly named Your First Customers, also a great resource.

Next Chapter 6: Thriving in the Long, Slow, Grind >>

Chapter 4: From Idea to Minimum Viable Product

<< Back to Chapter 3: Finding Micro-SaaS Business Ideas

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.

You've already subscribed (thanks!) so go ahead and download them here.

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.

More specifically:

  • 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 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:

  1. Don’t build it.
  2. Really, just don’t build it.
  3. Okay, fine, look for some existing service that can get you a good enough version of it.
  4. Really, there’s nothing? Go look again?
  5. 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 ( and point to a WordPress site with your landing pages and your blog at Then have your actual application hosted at 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.

Next Chapter 5: Getting Your First Customers >>

Chapter 3: Finding Micro-SaaS Business Ideas

<< Back to Chapter 2: What Makes a Good Micro-SaaS Idea?

As I mentioned before, the most important part of ending up with a good Micro-SaaS idea is throwing out a lot of them. But there are a few good ways to prime the pump and look for new ideas. Here are a few methodologies that I’ve developed or generalized from other Micro-SaaS entrepreneurs.

Micro-SaaS Idea Generation Mini-Course

Get 5 days of exercises in your inbox to help you come up with your own profitable Micro-SaaS business idea. Even if you've already subscribed to the newsletter drop your email in here to start the course.

Powered by ConvertKit

Scratch your own itch

Eat your own dog food as they say. This is the classic example of how to build a product company and it does work. The most commonly cited example is of course 37signals, a design firm that built a project management tool, Basecamp, for their own internal needs. They realized other firms might need a similar tool and started selling it as SaaS. The software business quickly eclipsed the design business and now they can hardly be called “Micro” with millions of customers. Here is the origin story.

Another great example is Josh Pigford, the founder of Baremetrics. Josh was running another Micro-SaaS business and was struggling to get some basic financial metrics like Monthly Recurring Revenue out of his payment processor.he hacked together a minimal product that anybody, but first and foremost his own business, could use to instantly get SaaS metrics from their payment processor. Realizing lots of other business owners would have a similar problem, he opened it up as a product and shot up to $8,000/month in six months.

This is a well tested strategy but it has two big problems at this point in time. First the idea of scratching your own itch has been around and popular for a while and second the type of people who build software businesses tend to be somewhat similar in their needs. There are only so many itches to scratch for a software entrepreneur and at this point a lot of them have been sufficiently scratched. Slightly paradoxically, this is in fact part of the reason why now is such a good time to build a Micro-SaaS business. Scratch your own itch has been around so long, that for almost everything someone trying to build a software business needs, there are 15 other software businesses selling pretty great solutions for it. Once you hit on an original idea, you can often use those other itch-scratchers’ off the shelf solutions rather than having to build your own internal tools.

Pieter Levels, the creator of Nomad List, has a good solution to the over-saturation of scratch your own itch. In his book MAKE he suggests that if you live an interesting or unique life, you will generate new and unique itches to scratch. In his case he was living a digital nomad lifestyle, traveling around the world in a backpack while building a new startup every month. He needed to figure out the next best place to live each month comparing data like cost of living and internet speed for cities all over the world. So he scratched his own itch, crowd-sourcing a basic dataset and built a site to help other digital nomads connect and solve the problem.

If something about your life is really unique, then you can use scratch your own itch in that area. If you are a freelance graphic designer in San Francisco who likes yoga and green juice, you’re going to need a different strategy.

Niche versions of existing SaaS

A lot of big funded SaaS startups have built generalized software that many different types of businesses are using for their own specific needs. These SaaS businesses have to target a wide audience because of the shear volume of sales their company size and valuations require. Looking at generalized products like Salesforce, Quickbooks, Basecamp, Freshbooks, Shopify and WordPress can be a good source of ideas for niche SaaS products.

A great example is Mindbody, which is custom SaaS for yoga studios. Everything about the app is customized specifically for this niche: online class schedules, tracking teachers, accepting payments and subscriptions. A yoga studio could probably cobble together all of those features from a few existing big SaaS products but when there is a single product that works for them out of the box it easily clears the 5x better hurdle. And I think you would be surprised at how low the bar is here. Even something as simple a building a simple CRM with data fields and workflows pre-built for a particular industry could be enough of a UX improvement to sell well.

Haven’t seen any great examples yet for this, but I think there is a big opportunity in just building a simple CRM for specific industries. Even if it’s less powerful that Salesforce, a simple contact and pipeline tool with workflows and a data model (even just having the right words and terminology built in) could sell well enough to be a healthy Micro-SaaS. Salesforce for wedding photographers. Freshbooks for dentists. Play around with combinations until something passes the Meat Grinder.

Repeatable freelance and consulting work

SaaS, and software more generally, has been stealing work from freelancers since the beginning. Nobody wants to be in the business of reinventing wheels, so if you see a specific type of job that businesses are paying contractors to do over and over again from scratch, there may be an opportunity to build a SaaS solution. This was the method that generated the idea for Storemapper. There was no good plug-and-play solution for a store locator app on the market and several of my own clients asked me to build them one. I could have made something from scratch and sent them a bill for $1,000 – $2,000 each but it was a broad enough need to warrant investigation as a Micro-SaaS. Another thing to look for is a big change in complexity. I did some research into other store locators and found that companies with a store locator would have a relatively simple site, something easily built without a developer on Squarespace, WordPress or Shopify, but the store locator would be a big step change in complexity. So I reasoned that you might have a lot of customers who could launch their entire site without a developer, except for the store locator. Great opportunity.

The best way to sniff out these kinds of opportunities is to actually become a consultant in a particular field and really learn what customers need.

Automate manual tasks

Sometimes you can use the sections from Chapter 2 on what makes a great Micro-SaaS idea, to generate new ideas. One of the best attributes of a Micro-SaaS business is automation. So you can start from there and look around for things that could be automated, and then test to see if they would be good overall businesses.

A great example is Stunning  which is an app that handles dunning, an odd term for the painful process of following up with customers whose credit card on file has expired and getting them to update it. Without Stunning you are forced manually check this each customer, setup an alert if their regular monthly payment fails, and hound them until they update their payment info. With Storemapper I did this by hand for the first year. It was awful and I was not very good at keeping up with it until one day I realized fully 20% of my “paying” customers were not actually paying me due to some kind of billing issue. Stunning plugs directly into Stripe and automatically starts sending follow-up emails and in-app messages to customers until they update their account. It’s a great business model.

Build upon growing platforms

Like automating manual tasks, this source of ideas works hand in hand with what makes a good business model. A majority of the successful Micro-SaaS businesses I have encountered are plugged in to or enhance a rapidly growing platform. Baremetrics and Stunning built on Stripe a massively popular new payment processor. Mailparser, a Micro-SaaS for parsing data out of emails, got many of its early clients through Zapier a growing business automation tool.

We’ll discuss this platform strategy in more detail in a following chapter on acquiring customers but again you can work backwards for a source of ideas. Keep a look out for rapidly growing platforms, check their forums and Twitter mentions to see if there is one big feature or use case that many users are clamoring for but the company doesn’t seem likely to build themselves.

The best version of this is a platform bolt-on that can use that integration as a beachhead, but isn’t too tightly interwoven with that one platform. If you can also add value as a standalone product and integrate with other competing platforms, you have an even better idea.

Next Chapter 4: From Idea to Minimum Viable Product >>