Batman vs Bane: Building a Software Startup

If Batman and Bane each had a startup, Batman’s would whoop Bane’s in a heartbeat and I have scientific proof. Why? Because Batman would release a Minimum Viable Product, and Bane would just throw money and resources at his until he thinks he’s ready to launch.

But before we get into this heated debate, let’s talk a little bit about what a Minimum Viable Product (MVP) actually is. We can dissect the term MVP into three parts, the “Minimum”, the “Viable” and the “Product”.

This seems like a no brainer, but each part actually has equal weight in determining the success of your product launch.


Many startups or side-projects begin with the idea of a “Product” and how that product will help its customers or users, then they go out and build the product. Simple enough right? Just build it and they will come, right?


I’ve made this mistake several times, I thought I had a great idea, so I built the product, did a little bit of marketing, sat back and…nothing.

Or, even worse in my opinion, I would get a ton of interest, spend 6 weeks+ developing a product, and then no one would actually use it even though I had 2000+ pre-signups.

The “Product” part is by far the easiest part of making an MVP. After all, you’ve got a great idea that you think tons of people will use because it solves a problem that you personally have.

Turning that problem into a marketable product solution is the goal of your startup or side-project. If you’re reading this post, chances are you have no shortage of ideas about what can make your product great and what can make it better than the competition.

In fact, one of the scariest things I hear from people beginning their business is that there is no competition. That’s bad, that might mean that there potentially is not a market for your product.

One of the easiest ways that you can save time and money before launching your product is by researching the competition that DOES exist (I guarantee it). Buy and use their products to figure out where they are lacking, where they are succeeding, and how easy to use they are. Can your product perform this task better than theirs? How would you improve their product?

Take notes and write all of your findings down in a notebook. If you still feel like your product can be a great success, its time to move on to the next step.

Enter Bane.



Bane builds the perfect product. He’s got muscles, a freakin’ bomb, an army and a cool voice changing face mask.

But the problem is that he hid in the shadows until he thought he was completely ready to launch his perfect product. Instead of validating his idea using a Minimum Viable Product, he already spent all of his resources building something that he thought would succeed.

Everyone thinks their product is going to succeed, otherwise they wouldn’t be building the product. Those that lead long, happy, crime-fighting lives like Batman know that they need to gradually perfect their product and get input from their users as soon as possible.

Let’s say that Batman and Bane each begin working on their startup at the same time, each of them has the same amount of time and resources to spend. Batman decides to make a Minimum Viable Product and begin testing it:


Batman starts off by learning how to fight. Once he learns hand-to-hand combat, he goes out and beats up a few bad guys. Good news, he learns that he can successfully beat the crap out of bad guys! Learning is the important part here. Now that he knows that this is going to work he builds the Batsuit & Batarang. Then he goes out and beats up one hundred more bad guys. It looks like this is going to work!

Now for some hardcore investment, he decides to build the Batmobile. Good news, now he’s the Dark Knight of Gotham City, he’s making a ton of money and he’s beating up a ton of bad guys.

At around the same time Bane comes up with his idea for taking down the Batman. He spends a ton of time crafting the perfect plan, but he never tests his plan. He may be the perfect product, but while Batman was learning how to beat up, I mean gain, new users, Bane was busy making his product perfect.

Spoiler alert, Batman takes a few hits from Bane in the beginning, but eventually Batman beats the shit out of Bane and we all go home happily ever after.

They both spend a boat-load of money. But since Batman has been crafting himself since the beginning he winds up winning because he truly discovered what the public wanted. He tested his product continuously instead of waiting to release something perfect.

The goal of an MVP is to test your product before putting in a large amount of time, effort, resources and dollars into it. But what is the right way to test your product without having the complete product finished? This is where the Minimum Viable Product shines.

So you’ve learned your first lesson, “Don’t Be Bane.” Now let’s move onto what really makes an MVP.


The key of the MVP is “Minimum.” I like dividing this into three separate parts:

  1. Minimum amount of time to develop.
  2. Minimum amount of capital.
  3. Minimum number of features.

Each of these three minimums are detrimental to your MVPs success. The point is to be as lean as possible until you know for sure whether or not your product has a market.

Minimum Amount of Time to Develop

One of the most important things about building an MVP is your time to market. The quicker you can get to market, the faster you can test your idea to see if it works. One of the easiest ways that you can decrease your development time is by using solutions that already exist. There are three primary areas that you should try to plan for that will drastically decrease the amount of time it takes for you to develop your MVP:

  1. Open Source Code: Chances are there are open source projects that already exist that will help you to build your MVP quickly. For instance, when I wanted to add video chat to my side-project,, I knew that it would be an absolute pain to program it using WebRTC from scratch. So I did my research and found EasyRTC and programmed my video-chat in less than 300 lines of code. For free.
  2. Closed Source Code: Your time is worth money. If given the choice between working for 40 hours to program something, or buying a solution that could help me for $100, I would spend the $100 in a heart beat. In fact, the primary feature of, “Collaborative Coding,” is actually built using Firepad. And while Firepad is open source, Firebase (the Database-as-a-Service behind Firepad) costs $50/month once you get past their free limits. Programming this feature would have taken me a TON of time. To me, that’s $50/month well spent.
  3. Frameworks: Use them. Seriously. Gone are the days where you can make a full blown web app using only jQuery, and don’t even get me started on the backend. Frameworks exist to make your life easier as a developer, to allow you to iterate quickly. Some of the most popular front-end frameworks are Ember, Backbone (I use Marionette on top of Backbone) and AngularJS. To see these frameworks in action, or check out some other ones, TodoMVC is a great resource.

Minimum Amount of Capital

You see it in the news almost everyday: “X Startup Raises $X Million Dollars.” And I hear many of my friends saying “Man, I could do this if only I had $100K so I could quit my job and work on my idea full time.”

More often than not, they haven’t even begun working on an MVP. And one of the most important things about an MVP is to test your idea without spending much money.

You’re going to have to buy some things: a domain name, server (hopefully virtual server as a service), any closed source software that would make your life easier, etc.

Invest $100 or $500 of your own money to see if you can get your product off the ground first. If you are met with some success, then, and only then, should you begin to invest more.

Doing this ensures that you aren’t going to quit your job, try to build something, and then fail when no customers come knocking on your door.

Minimum Number of Features

Maybe you have 15 different ideas that you want to build into your product, but building all 15 is going to take a lot of time and money. So what’s the logical next step?

Let’s only build a few of those features just so we can test out the idea.

Remember, testing the waters to see if your idea is actually going to take will reduce the amount of time and money you spend.

In fact, lets pick only ONE feature to build. Maybe it only takes you a few hours and $50 to give it a try. Great!


Whoa, what happened there, “The Machinist” Batman? Did you decide to starve yourself?

Having the minimum amount of features that you can is important, but only if the combination of those features is “viable.”


Maybe one feature was too little. This brings us to the last piece of the MVP puzzle, “Viable.”

One feature might be too little, 15 features is most likely too many, so let’s determine how many features we need to test out our product. You know the problem that your product solves inside and out, and chances are its a problem that you have personally.

So out of those 15 features, what are the most important ones?

Feature Management

So how do you manage your feature pipeline? How do you determine which features should be included from the beginning? I like to pick 1 or 2 features that you think are absolutely necessary to:

  1. Solve a problem for your target market (or a portion of that problem).
  2. Make your target market use your app (this is the viable part).

What are the smallest features that solve the biggest pain points for your users? You should only build those to test out your idea.

I’ve had this discussion with plenty of contract work where a non-technical team will hire me to build them a Minimum Viable Product. I explain the concept of an MVP to them, and then begin to ask them what features we can remove. What’s not necessary for seeing if this idea is going to work? Normally this discussion starts out fine.

I give them some recommendations on what I would build, they agree, and we continue to talk. Then, 9 times out of 10, I wind up getting an “American Hustle” Batman:


I get a call the next day. Somehow, after they already agree that we need to cut out a majority of the features, they wind up talking themselves back into all of the features that we removed, and then they also tack even more on top of those!

I call this “feature bloat.” Its when you start adding back in features that you think are necessary again, or features that provide almost no value in determining whether or not your product will be successful.

Sometimes I succumb to this temptation, “this feature will only take me a few more hours to build, I should just build it.” But stay strong, this is an iterative process; you can always add those features back in once you determine if you product is viable.

The definition of “Viable” is “capable of working successfully” or “feasible.” You want the bare minimum number of features that will get people to try out your product.

You can’t be afraid to bench features.

You might need one feature to be viable, you might need five. But whenever you think something is “necessary” you must step back and ask yourself:

“Is this feature necessary to test whether or not my product will work right now?”

No? Then put it on a list of possible features to add later. You can always add the feature in later once you know more about how your users are actually using your product.

Minimum+Viable+Product = Success

Batman started out as just some kid on the street who had his parents killed. He came up with a great idea for a product: let’s rid the streets of bad guys.

He started out small, using hand-to-hand combat. Then slowly perfected his technique, sought out mentors to learn from (competitors), he began to invest money into features like the Batarang.

I would argue that Batman is the perfect MVP success story. He started out with something “Minimum” and “Viable,” tested it, found out that it worked. Invested more time and money, and now he’s the richest man in Gotham City.

But remember, “The Machinest” and “American Hustle” Batmans are only a few mistakes away. You must have the perfect balance of features in order to succeed with your MVP. Don’t have too little, but don’t think that more is better, in fact, the opposite is true in most circumstances.


So I’m calling all of you crime-fighting programmers and product-people: start small, build only the portions of your product that you need to validate your idea, then start adding more and more.

You don’t need the Batmobile to get your first customer. That can come when you are on your 100th, 1000th or even 10,000th customer.

Free "Building Software Products in a Weekend" eBook

You'll learn the development strategies I used to program my SaaS product in just 36 hours.

Any programmer can take information in this practical 53-page eBook and use it to build a software product. You'll be able to take your idea and boil it down to a Minimum Viable Product, learn how to waste less time writing unnecessary code, and use my 3-step development process for building quickly.

Download link will be emailed to you. No spam, unsubscribe anytime.

  • Tony Woodall

    Matt, great article. I love reading about startups and how they get started. I will be following to see how it goes.

    • Matt Kremer

      Thanks Tony! Glad you enjoyed the article :)

  • Mariusz Klimek

    Hi, Matt. Following John Sonmez led me to this blog :-) I decided to read your ebook and than your blog from the very beginning. I think it’s the most valuable (web)page for people like me, who want to start with some pet projects. Thanks for your article!