Custom software projects move the needle. Whether you are building out custom website features, software as a service, or an internal-use system that will overhaul the way you conduct your business, custom software offers your organization the opportunity to streamline, optimize and offer customers experiences that otherwise would not be achievable.
However, not all projects are defined the same. Software is sophisticated, and as such, it takes time and effort to outline and architect the right solution for your specific challenges. One mistake we see all-too-often is the entrepreneur or project stakeholder who is trying to bite off more than they can chew. To those folks, this post is dedicated… Software is a living, breathing thing. And, as such, it isn’t always necessary to aggressively build everything at once. But how do you know when you need to plan for a multi-phase approach? And how do you devise what phases should exist and what features should constitute said phases? This post will attempt to clarify these common questions.
First, I want to impart some thoughts as to the wisdom of taking a phased approach to software development. For the most part, building projects in phases is a hard and fast rule in the software development arena. Almost every project we see has some forward-looking component where subsequent periods are being plotted. Therefore, this concept needs to be embraced from day one. Failure to do so will actually limit you significantly and increase the odds of project failure. Everyone wins when you carefully divide an initiative into phases. First, you limit your exposure to the project. Projects that are overly complex and grandiose are the most likely to fail. As such, a smaller initial phase mitigates your risk of project failure. Secondly, it helps you see results sooner. A quick prototype builds your confidence in the concept. An MVP gets you to market fast. Seeing immediate results is good for the customer, great for the investor, and even better for the entrepreneur. Finally, phases help you iterate wisely. When you devise a new project, you may outline what you believe at the time to be crucial stages, which subsequently can change as you see the product in use. If you attempt to build everything from day one, well, you simply don’t know how to iterate because you have no real-world data to guide you.
As you can tell, iterating makes sense.
So now, let’s focus on how you do it…! I’ve highlighted key thoughts that you should consider while phasing out a custom software project – let’s dig in!
Step One: Understand, Embrace and Define an MVP
Surely this step could be a topic all of its own. In fact, it has been! MVP is an industry standard acronym for “minimum viable product.” This concept is best explained by this definition: “MVP is the product with the highest possible return on investment compared to the associated risks.” In software development, this is an essential concept. The idea of building out a feature set that is the minimum you need to operate the product to its intended audience is critical. This allows for the ultimate in risk mitigation while still allowing you to achieve the vital aspects of your project.
So how do you define what your MVP is? Well, it depends on the project, of course. But one general rule is to establish a couple of core use cases that you are seeking to achieve. Define your users, their roles within the system, and what they are going to accomplish as they plot around the system. In doing so, you need to be honest in understanding what core functionality is and what is secondary or tertiary. This is best achieved by simply asking yourself simple, basic questions. Why are you doing this? What problems are you looking to solve? Who are your users? How can you most easily solve them without adding complexity?
It’s so easy to think about your project in terms of where you want it to be, down the line. I get many inquiries to our website from people who want to build the next Airbnb or next Craigslist. They have complex use cases that dig way too deep into specific functionality. It’s okay to say that you want to be the next Airbnb – but remember that they have spent millions of dollars over many years to develop that platform. You need to focus your efforts on the smallest specification that can deliver the functionality that will serve as the foundation for you to grow your empire. You don’t need to compete in all areas from day one. This concept should be your north star in terms of defining your MVP.
Prioritize Features
One method that makes sense in defining an MVP, especially when you are feature-happy, is to list all of the features and use cases that come to mind into a matrix, and then organize them by priority. This can be a fun exercise – plot out everything you can think of in terms of functionality. Then, simply assign a value to each: must-have, nice-to-have, wish list. This exercise leads to a level of clarity about what is and what isn’t essential. As you whittle down and identify what your must-haves are, take a second run at the list. Are you being totally honest with yourself? Are all of your must-haves essential to an MVP? Or are they vanity items or nifty features that you can live without in the beginning? The key word here is to be ruthless – evaluate each feature against whether or not it is immediately necessary to accomplish your goals. It’s okay to challenge yourself in this regard!
Once you have your list finalized, you can start to phase them out. MVP, V1.1, V2, V3. In our practice, we often look at V1.1 as the first iterative specification that is completed after an MVP goes to market. Almost always, project stakeholders want to address some issues in a month or two after launch. V2 is a more comprehensive specification that comes in the 3-6 months following launch. What you’ll notice is that as your development project commences, your V1.1 list will change. And your V2 and V3 may as well. This should serve as confirmation that you made the right choice pairing down your initial specification – unknowns are unknowns for a reason, right? As they present themselves, the best reaction is to know you are situated in a position that allows you to respond without blowing too much up. The proper definition of responsible phases enables you to do that.
Be Careful of Dependencies
One thing to watch out for when breaking your project into phases is dependencies. What constitutes dependency? The best way to define the term in the software world is that a dependency is presented when a feature needs some prerequisite functionality in place to work correctly. Or, put more simply, you can’t build a roof until you have the first floor in place.
Dependencies can pretty much make everything difficult if not considered. But first of all, it’s hard for the laymen to see where they may lie. So it may be difficult for you to plan out your development phases because you may not necessarily understand what needs to happen where. No worries, your developer or agency can step in and help you know where they exist.
However, even when you see them, you may be frustrated. It’s hard to explain to clients that things need to happen “under the hood” to accomplish specific tasks. Therefore, to avoid this frustration, it helps to have a software developer assist you in the architecture of your application, so that you can from there focus on planning phases in a logical order, where each stage builds upon the previous. This may require you to refocus some efforts and functionality in a way you wouldn’t exactly want, but, it will pay off in the long run.
Focus on foundation
I can’t understate this enough… The purpose of an MVP is primarily to get to market quickly, with minimal risk. But, you must not sacrifice your future possibilities at this point. You MUST ensure that your MVP is a foundation for future growth. This means you need to make proper technology solutions.
In our practice, we spend a lot of time to educate clients about the different pathways software development can take. As an example, today, most clients have a choice in development architecture when it comes to complex web applications. The new methodology includes the option of building your site with API-driven technologies. A custom-built API powers a front-end experience built on React, Angular, Vue.JS or similar. The second choice is to utilize a more integrated approach, wherein you rely on a platform that includes a single codebase, usually building an entire application on a platform such as Laravel, or similar.
The integrated method makes sense and can last for a long time. However, the API-driven approach splits the project into separate components, which over time will mean they will be easier to manage, scale, and iterate. Of course, the API approach takes more time and therefore costs more.
The decision between which direction to take must be taken seriously as this is a prime example of a foundational choice, something which you will have to live with for a long time. So, in making the decision, consider the long term implications. For example, if you someday may want to build a mobile application or any other software that relies on an API, then it’s probably a good idea to undertake that methodology now, rather than later. However, if your application is a one-off solution, and it will not need to scale in the future, then the integrated approach may be best.
It’s hard for you to know what will be a roadblock in the future, but it’s easier for your developer, provided they know in all honesty what you are looking to do in the future. So it’s good to be open about future plans, enabling them to make the best technical recommendations that allow for future growth, scalability, and reliability for your application.
Business vs. Technical phases
Sometimes, it makes sense to consider phases that can help you from a business perspective, not only in a technical sense. For example, it may make sense for a start-up to work in some preliminary phases to prove concept such as additional design work or conceptual renderings. Or, it may make sense for a team to work on functional prototypes to convince upper management that a project is worth undertaking. Either way, some phases can come early in the process to even further mitigate your risk and enable others to see the vision of your application without much code being written.
During the vetting process with new developers, spend time with them to discuss your business situation and what the process looks like on your side – including stakeholders, whether they be partners, investors, or others. This will help you in a few ways. First, you’ll get a sense of if your developers have any business sense – there isn’t a certification for knowing how businesses work, so having these conversations early can save you the trouble of working with a developer who has zero ideas with regards to how to run a business. And, having this conversation again will help the developer or agency work with you to best identify how you can leverage early-in-the-process deliverables to advance your initiative.
Wrapping Up
This post was fun to write, mostly because putting it together reminds me of the excitement we see when new potential customers come to us with ideas that they think will either improve their business or serve as an application they can build a business around. Building custom software, much like constructing a house or any other undertaking, can be a fun and gratifying experience. But, you have to be prepared to responsibly and thoughtfully proceed through planning, which ultimately should result in a properly devised approach that includes multiple phases.