How to Build an App Price Quote
The question I get asked every day without fail is, “How much does an app cost?” At the beginning of the week, I am polite and professional. I respond with something like, “Well, that depends on a lot of factors. Let’s sit down and discuss our process.”
After Wednesday, I’ll have most likely been asked, “How much does an app cost?” at least five or six times. My answers become a little less ambiguous, tending toward the silly: “We’ve built apps for as little as ten thousand dollars and as much as a million dollars, so it really depends.”
As the week winds down, I may start to develop a small edge to my answers. “How long is a piece of string?” I might answer. Another favorite retort is, “How much does it cost to build a building?” These tired responses are designed to point out the complete impossibility of answering a question like that.
App costs vary drastically. Like most professional service businesses, we base our costs on our estimates of the time and resources it will take to build something. This usually involves a fair amount of planning, discussions, and in-depth knowledge of the problem we are trying to solve.
I’ll give an example of how we quote project work:
A client comes to us and describes what they are looking for. We work with the client through a number of whiteboarding sessions to make sure we understand exactly what they need. A project manager (PM) and a solutions engineer are always sitting in on the meetings, taking notes.
The project notes are then discussed with one of our lead developers and a user-experience (UX) expert. This is normally another extended whiteboard session or two, where we draw out more potential designs, workflows, and features. We highlight potential pitfalls from a technical standpoint.
Once we have a solid understanding of the application’s main features and workflows, we start wireframing. Our PM and UX experts work together to create an interactive document that mimics much of the functionality of the actual app. This is not just done for the front-end application, but also the administrative screens, email templates, and web versions. Each page is annotated with functional specs.
Once the wireframes are complete, we move on to the scope documentation. A scope is a text document describing, in detail, everything that cannot be illustrated by our wireframes. User stories are a common feature. These are descriptions of the types of interactions a user would experience using the product. Permission and role structures (descriptions of the features that each different user-type will have access to) are covered in detail. A small app takes around 20 or 30 hours of work to fully scope out.
Once the scoping and wireframing are complete, the documents are turned over to our development team. Our CTO will then run a session where each functional area of the specification is mapped out to a time and level of effort estimate by the team. Each programmer has their own strengths and weaknesses, but software is built as a team. If a feature is under discussion, one developer might say, “I need two weeks to build that,” whereas another might chime in, “Don’t worry, I’ve built something like that before, I can do it in a week.” We trust our developers completely. Most of our team code on the weekend for fun, so we live and breathe this stuff!
After our CTO and PM have gathered all the requirements and developer time estimates, they start work on figuring out the level of managerial effort and QA time. Each project (unfortunately) needs meetings. Meetings for progress reports, technical evaluations, etc. We also plan for a certain number of changes. No software is ever delivered to a client without them asking to change one or two things.
Depending on the type of app, we know what percentage of overall development time will be spent on testing and debugging. Feature-rich, customer-facing apps require a lot of user testing. (Testing where a human being has to play with the app to find bugs.) Business intelligence systems require tons of small automated tests, which are written by programmers to check their invisible functionality.
Once all that is said and done, the project’s PM will put together a proposal for the client. A typical proposal will contain quotes for:
- The administrative back end
- An iOS app build
- An Android app build
- Any other device, browser, and operating system builds
- Hardware and hosting costs
- Security system costs (Encryption certificates, audit requirements, etc.)
- Separated QA costs
- Ongoing support fees
Usually there are a few other considerations unique to each project, but that covers the most common items in a Sourcetoad project.
I don’t intend on showing off how diligent or rigorous we are in our planning processes. Rather, I am trying to illustrate that a fair amount of work is required before we can answer that daily question, “How much does an app cost?”