How not to negotiate your app development contract
There are several ways of negotiating a contract. Mobile first startups today find themselves in a unique place. They cannot work with app development teams the way enterprises outsourced to IT firms in the 90s. And so negotiations over contracts take a different meaning here.
App development teams in the market price themselves differently and have different expectations from their customers before agreeing to do a project. Let’s take an example here. To a team that bills $25/hr for overseas customers and comes down to $22/hr for a local one, someone who expects to pay $18/hr is simply not worth speaking to.
Negotiations here should be looked as a way of getting both sides to fully understand the granular details about the product and the effort required to build it. Custom app development takes time and hard work. It cannot be equated with buying a set of items in bulk and that’s why negotiating an app development contract can’t be done in the same manner.
Budget. “My team built all the features we wanted for the budget we had!”, said no bootstrapped startup ever. At some point, all product owners wanted more than what they needed and could afford. Be ready to get quotes that will be outside the budget and try to understand why the team has budgeted the project in such a way. All custom app projects are priced according to the effort involved. So, it’s always a good idea to speak more than 1 team and even get inputs from other techies on the effort involved.
Effort. Every team would estimate the effort involved differently. A team with no relevant experience would keep a considerable buffer since they aren’t certain about the project’s complexity. This might come across as over-estimation. On the other hand, a team which has built a similar product would have a more accurate work and cost estimate.
Features. Products are not meant to do everything at first. Nobody would have understood what Facebook is if they had dumped all the features they have today on their users on day one. Prioritising the features and keeping only the essential ones in the scope would help you in a number of ways:
You would have more room to negotiate with a team.
You will have a clearer idea on what your product will do.
So, tracking the project to completion would be easier. It’s always tough to finish a clunky scope. Remember: products are meant to evolve over time.
Subsequent iterations leading to the next release would be more productive(A smart and successful lean startup!).
It’s usual to come across product owners bargaining hard with teams over features that may not even be the most important at the time. Even if they do somehow manage to get the teams to build it, the features may hardly even be used by customers.
The market rewards those who fail first and adapt according to what customers currently need. Making sure that the first build performs all the essential features well is crucial. Negotiations here are not about getting your app made for the cheapest cost with promises of all the features that a product owner envisions. It’s about working with a team that can help you build a world-class product, scale it, and in some cases even help you build your in-house team over a period of time.
Pravir Ramasundaram is our in-house content writer here at ContractIQ. Keep coming back to read more of his articles on mobility & outsourcing.