Strategies for Making an MVP for a startup
To build an MVP to get your foot in the market means you have to build and ship, and ship it fast. There are things we have to account for as we do this without breaking our souls. The ship must be easy to repair, and it must be well understood, in a very short time. New ship builders need very little instructions, and a lot of leeway to operate before they are destined to make a mess.
As we build the app we keep an eye on the following traits but soon trail off and be side tracked.
Monetizing: start with one strategy
The application itself could lend itself to which way to monetize, your strategy should revolve around it. Or monetizing may not be clear. Like YouTube. It took a while before they knew how to make money out of it. But YouTube app is so big, it stopped being this nice little MVP with a couple and a half developers. If you don’t know yet how to monetize your app, it’s okay, ship with some features, and wait for it to reveal itself. But don’t build for seven different ways to monetize.
To ship safely, change the developers mindset
May at times did I do work for clients who wanted to revamp their version 1.0 now that they proved it worked. Money that could have been saved if they were a little more careful.
If you had to choose between using all the shiny third party libraries, linters, productivity tools and Git magic, what stops a new developer from messing it all up with unnecessary overhead? If you keep your code clean every day, spend time and effort into keeping up to date with the latest version of whatever frameworks you decided to use, or third party libraries you carefully choose, a new developer would inherit this mindset. Not the Prettier linter usage. In the beginning of a project, that would last at least a year, it pays off to clean a bit every day, than having a hammer to stitch Lego pieces together.
In my last decade or more, I have created dozens of functions with abstracted properties and external configurations thinking I shall need them one day. I have yet to make use of them! I stopped. I only configure the parts I need to configure now, and probably 2 months from now. If in two months I am not making use of it, I hard code it.
Do it yourself
Here is an unusual advice for you: if you do not have enough budget to get an expert to build it, either build it yourself, or offer partnership with an expert. If you build it yourself, you will always be aware of the things it needs, and down the road would hire the right expert. A junior would consider you a short term money bag and resume filler. In addition to that, maturity in the tech world has perks. You do not have to be a seasoned SQL developer to know what to avoid and how to create the right stuff, simply because the skills needed to get there are: knowing how to ask the right question, knowing how to choose the right answer, and knowing, most of all, how to fight the urge of trailing a trendy catch phrase: the silver-bullet kind of claims.
Overhead of security and privacy
You might think security and privacy as good investments ahead of time. For so long, Windows had the worst security measures, until Apple machines started making headways in the general public, attracting more users, and more hackers alike. Your app will not attract hackers and crackers for a good period of time. Relax. Badoo, a company that made its first million users in the first 6 months, deliberately relaxed their privacy measures. It should not be your priority either.
No silver bullet
I remind you, and myself, that in startups and kickoffs, there is no silver bullet. Time changes, technology changes, and what was not easy a year ago, now is a breeze, and what was uncharted land a couple of years ago is now mount Everest, the place with 35,000 annual visitors.