You have decided that your business needs an app, so what is the best way to ensure that you get what you want?
Well you could follow the App Happening four step framework:
- Concept, Marketing & Viability
- Design & Specs
- Build & Approve
- Launch & Support
This is a best in class solution for getting the app you want, at the lowest cost, in the shortest possible time. App Happening provides free marketing tips, app concept templates, strategy guides, development timelines and even an eBook on creating a successful app (http://www.apphappening.com/ah/appbuildingguides). So why does (almost) nobody use these? I suspect the reason is a combination of, “too hard”, “why bother” and “I just want to get started”!
As a Developer, I’m not too worried about whether your app is going to sell well or deliver on your business case. My job is to deliver the app you specified at the cost I bid and within the agreed time frame. If you have reached the stage of hiring a Developer, I assume that you have already worked out that the cost and effort is worthwhile. If not, then I suggest that you go and have a look at the Concept, Marketing & Viability section (http://www.apphappening.com/ah/conceptmarketingviability) of the web site.
I’m also assuming that you have a clear idea of what your app will do, because if you don’t, explaining the concept to me will be difficult. I don’t need a complete Functional Description and fully laid out screen shots initially but I need enough to be able to provide you a price and how long the development process will take. Before going into the bare minimum specification requirements, I would like to discuss why the specification step is important.
How to spend a lot of Money and NOT get what you want!
If you have ever renovated a house you will know that the cheapest time to modify the design is before construction start. It is exactly the same for app development. You want to have a very good idea of the outcome before you start. Sooner or later you will need to make decisions about what the app will do and what it will look like. Given this fact, doesn’t it make sense to do it at the beginning? I guarantee that if you do, it will save you money and reduce frustration.
There are generally two ways that you can engage a Developer:
1. Fixed price; or
2. Hourly rate.
If you choose to go the hourly rate route then you could just make it up as you go along (some people call this AGILE development) but it can become expensive. If you select the fixed price approach, it is much more important that you get the definition phase correct. Do not assume that a feature that you want is included in the design, if it hasn’t been explicitly specified then your developer hasn’t costed it and it is unlikely to end up in the final product. Assumptions in the design phase of fixed price contracts lead to disputes, which waste everyones time and energy.
I have enough stress in my life…
If the specification of your app consists of something like “i need a game built in 1 week for a fixed price of $100”, don’t be surprised if no developers bid on it (what game? what platform? what device? what???). The level of design specification required depends on where you are in the development cycle. If you just want indicative pricing to plug into your business model then simple dot points which describe the objective, functionality and target platform (e.g. iOS or Android) are probably sufficient – just be up front with the Developer.
If you are committed to building an app then I’m afraid that I’m going to direct you back to the App Happening website page (http://www.apphappening.com/ah/designspec) on Design and Specification. It is in your interests to specify the app as fully as possible. You should include the Developer in this process if possible. Start with your simple dot point functional specification. Your Developer can tell you what is technically possible on a particular platform and what is possible but difficult (i.e. expensive). Once you have a good idea of app functionality, sketch up some indicative screen shots (wire frames), pen and paper is fine. Alternately get the Developer to suggest something. You want these wire frames to be low fidelity so that people are comfortable playing around with the design and changing them. The combination of the Functional Spec and the Wireframes will give you a flow diagram or flow map which describes how users will move around your app. Make sure that key functional screens are at the top of your navigation stack.
If your Functional Spec is detailed enough, the data base design (if required) will fall out of this. For a people based app, you may want to save information like name, address, phone, favourite colour, etc. Consider whether you think the data model will change in the future, if the ability to update and migrate data models isn’t built into the original design it can be expensive to retrofit it.
If you follow the above suggestions, your Developer will be in the best possible position to assure you get what you want, when you want it.