Don’t go ‘all in’ right at the start, take baby steps
Can this mobile app be built?
This is the question startups usually ask app development companies. However, it is a wrong question to ask. The right question is, “Should this app be built?”
You need to know if the app you have in mind should be built or not, before you go too far down the road. This means that you don’t have to spend all your money developing the full app only to learn that there are hardly any takers for your big business idea. If you can get this user feedback early on by running prospective users through a prototype, you would know if your idea is of the stuff of unicorns, or not (or something in between, with some changes). That’s why you only need to build a prototype that closely mimics the app you have in mind. If your prospective users love it, you will know you are on to a good thing. Or they might give you great feedback on what is it that they really want. Either way it is a great input so you will know where to put your money on.
Take baby steps
The term ‘All In’ possibly originated with gambling games such as Texas Hold 'em style poker. Still a poker metaphor, 'All In' has also come to mean a situation whose subject is unreservedly involved, without qualification fully committed, where the maximum 'raise' is to bet your FULL stack of chips.
While it could be a good strategy once you have found the secret recipe for cracking open the market, a classic mistake by startups is to try and go the whole nine yards in the first launch itself. That is, spend so much in building up that first cut that it leaves them with nothing, should they need to do some course correction or pivot to a new model. It is especially true for the ones who are bootstrapping!
The correct lifecycle is:
The validate phase should go through cyclic ‘Build-Launch-Learn’ till the time a startup finds its sweet spot and needs to scale up. That is the time to go ‘All in’.
The lean approach
From the product vision, create the product backlog along with your app development team. The backlog is the complete list of features that the leanest version of the app must have, which end users will find extremely useful.
Now plan sprints in which specific features are picked from the backlog to develop. At the end of a sprint (one to two weeks), get a demo of the product. You get to quickly assess if the development is as per your product vision, and what needs to change.
See the app evolve
With this lean approach, and weekly demos of the app, your startup teams get to see your product evolve, practically on a daily basis. While the focus should be on building the minimum viable product (MVP), the right amount of attention needs to be on ensuring that the fundamentals of strong app architecture are in place. Go agile, but do have enough information which is fully thought through.
For example:
- A detailed architecture of the platform
- A list of prioritised features/user stories
- Cloud deployment strategy
- Plans for scalability should the idea take off, etc.
Startups by definition are trying something new, so they need to build just enough MVP to go out and test their idea. It’s also the most feasible approach to pitch investors, who can visualise and explore the true potential of your app. This is a trend that is picking up. Apart from building a cost-effective app, it helps you to find what your customer actually wants.
(Disclaimer: The views and opinions expressed in this article are those of the author and do not necessarily reflect the views of YourStory)
