Plan a Project

Let’s Get it Working First: 3 Reasons to Build Apps In Steps

April, 27 2016

 

Creating a new application is an exciting process where almost anything is possible. The decision to create an application is often driven by a single purpose, but as the requirements are put together more and more ideas are thrown into the pot. What started out as a clean, purpose-driven application can quickly expand into a do-it-all behemoth of an application that is meant to automate everything from payroll to cleaning the office. While there’s no reason an app can’t have multiple purposes, it is often wise to put them in incrementally instead of all at once.

Below I will outline three great reasons why building applications should be done in step by step fashion.
Building software is hard. That’s an important point that can often be lost in the exciting planning stages. It’s easy for everyone to be supportive of building an application when it’s just a concept, but as time passes and the concept has yet to turn into something people can see or touch, the momentum often ebbs away. This is normal, but can be especially damaging with a longer term product such as developing software. Unless there is strong momentum, a project that once seemed like a no-brainer now seems expensive and time consuming.

1: Get an Early Win

Luckily, there’s an easy fix for this. By breaking a big application into several smaller chunks you will be able to release usable functionality earlier. This will give users something tangible that they can use and get excited about. It’s a wonderfully validating experience to see a concept turn into reality and this will keep momentum going for the other modules of the application that have not yet been built. Getting an early win is key to keeping everyone on board and ensuring that the project will keep moving forward.
During the planning stage there are often modules that seem like must haves for the application to be successful. For example, maybe your application has a task component and you want those tasks to integrate with another third party task tool that you use. You figure that keeping your tasks in two places makes no sense and you know that you’d use that functionality every day. This is not necessarily wrong, but how sure are you that everyone else is like you? What if nobody else uses the third party task tool you use? What if they use it for personal tasks and don’t want to mix it with their work tasks?

What you need immediately is different than what you need in the long-term.
What you need immediately is different than what you need in the long-term.

2: Make Sure You Need It

There’s a concept in software development known as the Minimum Viable Product (MVP). This is the most basic level of functionality needed to make the application achieve its core purpose. It doesn’t include the bells and whistles that you may envision, but it gets the job done and can be built quickly. Furthermore, it will give you a great feedback mechanism from your users to determine what bells and whistles they actually want and need. If they demand a way to integrate their tasks with a third party task tool then you were vindicated and can start working on that immediately with no real time lost. If, on the other hand, nobody cares about tasks and it’s really calendar integration they’re concerned with then you can pivot your efforts to focus on that. Your goal should be to deliver what your users want which can be quite different from what you think your users want. By releasing the MVP you can figure out what they need.
There lurks a common misconception in the software development world that if a module isn’t included in the initial release then it will be either cost or time prohibitive to add it later. Therefore, the reasoning goes, let’s make sure everything we need is in our first release. It’s thinking like this that makes software projects take years, where they die before they ever get released. As it turns out, there’s no rule that says all modules have to be built at once. In fact, as the previous two reasons point out it’s often wise not to.

Make it to market fast to establish your brand as innovative.
Make it to market fast to establish your brand as innovative.

3: There’s No Reason Not To

The reality is that building software incrementally is not only more likely to succeed, but it also doesn’t have to be any slower. If structured properly, software can be easily expanded with additional modules later. Furthermore, planning for future phases can be done in parallel with the development of earlier phases. This allows for a seamless transition from releasing one phase to beginning development on another. Building software in a phased approach reduces risk and greatly improves satisfaction.

The reality is that building software incrementally is not only more likely to succeed, but it also doesn’t have to be any slower. If structured properly, software can be easily expanded with additional modules later. Furthermore, planning for future phases can be done in parallel with the development of earlier phases. This allows for a seamless transition from releasing one phase to beginning development on another. Building software in a phased approach reduces risk and greatly improves satisfaction.

When it’s all said and done applications can be tremendous tools to help your business become more productive. But that’s only the case if they actually get built and released. To ensure your software projects are successful keep them focused on their purpose, release early and often, and build what your users want (not what you think they want). In other words, get it working first, then start expanding.