An MVP for SaaS should be as manual as possible. As a programmer when I say manual people think I mean start a bash script, instead of it being a cron job. What I mean is that as much as possible MVP should consist of a person, reading instructions from an internal wiki and tracking what they do in a spreadsheet.

This isn’t a new thought the Wikipedia page on MVP even describes doing something like this for the MVP of a service and googling for “concierge MVP” gives lots of examples. Eric Ries and the lean startup movement have been promoting this type of thinking for a while and Rob Walling touches on it when he talks about launching a software product in Start Small Stay Small

But these are mainly reasons to do it manually from a purely business perspective. They don’t really emphasize why you would want to do it manually from a software engineering perspective.

Cheaper

Every programmer knows once you write a piece of software creating another copy, or running it for another customer is (practically) free. The cost equation for software is:

total cost of product = fixed cost + (0 * number of customers)

Where fixed cost is essentially the salary of your developers and designers. But this equation is only applicable to finished products. With an MVP you will most likely be iterating on the product multiple times which means that there will be a fixed cost for each iteration.

By doing it completely manually you change the equation to:

total cost of product = 0 + (cost per customer * number of customers)

When the number of customers is small (like during an MVP) even with a high cost per customer it’s unlikely that it will be greater than the fixed cost of multiple iterations of the software.

In addition you’ll gain better insight into what software you should be writing and designing. And if your product doesn’t work you haven’t payed the high fixed cost of writing reams of code

Faster

During an MVP your application layer and infrastructure will normally not need to change that much, but the business logic layer and the front end is likely to change multiple times as you get feedback from customers. From a product point of view feedback is great but to iterate quickly this means that you’ll have to be constantly tweaking the business rules and front end.

Updating code without incurring too much technical debt takes a lot of time, which means you aren’t iterating quickly. To update code properly you need to

1. Update the test
2. Update the code
3. Get a code review
4. Push to production

In addition if your business logic model is completely wrong you’re going to have to refactor your code and update all of your underlying database tables. Doing this can take a lot of engineering effort, which will slow you down. By doing it manually at first you learn the domain model, which means you can get the domain model right the first time you implement it.

Better error handling

People are incredibly good at seeing patterns in data. I’ve previously described humans as slow executing code with amazing error handling. If a human is manually going through the data and taking an action and they see something strange they’ll stop and consider it. A human is not going to buy a stock at $100 per share if it’s currently selling at $20. Unlike a computer which will happily do exactly what you tell it to.

Early in the development of a product you are going to have a lot of unknown unknowns which you are going to have to handle. But you won’t know what they are until somebody notices them. By doing the work manually you are more likely to find them earlier then if you were having code do it.

How to do it

Just because you are doing the work manually that doesn’t mean you shouldn’t be rigorous though. I’ve noticed some common patterns and best practices when manually testing a product.

1. Write down every step that you are manually doing.

This doesn’t have to be a wiki, although I prefer one, a Google doc will suffice. But every single step should be documented. Not just what you do but how you make decisions and filter out options. So if you are deciding not to send out emails to clients with hotmail email addresses or anyone under 13 then that should be documented. As the steps and rules evolve and change you should update the wiki.

Think of this is as the code that runs the process. Sufficiently documented manual processes are indistinguishable from pseudo code. Which makes eventually implementing the business logic easier.

2. Track what you’re doing and who you’re doing it to.

If you are manually onboarding a client you should be tracking what state of onboarding they are in. If you are sending out emails to customers you should be tracking who you sent it to and when.

If the wiki is equivalent to code this is the equivalent to the database tables in your final application. For that reason I like to use a Google spreadsheet since it makes it easy to import data into SQL, although I know some people prefer Trello

3. Have multiple people do the work.

This isn’t as important as the first two steps, but if you have the resources, having multiple people doing the work is preferable. It lets you iterate faster. Since you are doing the work manually each customers work will be done slowly (compared to a computer). Having multiple people speeds the process up.

It also forces you to be rigorous about writing down every step and tracking what you are doing. How to perform a step can’t just live in someone’s head if multiple people are doing it.

What shouldn’t be manual

Obviously going between manual and fully automated isn’t binary and you shouldn’t be dogmatic. If there is a specific part of the project that will take a large amount of time to do by hand and can be easily automated then you should.

A common example of this is metrics or page hits which are almost always expensive to compute and track manually but cheap to automate e.g. Google analytics. Similarly if your new product will be very similar to an already existing product of yours it may be cheaper to simply build the product.

But it’s amazing how complicated of a workflow you can manage with a human, a set of instructions and a spreadsheet.