So you have a great idea for an amazing software application that is going to revolutionize the world of business or be the next billion dollar mobile app. Great! Now what?

I am asked regularly by entrepreneurs and business owners with the need or idea for a new piece of software, “How much will it cost?”. The answer of course varies greatly based on the details, the features, the expectations, and all the other factors that go into creating a software application.

As a starting point, before getting into the approach, you should try to define all the details related to your app and what it needs to do. While the format isn’t particularly important, you need to capture the overall context of your application, the specific features it needs to have, and as much detail around each feature as you can think of. Some of the ways it can be done, includes:

Outline of features: An outline and nested bulleted list format is usually a great start if a full set of “specifications” seems too daunting, or

Wireframes or Mockups: For the more visually inclined using tools like Balsamic or are a great way to capture your ideas for the app visually.

For the scope of this article, I assume you have passed this phase and have created some kind of document outlining the details of your idea and what the software needs to do.

So… how much will it cost? It depends on how you want to go about it. In general, there are tradeoffs based on your budget, your timeline, and how committed you are to the idea at the start. Not sure if it is even possible? Start with a Proof of Concept. Have a firm idea of what you need and are full steam ahead? Plan for your v1 release. Building a mobile app? Pick your preferred platform and start with that version first.

Now, let’s dig into what these mean and which one is the right fit,

Proof of Concept (POC): It is like a prototype, where you are building some level of feature set around what the core of your application is going to do. This is a great way to confirm any of the unknowns in the application, such as the feasibility of a certain integration, or how the various elements of your software might interact.

The end-result of a POC is usually a partially functional system, without the bells-and-whistles or layer of beautification applied to it. It is usually used to confirm that what you want to do is possible, work through the unknown elements in your requirements, and have some deliverable at the end that makes the case for proceeding into full development.

It is a great way to catch any pitfalls that you might have overlooked, and to prove that what you want to do is possible. It is usually the ‘lowest cost’ way to get started, but on the downside it is often not going to be usable and will be mostly scrapped if/when you jump into the full product development, meaning the total cost to your end-game will be higher!

If you need a starting point for a fundraising effort or to make the business case to others along with refining the technical details for your product, it can be a good first step. However, if you already have a firm grasp on the requirements and feasibility, skip the POC phase.

Minimum Viable Product (MVP): MVP is a version of your application that has the foundational architecture in place and the “must-have” features that are required to deliver the core value. It does not have all of your features, but rather the core elements that your application is meant to do. In defining what your MVP is, you need to go through an exercise of what elements of your application are absolutely required, and which ones are in the “nice to have” category to save for a future release.

The goal of a MVP is to get a usable application in the shortest possible time and in the lowest possible budget. By stripping out all non-essential elements of your feature set, you are able to get to the core of what your software needs to do and focus on the solid foundation to build upon.

This approach is usually the fastest way to have an initial version of your software. If your application has a core need to meet but if you aren’t sure of everything else it needs to have, start with a MVP. If you have a very small budget and need to start with something basic to build upon and get initial users on, start with a MVP. When done properly, your MVP serves as a solid foundation to expand upon as your budget and time permit.

If you have a firm grasp on everything your initial application needs to do and you have customers waiting for those features, then you might want to jump straight to your version 1 release.

Full Version 1 (Beta) Release: With any new application, you will want to get to a ‘beta’ release, which is a full release of your software with all of the features it needs to have to go to market, but possibly needing some refinement based on user feedback. Whether you start with a MVP and work your way to a Version 1, or go straight to your initial release, you will want to line up beta users to start using your application for real. This is the only way you can truly validate the application as well as learn how to make it better based on user feedback.

If you have a clear vision of your software product and know the features that you need to have to go to market, planning for your full initial release from the start is the quickest path to get to market with your full set of features. Overall, this path will be the ‘most cost-effective’ way to get to market in both time and money.

However, the major risk to avoid when taking this path is “scope creep”. With nearly every software application of any complexity, you will realize many things during the build that you had not thought of. Many are things that you will want to incorporate into the product, but it is important to not act on all of these as they come up. Adding in features on the fly is called scope creep, and is a path toward a never-ending software build and potential derailment of your product itself. To avoid this, focus on your initial goal and keep a roadmap of things to come back to later. This will help you keep both your time and budget under control.

The secret to success: Iterate

One thing that is universal with nearly any software product is that the end result when you are fully “done” is usually different in some way than your initial vision. This is perfectly natural, and the best software products are built over time through ongoing iterations, or releases, where user feedback and new realizations can be incorporated and aligned with the business vision.

When budgeting for your new application, be sure to allocate some room for a beta phase and iterations on your initial release in order to refine your product. It is very rarely the case in the world of software applications that you get to a point of being “done”, and planning for this helps ensure you can get all the way to a successful product.

Our recommendation on how to best do that is to follow an agile development process, whether from the start, or after your MVP, or starting from your first release. Staying agile means you are always prioritizing your software features based on real user input and business priorities, and usually ends up with the best blend of pace, budget, and success.