Arriving at a final price for the development of software is not as simple as it sounds. Developing and creating software is a dynamic process that must be embarked upon before knowing all the answers, even though some of those answers would help with costing. When you build a house, you are given a rough estimate of the cost and the time it will take to build because variables such as building materials, location etc are known. However, when you develop software, both the developer and client need to remain flexible because the process inherently contains many unknowns.
Throughout the process, you will find yourself faced with questions such as “What if this happened?” or “Why don’t we add this?” Often these questions don’t arise until the product is at the testing stage, or at least half way there. Depending on the type of software being developed, you may also find yourself asking questions like, “What if the user deleted this while another user is editing it?” or “Why don’t we add branches to the companies and have branch managers?”
So, do you need all the details of the software project before asking a developer for a quote? No, because enhancing software/applications is a process that never ends and if we waited until we had all the details, some apps would never get built.
Of course, the more detailed your project is the better, but I tell my clients to just make the first, functional version of the software that can be placed on the market. From there we can build the second version and so on, refining it and developing it further
So what does contribute to the cost of creating your application/software and how can we keep costs down? Pricing the first version of any application/software comes down to specific variables.
#1: What is the core feature of the app? How complicated is it?
For example, is the app made to assist with decision making i.e. it gathers reports and helps the end user differentiate between them? Or is the app simply a survey builder with a twist? (Check out Emovey- an awesome app we helped build!)
The more complicated the core feature is, the more time it will take to develop and the more it will cost. It’s best to explain the core feature to the developer right from the start so he can give you a reasonably accurate price range.
#2: How many different users would be logging onto the app and do we need to differentiate between the users?
If the software needs to be quite complex, the cost is going to rise. For example, you might want to create an app for plumbers and suppliers to help them connect together. (Check out Gimble, another awesome app we helped build!) Your types of users can go from two (just plumbers and suppliers) to eight, with each side having an admin, state director, branch manager, representative etc.
Somewhere down the line, you will need to set up the roles and their functions so each type of user has a particular role with access to certain features in the system and not others. But ask yourself this: can the application run in such a way that the end-user would benefit without this feature? Nine times out of ten, the answer would be yes. The fewer types of users you have, the less complicated your application is and the less costly it will be to get it off the ground.
#3: Keep in mind appearance is not as important as functionality.
I’ve worked with a client who had a great idea for an app but was focused on animation- the movement of the elements within the app/website- rather than the functionality of the app itself. It’s like an author being more focused on a book’s cover rather than the words inside it.
Design is important, animation is great, but functionality is essential. Make sure that the design you start with is simple and easy to understand. I always recommend leaving animation until the second or third version of the application unless it’s within the budget to do it in the first launch.
#4: Lastly, you need to ask yourself whether users can live without certain features.
Would the product still be useful without a particular feature? If you answered yes, then write this feature in an excel spreadsheet and give it a score from 1-10, depending on how important the feature is. When you’re done you’ll have a list of features that are not essential but would be nice to have, ordered from least to most important. Ask the developer to quote you for each item on the list. Deciding which feature to drop and which to keep should then be an easier decision.
I hope this has helped you to plan how to get your software created in a budget friendly manner. If you have any questions please comment in the comment box below.
