So, you've got an idea for a new website. That's cool. Now, what do you do?
In one scenario, which I call the Big Gamble, our excited entrepreneur begins to fill napkins, notebooks, and whiteboards with lists and drawings of all the features they would like to build into their exciting new application. They turn all that data into a Request For Proposal (RFP) to recruit a developer to build a giant monolith to their ingenuity. Developers bid on the RFP with big dollar signs in their eyes. Eventually, the application gets launched and then, at last, the target end users get to see it. The users may like it. The users may hate it. Or, the users simply just don't understand it.
A better approach to application development is to work with a reputable developer, often on an hourly basis, to build out something called a Minimum Viable Product. (MVP). An MVP, by definition is just enough of the core features of an idea to express your idea in a way that it can be consumed and evaluated by users. There are several reasons that justify this approach including: return on investment, responsiveness, fail fast philosophy, and code base agility.
ROI is the compass used by so many businesses and entrepreneurs to guide their journey through the business world. ROI is a simple formula: (Revenue - Cost) / Cost. There are two ways to increase ROI: Increase revenue or decrease cost. Decreasing cost does more to increase ROI than increasing revenue.
Let's say a $250 investment produces $1000 in revenue. That will produce an ROI of 3. - A $50 increase in revenue increases ROI to 3.2. - A $50 decrease in cost increases ROI to 4.
The strategy of pursuing an MVP is all about decreasing cost.
If our brave entrepreneur has a set amount of money to invest in their new application, the Minimum Viable Product Strategy keeps more cash in reserve to allow the entrepreneur and the developer to respond to feedback from end users and make changes/improvements in the application that bring real value to the entrepreneur, their investors, and their users.
Not all ideas are created equal. Sometimes, it's just not going to workout. An MVP allows our fearless entrepreneur to get up, dust themselves off, and either refresh their vision for their application or to pursue something else entirely. We learn more from failure than we do from success, and the most important lessons, like "don't put all your eggs in one basket" apply to developing a application just as well as anywhere else.
When it comes to developing software, the general rule of thumb is that "every line of code is a liability." You want to write as little code as possible to fulfill the code's function and as few functions as possible to build your MVP. The more code you have written before you start to respond to the market, the more it costs to make changes. The Big Gamble type projects are notorious for having functionality that is literally never, ever, ever used. Only write code that gets the basic needs accomplished and respond from there.