There are a number of payment models for app development. In this article, we are going to look at full payment terms. We’ll look at joint ventures elsewhere.
First the good news: You’ll never have to pay 100% upfront for your app development. If you are being asked to, walk away from that developer. Unless they have discovered you have a terrible credit score…
Developers need to protect themselves, so it’s understandable they want to see some financial commitment from you, not just a signature on a contract.
Less good news: Many developers will try and force you to agree to payment terms that are more to do with their cashflow than encouraging them to do a good job, on time, on terms that are comfortable for your bank account.
Don’t let this put you off. We are here to show you payment structures that will work for both the developer and for you so that you can both enjoy a productive project without money getting in the way of your relationship.
Very few developers will work without some kind of upfront payment.
Those that do should have their motives questioned as it smacks of desperation if a developer is prepared to do something outside the normal terms of business.
Most developers seek around 25-40% deposit. Depending on their rates and overheads, this typically equates, either partially or wholly, to their staff costs for the projects. They know by getting this amount up front, if something happens to your business and you can’t pay, they have their most expensive costs covered.
Some developers may ask for 50% up front, and you may choose to accept this if you don’t have to pay another payment until the project is finished and signed off. This way, you are both sharing the risk equally.
Most development projects are paid on a milestone basis – when key points in the project’s production plan have been reached.
Despite all of the talk and enthusiasm for Agile, many mobile app projects are still built in the linear Waterfall methodology. This is because while Agile is great for large teams with ongoing feature iteration, for smaller projects once you have the requirements for the development captured the team knows exactly what to build and how long it will take. There is less of the ‘build and see what happens’ aspect of development, for which Agile is great.
The truth is you want your development plan pinned down from day one so you know exactly what your costs and timeline will be. The best way to do that starts with an App Development Briefing.
If the developer insists on using Agile, there is nothing wrong with that, and indeed it will be better than Waterfall because you will get to see and test the app product sooner than Waterfall. What you need to be clear on however is that the spec is the spec, whichever way the developer builds it, and that you will pay for the app based on the spec, not how many attempts the developer needs or takes to get it right.
At this point, a good development team will understand the importance of understanding the project from day one, and they will insist on a thorough briefing, which is where our template becomes your best friend.
Step-by-step, it will take you through everything you need to tell the developer so that they can give you an accurate price estimate and then go on to develop a realistic project and timing plan.
A typical Waterfall project payment agreement would look like this
1. 40% deposit to initiate the project
2. 40% payable when the developer provides you with the app to test (User Acceptance Testing, UAT)
3. 20% payable when the project is complete.
A typical Agile project payment plan, accommodating six sprints, would look like this:
1. 25% deposit to initiate the project
2. 6 x 10% payments payable at the completion of each sprint
3. 10% payable when the project is handed over for final testing (UAT)
4. 5% payable when the project is complete.
Aside from the deposit, the payment terms are normally negotiable but typically anywhere from 14 to 30 days.
Date based payments
Sometimes, mainly with long-running projects, instead of milestones based on work produced, a developer and client will agree on time-related payments, usually monthly.
These payments are more common on very large projects where the developer has to employ a large software and testing team. The advantage for the developer is they can manage their overheads and cash flow more easily.
The disadvantage to you is that, unless there are other incentives for the developer to deliver the project on time (such as penalty payments for late delivery), timings can start to slip as the developer knows they are going to get paid anyway.
Sales and other taxes
Depending on your state or country there may be a sales or value-added (VAT) amount that needs to be paid. Make sure you understand whether the costs/pricing of the contract agreement (and any estimates) have these taxes included or excluded. In the UK for example, VAT registered developers will nearly always quote excluding VAT (as it is recoverable by VAT Registered customers).
If you are a big business, you may be able to dictate the speed at which you pay. Most developers are used to 30 days payment terms (it does differ country to country) but if you are a very large international company the developer, if they are a reasonable size, will accept 60 or even 90 days payment terms.
If you are a small company or an entrepreneur, don’t be offended if the developer insists on payment of the deposit up front. They are doing this because the risks of working with you are far higher.
Getting the best terms
Elsewhere we have discussed the importance of the client and developer having an equal relationship.
If you are going to insist, say on a lower deposit level than the developer would normally require, give them something in return for their taking on more risk. This might be to make an interim payment during a long Waterfall iteration period or to make a high percentage payment on the first Agile sprint delivery.
Usually, though, it’s best to go with the developer’s normal development terms. Good development teams will have done enough projects to know what works for both them and the customer.
The question is, how do you know the developer you are considering hiring is a good one?
As always, our App Project Briefing form will help you weed out the poor developers from the great ones.