Make It Rain: Building an MVP for Fun and Profit (Part 3 of the Epic Guide to Bootstrapping)

(Oh yeah — minus most of that whole “fun” part.)

I know you’re probably just itching to write some code at this point, especially after I’ve been pounding on you to avoid your IDE like it has a raging outbreak of herpes in the first two parts of The Epic Guide to Bootstrapping a SaaS Startup from Scratch — By Yourself (Part 1 is here and Part 2 is here if you’re just running into this series for the first time.)

But I did that for a reason.

I want you to understand first hand that building a SaaS startup is mostly a marketing optimization problem — not something that you can just code your way out of.

And the only way you can possibly learn that is to stop coding and to experience it for yourself.

So before we begin, just so there is no ambiguity, and so you understand exactly where I’m coming from, I’m going to reiterate my maxim one more time:

Code is the least important thing about a SaaS business.

Because:

A business’s software serves one purpose and one purpose only: To make the business money.

Ready?

Nobody knows what an MVP is.

Unless you’ve been living under a rock for the past few years, you’re probably familiar with the term MVP (Minimum Viable Product).

In case you haven’t, The Lean Startup (which is where it comes from) defines it as the “version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort”.

Now, like all things that are beautiful in their simplicity, the concept of MVP has been distorted, bastardized, and stretched on a rack to such a point that it’s no longer discernible in practice when compared with its original intended purpose.

Don’t believe me?

Would you say that a landing page is a type of MVP? How about a marketing page that looks like a real product but is just a “test” to see if people would pay for such a service? Or how about a “SaaS” that’s really just a bunch of interns plugging data into spreadsheets behind the scenes and emailing them as reports?

So, it’s really not inaccurate to say that nobody knows what an MVP is anymore.

But for our purposes, we can say what an MVP is.

Since we are trying to build a SaaS startup that can make money, for us, an MVP is (adjusting the original definition):

The version of a SaaS application that actually generates an agreed-upon amount of revenue from paying customers with the least amount of effort and features possible.

It’s that simple.

But at the same time it’s really not.

A Quick Update

Since its original publication, The Epic Guide has become an *insanely* popular resource for bootstrapped startups — on the verge of becoming a “cult classic”!

I’ve had an insane number of people asking me for even more down and to the point advice for building their startups — so much so that it’s inspired me to give The Epic Guide the full-length book treatment.

If you’re interested in learning more about the book or if you’re itching to pick up a copy, head on over to this page I’ve set up for The Epic Guide to Bootstrapping a Startup By Yourself: The Book!

Now back to our regularly scheduled programming:

It’s about the market, stupid!

If you remember from Part 1 and Part 2, you need to have a market. No market, no money.

All of those wild goose chases I sent you on (as amusing as I’m sure they were to you) were so that you would find your target market.

So we aren’t going to be going after just any “paying customers” — no, no no.

We’re going to be going after our target market that we spent all this time discovering.

Why is it so important that I spell this out to you? After all, aren’t target market and paying customer synonymous?

The reason is because of this little bitch of a thing called product/market fit. If you ever want to be able to reach it, you better start aiming for it now.

What you build for your MVP is entirely dependent on the market you are targeting. Not just some random paying customers — but an honest to goodness, tangible, identifiable, demographically describable TARGET MARKET.

Think about it: You may have identified TWO potential target markets to date! You may have to build a completely different set of features for Target Market A vs. Target Market B. But we’re only going to build for ONE of those target markets! So which features do you go after? The ones that the target market you’re going after cares about most!

Just in case I’m not clear enough: TARGET MARKET IS EVERYTHING.

So, adjusting for target market, our definition of a SaaS bootstrapper’s MVP becomes:

The version of a SaaS application that actually generates an agreed-upon amount of revenue from a specified and specific target market with the least amount of effort and features possible.

So you’re probably asking — why “an agreed-upon amount of revenue”? And how much is that agreed-upon amount of revenue?

It’s important that you have a “no-bullshit” metric that keeps you honest and accountable.

And since we’re trying to make actual money with our software, our no-BS metric should be around revenue.

Pretty simple, no?

So how much?

Shoot for something like $1,000/mo for starters.

You’re probably like “What the fuck man! I can’t live off $1,000/mo!” I know that. No one can. That’s not the point.

The point is that getting that first $1,000/mo is going to be way the fuck harder than you can possibly imagine at this very moment.

If you set your goal to something ridiculous like $25K/mo, you’re going to find out real quick just how far from that goal you are. Not only that, but once you see just how hard it is to add even $100/mo to your bottom line, you’ll get depressed, give up, and we’ll all be trying to pull you out of bed from underneath your tear-soaked blankets within a month. For reals.

And no — WE ARE NOT GIVING OUR STUFF AWAY FOR FREE.

Man up and learn how to charge people money for your application or go back to your cubicle cell.

Just so we’re clear: At this point in time — No freemium. No exceptions.

Do you still have a problem with charging money for your software?

Look at it this way: People pay money for things of value. If you have something of value, people will want to pay you money for it. If you don’t think people will pay you money for it, that’s probably because it doesn’t actually provide any sort of tangible value to people. Give up if that’s the case.

In all seriousness, you need to come to terms with charging money and you need to figure out how much value people actually feel they get from your offering. The alternative is to rot away at your cube until you’re a grey-haired neckbeard. I hate to be the one to break it to you, but you’re not going to be 25 forever. Your window of opportunity to create the kind of life you want for yourself is shrinking just a little bit more every day you wake up. It’s your move.

You’re gonna get it wrong.

Before we get too far, I need you to do something for me.

I need you to accept this one axiom of truth: You’re gonna get it wrong.

I mean it. (Meaning, of course I’m right about this, and I really do need you to accept it.)

Your first attempt at building anything — MVP or not — is going to be wrong. It’s not going to get you to your goal of $1K/mo. So you might as well just accept that fact now rather than waste good and valuable time deluding yourself otherwise.

You’ll see why this is so important going forward here.

So what exactly should you build?

The thing you’re most certain will get you to this (even though you’ll be wrong):

The version of a SaaS application that actually generates $1,000/mo of revenue from a specified and specific target market with the least amount of effort and features possible.

Think of building your SaaS app like a game of chess.

You want to win the game with the least number of moves possible, but you have to think about how each of your moves potentially affects the overall game (and your chances of winning). As in chess, you’re not going to be able to win the game in one move. And despite your best strategies, it may take many more moves to win the game than you would probably like.

Knowing all of this, you most certainly should not spend a ridiculous amount of time on the first version of your application. Your goal is to release each iteration (analogous to a move in a chess game) in such a way that it has the most possible impact at this stage in the game and which takes the least amount of time to execute.

I typically recommend that you take no more than one month to build AND release the first version of your SaaS application.

Do not make the mistake of coding something for five to six months, putting it out there, and then finding out that no one will give you money for it. Trust me on this. I’ve done it. It’s a very sad thing. I regret it. You will regret it.

Now, if you’ve been playing along at home and have actually worked through the recommendations I laid out in Part 1 and Part 2 of The Epic Guide, you’ll have done some direct outreach as well as have built a launch list around one (and only one) benefit that targets a specific market. Hopefully you’ve gotten your “Heck Yeses” and the signup numbers I’ve directed you to get.

If you haven’t gotten those “Heck Yeses” or signups, you need to go back to Part 1 and start over. I mean it. If you can’t get people to give you a “Heck Yes” or give you an email address for your launch list, you will most certainly not get anyone to actually give you money for your SaaS application. Think about it: Are you more likely to give out your email address or your credit card number to a total stranger? This isn’t rocket surgery. If you can’t get emails, you’re not going to get credit card numbers.

So what you need to do next is to identify the smallest set of features that can satisfy that one benefit.

I know when you set out on this SaaS journey that you probably had grand dreams of how impressively comprehensive your app was going to be, how it was going to solve every problem under the sun and have just the coolest of the coolest features.

I’m sorry, but we’re not doing that.

That’s not to say that our app isn’t going to be cool, but if you cannot directly tie a feature you’re building as being absolutely critical in satisfying the delivery of your one benefit, you are coding for coding’s sake and wasting your time.

This is a very important point for a number of reasons, but I’ll give you just one.

As a solo bootstrapper, you have to do it all — development, testing, marketing, sales, support, etc.

And you can’t do more than one thing at a time.

So every single day that you spend writing code is a day that you are probably taking away from marketing and sales — which are the lifeblood of your business. Until you have a steady stream of revenue (and even when you do), you need to be pounding the pavement promoting your application.

Your cycle is going to look like this most likely:

Market and sell → Develop → Market and sell

Notice how we market and sell first? And then we market and sell again?

Marketing and selling are going to be about 80% of your time and effort if you’re serious about this. That means that you do not want to be spending more time doing development than you absolutely have to.

If you spend all of your time building features for your product, you will not make any money off of your SaaS app. Period.

So what we’re looking to do right now with version 0.1 BETA, is to figure out what the smallest set of features is we can build in under a month of development time.

We’re going to switch gears from marketing and sales to development — but only for a month — and at the end of that month, we better have something that we can market and sell with the realistic expectation that it will make us some money (even though it probably won’t).

Any piece of software is a continual work in progress. It is never done. You can always change it or add to it. The SaaS apps that you know and love today did not start out looking like they do today. The people who own them have been working on them continually, adding features to attract more customers and to expand into other markets. You cannot build everything on day one. Nor should you try.

For example, I built and launched the first version of Tamboo in three weeks. What it let you do was watch in a video playback what someone did on a particular webpage of yours. That’s it.

Since then, I’ve had to completely revamp the method I used for the video playback (first attempt was almost right but still wrong), added the ability to watch what a particular visitor did across multiple webpages, created a WordPress plugin, added all sorts of useful analytics, and am now working on adding interactive heatmaps that show you (aside from the standard “people clicked here”) where people spend the most time on your webpage, which part of the webpage people are on when they leave that webpage, as well as a number of other useful pieces of information. After this, I have even bigger plans and even more audacious goals.

But each of these features were built and released in under a month.

In whole, they represent months worth of development effort.

But here’s the kicker: I didn’t wait to build all of this out and then release Tamboo, even though there are other SaaS companies that may have more features. I marketed and sold a specific benefit (“Watch how people use your website”), built something that satisfied that benefit (video playback of people using your website), released it, and then marketed and sold it. All within a month. And then I went and did that whole process over again (and again, and again).

Because of this, I’ve not only been able to get people using Tamboo, but I’ve also gotten feedback on what’s important to people, which has helped me determine what I should be working on next.

You don’t get any of this if you sit on your SaaS app and never release it.

Like I said before, I’ve built other SaaS apps that went nowhere. I’ve made plenty of mistakes, but they were never around building a product that functioned. Instead, they were all around marketing, sales, and getting people to use the app. So it’s vital that you treat those activities as the most important activities in your SaaS business. Otherwise, you’ll have an awesome functioning product that nobody really wants to pay for. And you’ll have wasted precious months (or even years) of your life on what can only be described as “a fun exercise in futility”.

Before we jump in and start writing code, there are a few more guidelines we need to cover about what you should and should not build when it comes to your MVP.

Some of this may seem counterintuitive to you, especially if you’re coming from a professional software development perspective. But bear with me, it’s important.

I don’t have any useful data to base this claim on, but I would assume that most SaaSes that never get out the gate are built by (albeit very good) enterprise software development professionals. Their perfectionism and trained habits in achieving 100% completeness prevent them from ever getting anything out the gate.

I used to be one of those guys. Coming from a background as an architect at a Fortune 500, it’s only natural to think of how to build for all of those “ilities” (resiliency, reliability, maintainability, scalability, etc.)

Don’t fall into this trap like I did. You’re building a startup. It’s supposed to be messy at first. This is not the enterprise. Nothing is robust. Nothing is reliable. Nothing is predictable. Don’t try to make it that way until you absolutely have to. You don’t have the time. You don’t have the resources. And you’ll fail.

So. Here’s what you need to know.

First off, you need to have a way for people to sign up and pay for your SaaS application.

That does not mean that you need to have a robust authentication and authorization system complete with self-service capabilities.

What it does mean is:

1. You need to have a way for people to sign up for and log in to your service.
2. You need to have a way to make sure that user information is reasonably secure (at the very least, you need to salt and hash passwords, people).
3. You need to be able to take a credit card number and charge them on a monthly basis for your service.
4. You need to have a way for them to communicate with you for support and for customer service needs.

That’s it.

What that means is that — out the gate — you do not need any of the following:

1. SSO/SAML/OAuth/OAuth2/JWT/social sign on/whatever complicated crazy auth scheme the cool kids are trying to use nowadays.
2. Password reset functionality.
3. Self-service profile management.
4. The ability to cancel service through self-service.
5. The ability to change a plan or tier through self-service.
6. The ability to support multiple user accounts for an account (unless it’s absolutely necessary for the domain you’re dealing with).
7. Any kind of automated billing accounting (more on this in a few).
8. Automated emails that trigger during signup, billing, or any other events for that matter.

I know, I know. Things are burning. Babies are crying. Such is the way of sacrelige.

But here’s the thing. Building out SaaS application infrastructure (account management, billing management, etc.) is a time-intensive endeavor. It’s going to take more time than you are willing to admit.

If you accepted my claim that you’re going to get it wrong, why would you build out these features? Those are features you would only build out if you knew without a doubt that you were going to succeed and that people would actually use them. As it stands today, you have no customers, and so you have no users. And so you have no one to use your awesome self-service account and billing management functionality. So you’re building code for people to manage their non-existent accounts. Not the best use of your time.

Rather, you need to focus all of your development efforts on the things that will get people to sign up for your app, get them to use it, and get them to pay for it. In that order. Anything else at this stage is roughly the same thing as premature optimization. Don’t waste time building features for events that haven’t happened yet and (at this point) have no proof for ever actually occurring.

“But what if someone’s credit card gets declined after the first month?!”

“But how am I going to know how to keep my user account profiles in sync with my payment processor?!”

“But how are people going to change their account plan?!”

“But how are people going to change their email address or their password?!”

“But what if they forget their password?!”

“But how are they going to get their welcome email?!”

“But! But! But!”

It’s rather simple, actually.

You do things manually. They send you emails when they need something.

Call it “white glove service” or “concierge support” if you want to gussy it up.

But bottom line is — until you are crushed by the burden of support or people are screaming about not having those features — you’re going to do shit by hand. Or wait until the last responsible moment to actually build something you need.

Let’s work through an example here.

You need to collect and charge credit card numbers for monthly service for your SaaS application. You’ve chosen Stripe as your payment processor to avoid nasty PCI compliance stuff (good choice). You have a 21 day free trial. You don’t require a credit card up front.

Question 1: Do you build a Stripe integration into your MVP?

Question 2: What aspects of a Stripe integration do you build into your MVP?

Answer: You build nothing having to do with payment processing.

WHAT?!

Yep, nothing.

You build out the signup form, the smallest feature set you can build in a month that satisfies your one benefit, and that’s it.

Only after you have your first customer that looks like they’re actually going to convert to paid (meaning, they’re on let’s say day 14 of your 21 day trial and still actively using the app and are saying good things whenever you email them) do you actually go off and build out a Stripe integration.

And even then, you only build the piece that actually creates the subscription.

All of those other billing lifecycle webhooks that tell you if the charge was successful for a given month or not stay on the back burner until — you guessed it — your first paying customer is close enough to actually having their second month of service renew.

This may seem more than moderately irresponsible if you have a professional software development background. But it’s actually the exact opposite. It’s the most responsible thing you can do.

Let’s follow the logic:

Your time must be the most valuable thing to you.

You don’t know if this thing you’re building is actually going to get any signups, let alone anyone willing to give you money for it.

You don’t waste time building features that don’t matter until a certain event occurs, for example a customer going through trial to paid.

Therefore, you actively avoid wasting your time building features that people may never actually need. If this thing tanks or requires more refinement, you didn’t waste time building things that had a zero effect on that. You only spent time on the things that were absolutely necessary to get to the next level of the game. You don’t worry about Super Mario Brothers Level 8 when you’re still banging away at Level 1.

Doesn’t this mean that you’re going to be embarrased or ashamed of your app and not want to promote it? You bet. But you embrace this embarrassment, this shame. You understand that people’s opinions are just that — opinions. You understand that you are protecting yourself and your most valuable asset — your time. And once you realize that they still get what they need from you even in absence of those features, you hug onto that fear and you let it rip.

But aren’t people going to ostracize you for skimping on those things?!

Only if they realize that those things aren’t in place when they need them.

And even then — you can’t get negative reviews for an app until you actually have people using it.

And let me tell you, getting people to use it is not going to be as easy as you think.

So trust me.

Protect your time. Protect your energy. Put on your flame retardant suit. Because even if you do everything “right” — having self-service account management, integrated billing, etc. — people are still going to flame your app for one thing or another.

Learn how to make none of this faze you.

Learn how to wait until there is enough evidence to tell you that you actually need to worry about something.

And only then do something about it.

Let’s get building.

I’m sure at this point you’re probably aware that I’m going to lambast your instincts about what you should be doing when it comes to this whole SaaS-building thing.

Unlike your other instincts, your instincts about me lambasting you are in fact correct.

So let’s get a few things out of the way with respect to actually going about and writing the code for your SaaS MVP.

Let’s talk about technology choices first.

I know you’re probably so PUMPED to finally build your startup and use that awesome new framework/programming language/cloud platform/architecture.

Sorry, but that’s how losers play the game.

Winners use 1) what they know and 2) what they know will be a good fit.

Winners know that it isn’t the technology that makes the company — it’s the business that makes the company.

Repeat after me: I will not use anything that I am not already an expert in when it comes to technology selection or approach.

Why? Because we’re doing a startup to make money, not to learn a fancy new technology. Because we’re smart enough to recognize that the risk involved in learning how to successfully execute a completely unknown programming language/operating system/platform/paradigm is SO HIGH that it will potentially torch our ability to make money. Because we accept that what we’re already getting paid to do professionally should be enough to apply so that we can pay ourselves outright.

Use Java/.NET/PHP/Rails/Perl/VB in your day job? Then Java/.NET/PHP/Rails/Perl/VB it is.

I don’t care if you don’t know ASP.NET MVC and only know WebForms. Just use WebForms. Does that suck? Yes, it does. But do it anyways.

Learn something else once you’re making money and you can afford to pay yourself the time to learn something else.

I once spent three months learning production-grade Scala for a project I thought it would be awesome for. That project never got off the ground, and now I make $0.00 a year from having learned Scala. So I spent three months learning something with absolutely no ROI to show for it. Pure idiocy. Luckily, I’ve learned how to stop doing stupid. Can you?

Stop chasing shiny red balls. Dogs chase shiny red balls because they don’t have the mental faculty to choose otherwise. Are you a fucking dog?

Use what you know.

You’ve spent how long becoming an expert— use it.

You’ll spend less time building out your MVP so you can spend more time marketing and selling and making money — use it.

You’ll know what to do when things go wrong (which they will) — use it.

Everything new you learn at your job you can transfer for use at your startup — use it.

Just. Fucking. Use it.

“But that’s boring.”

Yeah.

But you know what’s not boring?

Making money.

So shut up and use it.

There are entire startups built off of Perl and Bash scripts making more than you do toiling away writing useless code for an inept company at your hopeless, grey, cubicle farm.

Take a lesson. Use whatever you know.

The same thing goes for architectural concerns.

Microservices? STOP.

Crazy ass front-end stuff with ReactJS or Angular2 with TypeScript? STOP.

How about some hot new NoSQL platform? STOP.

What about going cloud with AWS or Heroku? STOP.

STOP.

STOP.

STOP.

This is not an opportunity to learn new technology. This is an opportunity to make more money off of your existing technical skills. WHY ELSE WOULD YOU DO THIS?!

JUST. FUCKING. STOP.

In all honesty, you’re going to be spending a lot of time coming up here having to learn about marketing and sales and business in general, so the less you need to know from a technical perspective, the better.

Don’t believe me on the importance of this?

Who do you think gets the fattest salary, the fattest bonuses at your company? Here’s a hint: It’s not the IT staff, it’s not the IT directors, it’s not the CIO. It’s the VPs of marketing, the VPs of sales. BECAUSE THEY BRING HOME THE BACON.

This is not an exercise in technology. You’ve been warned.

So what else should you know?

Don’t waste time writing unit tests. You should only write unit tests for codebases with a long-term lifespan. Your startup has not proven to you that it is worthy of unit tests yet. So don’t waste time writing them.

Don’t waste time with continuous integration or continuous delivery. You can worry about that when you actually have a business paying you money to worry about it.

How about version control? Yes, do worry about that. But as cheaply as possible. Using whatever tools you are already familiar with.

Hosting? As cheaply as possible with the least learning curve. Unless you already do “cloud”, put it on the back burner. I launched Tamboo on a beefy HP Envy desktop I bought at Best Buy for less than $800 that I installed Linux on that functioned as a server sitting in my basement (literally) hooked up to a Time Warner cable internet line. For reals. Cost? Whatever I was already paying for cable internet on a monthly basis.

Get scrappy. Get serious. Get resourceful.

If it doesn’t explicitly create value for your target market, don’t do it.

Otherwise you’ll just talk yourself out of doing anything.

And every day that neckbeard cubicle in the sky will only get closer and closer to becoming your reality.

Don’t worry about HA at this point. Try to use open source where you can. Make it work.

Let’s light this puppy.

Okay, so from this point forward — one month — nothing more.

What do I mean by one month?

One calendar month. Not one man-month. Find the time. One month.

Once you’re done with something that supposedly meets this criteria:

The version of a SaaS application that actually generates $1,000/mo of revenue from a specified and specific target market with the least amount of effort and features possible.

You release it.

You reach out to your launch list. You reach out to anyone you’ve exchanged emails with. You reach out to your Twitter audience. Your Facebook/Instagram/Snapchat/whatever audience. You tell them: IT IS HERE. GET IT NOW.

And then you wait to see what happens.

Prepare for the tsunami while expecting the small creek.

After all, this is your first version, your MVP. Prepare to be torched. Prepare for people to disparage you. Prepare to be lambasted.

Because you probably got it wrong.

But that’s not the point.

The point is, now you market. Now you sell. Now you try to get people through that funnel. Do they sign up? Why not? Do they use the app? Why not? How long do they use the app? Why not for the full trial? Do they convert? Why not? And you turn the knobs until you find a way to fucking make it work. At each stage of the funnel, turn those fucking knobs.

And this is why you don’t go off building castles in the sky: The general disposition of people is that they don’t give a shit, and that they don’t want to spend money on things.

You have to earn their attention. You have to earn their respect. You have to earn their money. And you’re not going to pull that off on your first attempt or foray.

But you still have to get out there and do it. Otherwise no one knows you exist. No one knows that they can give you their credit card and get what you have to offer.

Just. Fucking. Do it.

One last word of caution.

When I tell you that you’re going to get it wrong, I’m not kidding.

The expectations that people have for SaaS applications are dramatically higher than they were in let’s say 2008.

To convince people to part with their precious credit cards numbers is a task that gets harder every single day.

It’s almost like an arms race.

Fancy smansy logos, graphics, webpages, apps, etc. dominate our world. They make it harder for people like you and me to capture a portion of the market.

Don’t focus on fancy. Focus on value. You need to find the keys to the castle. The things that only your app can do even if it looks like a 2006 web app. Find the way to deliver more value than what everyone else is doing and you win. You can short-circuit this by putting up some fancy smansy graphics, but that’s a short-lived victory — sooner or later people will realize all you’re offering is saccharine and go to the competitor that actually delivers value.

You’re going to get it wrong on your first attempt.

You’re going to get it wrong on your second attempt.

And probably your third.

Just understand — it’s harder now than ever to build a successful SaaS business.

It’s a fucking arms race. The expectations get higher and higher.

And it gets harder every single fucking day.

But because of that, today is the best day to start a SaaS businesss. Yesterday was better, tomorrow is worse.

Go get ’em and best of luck.

This ends Part 3 of The Epic Guide to Bootstrapping a SaaS Startup from Scratch— By Yourself.

In Part 4, we’re going to explore more of product/market fit and what that means for you.

Be sure to follow me on Medium and Twitter at @cliffordoravec and watch for the next installment to drop!

UPDATE: The Epic Guide made it to #3 on Hacker News! Read what that was like in The Morning After: Startup Famous for 24 Hours (Or, What a Hacker News Hangover Really Feels Like).

UPDATE #2: Part 4 is now available!

Hacker Noon is how hackers start their afternoons. We’re a part of the @AMI family. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities.

If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!