Summary: I encourage all entrepreneurs to build their own MVP – not so they can become a great (or good) programmer, but because it is the most efficient way to get an MVP in the hands of customers and validate the major business risks. Here are some examples from my current startup, soHelpful.me.
I Encourage Entrepreneurs to Build their Own MVP
In my startup help sessions I’m frequently asked by entrepreneurs about the process of building their MVP. I usually encourage them to start as single-founders and build their own MVP using popular frameworks before looking for co-founders or money.
There are a lot of reasons why I think we should build our own MVPs : save money, learn new skills, and prove our ability to execute, for instance. But the best reason is because it is the fastest way to test major business risks.
Learning How to Build an MVP != Becoming a Good Programmer
Many entrepreneurs are reluctant to build their own MVP because they know how hard it is to get good at programming. They’re right – it takes about 10 years in my experience. I’ve worked with amazing developers who could design elegant solutions to incredibly hard problems.
But most entrepreneurs are NOT trying to solve hard technical problems – we’re instead trying to discover a new scalable way to make money1. This usually involves testing (1) whether we’re solving a real problem, (2) whether we can get paid to solve it, and (3) whether we can build a path to bring on customers.
An MVP is designed to be minimally viable to test these risks – a product that is cobbled together, feature-poor, and buggy and one that few customers would ever use except earlyvangelists – those visionary people who are already trying to solve the problem themselves.
Learning how to build a web or mobile MVP app takes about 2-6 months depending your time and experience. And as you start building you’ll be faced with hundreds of decisions about features and user experience – decisions you are best qualified to make because only you know what is and isn’t important to test.
The most important skill you can learn in building an MVP is how to creatively hack.
How I’m Hacking my soHelpful.me MVP
Hack: a solution to a problem, doing a task, or fixing a system that is inefficient, inelegant, or even unfathomable, but which nevertheless (more or less) works.
Wikipedia , Hack (computer science)
I love this definition because it so accurately describes how I’m building the soHelpful.me MVP – a horribly inelegant product which nevertheless works.
After months of work and hundreds of hours of conversations a few weeks ago I made the decision to start building the soHelpful.me MVP. Even if I knew exactly what to build – which I don’t – an elegant product would have taken about 1 developer-year to build.
Instead, I was able to get a “product” in the hands of a few earlyvangelists in 2 ½ weeks. But I could never have written a specification for how to do it – instead I’m making constant judgment calls based on what to build based on the risks I’m trying to test. I’m constantly asking myself, “how can I hack this?”, and “is this sufficiently important to do today?”
And I’m sure glad I did – now that I’m getting feedback from early customers I’m already realizing that some of my assumptions even 2 weeks ago were just plain wrong. Had I decided to build an “elegant” product I would actually have built the worst product of all – one that didn’t solve problems.
7 Ruby on Rails Hack Patterns Examples
I currently develop with Ruby on Rails, so I’ll use Rails lingo for the purposes of giving you examples of hacks I’m using with soHelpful.me and previous projects. But similar patterns apply to any modern web application framework.
Skip Registration – Setup Accounts for People
I built a complex registration system for my first Rails product (it was not an MVP) 5 years ago. Then nobody used it and I had to manually setup accounts and profiles for people just to get them to try it.
Skip Admin Tools – use the Ruby Console
Every enterprise product I’ve ever used had an admin feature – so of course I built out a set of complex admin tools for my first product . Turns out I never used them because I was the admin and I just used the Ruby Console.
With soHelpful.me I’m skipping the admin tools and using the Console to administer it.
Yes – Repeat Yourself
Search through my soHelpful.me code and you’ll find statements like “TODO: DRY-up this code”. DRY means “don’t repeat yourself” – a great guideline developers use to make more elegant, readable and maintainable software.
I hope I’m lucky enough to have the opportunity to make an elegant product with soHelpful.me – that would mean I’ve discovered an opportunity and a real developer can build beautiful software2. For the moment “nonetheless works” is fine.
Do Complex Model Work by Hand
Some products require complex calculations with multiple steps to update the database. An example from previous startup of mine was calculating the taxes and shipping costs for a product.
Turns out this task didn’t have to be done real-time. I should have done it in Excel once a day, but instead I spent 5 weeks building a complex model to handle it all real time.
Use 3rd-Party Tools for Non-Core Risks
soHelpful.me needs to automagically integrate with Google Calendar to improve the workflow and scheduling for everyone. But I’m not testing the viability of a scheduling tool – I’m testing the viability of making it efficient for people to use 1-1 free help sessions to build their brand and reputation.
So for the soHelpful.me MVP I’m using 3rd party scheduling tools like Google Appointments or YouCanBookMe and creating tutorials to use them.
Automated Testing – Skip it or Do Very Little
I’ve found that Test-driven-development (TDD) on a previous Rails MVP only results in lots of extra work and slowed progress. I got some good advice on testing strategies from Dave Haeffner at sohelpful.me/tourdedave on what actually matters for web app testing.
I’m testing by hand and running a few Selenium IDE tests on the key business activities for soHelpful.me. Took me about 2 hours to create them.
Hard-Code Complexity & Rebuild
soHelpful.me uses vanity URLs so that someone looking for Lean Startup or Customer Development advice can visit sohelpful.me/teaguehopkins instead of sohelpful.me/profiles/5.
An elegant solution works like Twitter where vanity URLs are created uniquely, automatically, and ubiquitously case-insensitive across all actions. But I decided to temporarily hack the solution by hard-coding the routes in routes.rb.
match '/teaguehopkins' => 'profiles#show', :id => '5'
Of course this is a horrible long-term solution. I have to rebuild the code for every new profile! But when you’ve got a handful of profiles and a Rake task to deploy to Heroku it works just fine. I doubt Teague is losing sleep over it.
Hacks are Creative – Not Elegant Solutions
Of course these are MY Hacks for soHelpful.me – I only knew what to hack because I understand how Rails works and I know what I’m trying to test in this MVP. Many of them simply won’t apply to your MVP, but only you – not a outside development firm or your first employee – will know that.
Hopefully these examples will impress upon you why the investment of 2-6 months in learning how to build a basic web application in Rails or Django has such important business value for your career– only you, the moderately technically competent entrepreneur will be in a position to make the decisions that allow you to execute faster.
Figuring out what is and isn’t important can be tough the first time you try to build an MVP. You don’t have to do it alone.
If you have strategic questions about what product to build and how to increase conversion via email, you can always ask Andrew Culver.
If you’re at wits-end (as I was few weeks ago) wandering through the endless confusing maze of Selenium documentation or Rails testing frameworks I suggest seeking some sage counsel from Dave Haeffner.
And, of course, you can always ask me as well.
About the Photo
If hacking an MVP can go too far this photo by Florian SEROUSSI surely illustrates it. I can just imagine the listener saying, “if only it didn’t have this string…”
- This is also why experienced developers can actually handicap a lean startup – they’ve spent 10 years learning how to predict and solve hard technical problems and bring painful lessons to the startup, not realizing that the biggest risks are not technical at all. ↩
- Maybe that real developer is you! If you’d like to work with me on soHelpful.me feel free to drop me an email at firstname.lastname@example.org. Please include links to your work. ↩