Budgeting For Your App Idea
Through our previous story So, you want to build an app , you may have ironed out the details of how to make it work for you and your tech team. The next step would be budgeting for your app.
Estimating how much the app will cost is complicated. There are a couple of ways to think about it and here is my honest advice based on our own experiences at Symph.
Fixed Cost
This seems like a good option, you provide the job details and then the design and development team will provide you an estimate based on what you provide.
The pro of this approach is that you know how much it will cost so you should be able to budget for it pretty easily.
The con of this approach is that things come up along the way; this inevitably results to changes in the original idea — for the better or worse depending on how much you can afford it to.
Here’s a secret: we, development and design teams, have monthly fixed costs, and when a project drags on because of additional scope or multiple adjustments, we want to quickly finish these project as soon as possible. Otherwise, our costs would go up, and the project will become a loss instead of a profit.
This makes us rush things. Rushing is not good. Important details get missed, and the quality suffers.
I don’t think any team, especially mine, would want to build apps in a rush. We want to build products that people love — and that would mean the best quality in all aspects possible. With a fixed price and deadline, it becomes difficult to accommodate the necessary changes in the scope.
However, sometimes having a fixed scope isn’t that difficult or detrimental to the project. Brochure websites are the best fit for the fixed price model. This model also works best for people who are very detail oriented, meaning they have thoroughly created their wireframes and user stories, not just ‘we want an app and here’s the idea of it, how much do you think it costs’ approach.
Even then, there will always be errors in estimation — so you and your design and development partner should clearly define how to handle these changes.
A fixed price and deadline model is based on the idea that once the design and development is finished, the work is done. That is never true. In reality, the launch is just the beginning of your app.
Lastly, if you still insist on this type of arrangement, you should consider this very carefully: You will likely need more design and development work after launching because if you are successful (and serious about it), you will have actual users who will use your product and will want more features, a better UI/UX and much more.
This is ultimately why I don’t think a fixed-price model is successful for apps.
Time Based Pricing
This model works a little better than the fixed price. Send us a certain request and we bill you by the hours it would take to get it done.
Time Based Pricing model is ideal for: Existing applications that need App improvements, bug fixes, additional feature requests, and maintenance.
However, this can also lead to abuse if you have zero knowledge on knowing how many hours (or other measures of time) a certain feature should take. Basic web/app development knowledge is most helpful when you are up for this model.
Having complex features may also not work so well for time based pricing as providers typically underestimate the time something will actually take, or there isn’t a clear understanding on the level of detail that a feature requires.
The rule of thumb for providers is to get the team’s estimate, then multiply it by 2.5.
So, if something is estimated to take 10 days of work, the reality is likely that it will take 25. That variation is a big difference in the total billable hours if you are in this type of arrangement.
The goal for any client-provider partnership is to have a mutually beneficial relationship. And although time-based pricing is a step ahead of fixed pricing, the time based model still does not have a natural long-term incentive — which I believe is something that you want your design and development partner to have.
From Experience
Even with the ability to redefine scope and adjust the work plan and cost with our understanding clients, we found ourselves spending more time monitoring the change requests, making adjustments and re-estimating our timeline and discussing the cost ramifications. The back-and-forth communication and administrative overhead of this was distracting us from what we really wanted to do: build an app.
Likewise, these conversations are not the easiest as basically we are saying “No, you cannot change that, or if you insist on changing it that will cost you more.”
Adaptive Pricing
We’ve adapted a pricing model that we believe works better for apps than the previous mentioned approaches. It isn’t perfect, however one advantage is that this approach is primed to handle what happens after launch. As I mentioned above, that is when the real work begins!
The objective of this approach is to establish a pricing model that is fair to both parties involved and aligned with the successful outcome of the project.
So, how does the adaptive pricing model work?
We start by working with you to understand the problem and the solution that you are looking to build. We then work on outlining the big picture goals of the app, as well as the user stories of the app. Once we have enough information on the app, we provide an indicative estimate of how long we think the current scope will take and we present the proposed team structure that we would dedicate to the app.
Although this sounds similar to the fixed price estimate, the difference is key: these estimates are based around the current understanding of the work that the app requires, and are scheduled out in development sprints. Our pricing model is based on the actual work done, as measured in the development sprints.
As work commences, usually the following will occur:
some features and functionality will turn out to be not necessary (i.e. customer validation shows they don’t want that feature) and can be removed, other features and functionality that were not originally thought of or now thought of in greater detail will be added to the development. These will be removed or scheduled on the future development timeline and overall the app will adapt to what the market actually wants.
Our typical team for an app is composed of: an app designer, a backend developer and a business developer (add a mobile developer if this is an Android or iOS app).We will quote prices on a sprint timeline schedule (either weekly or monthly). We also provide a breakdown of the level of effort per section of work, as this is then our guide to handle modifications to the scope.
We’ve found this hybrid pricing model is more effective at allowing both parties to focus on the main thing, respectively.
Focusing on the main thing enables us to develop a solution that people will love to use and that is actually what you want. You are also able to focus on moving the app idea forward.
Understanding The Principle
Forecasting for change is very difficult. It’s difficult in businesses, and it is notably difficult in technical development. However, change is constant as you develop an app, test it with the market and then iterate to build something they actually want — something that people will pay for.
It is crucial that you understand this principle prior to starting an app project. Equally important, you need to find a design and development partner who understands this principle and is willing to help you discover the right solution. Your partner should also value the engagement not just in the short-term but also be incentivized to build for the long-term success of your app.
Symph is a company incubating its own homegrown startups while also building awesome things to make the world a better place. Think we could be your ideal technical partner? Send us an e-mail at info@sym.ph and say “Hi!”.
