Shopping Cart

How to get the best deal from a developer

How to get the best deal from a developer

by Daniel Sim

Good developers are expensive: so are cars. Haggling with your car dealer won't leave you with a worse vehicle, but haggling with a developer can have some unpleasant consequences for both of you.

Who doesn't want to get a great deal on what we buy? And for a business where development is a large chunk of expenses it's smart to try to save money here.

Remember though that instead of a car you're buying the time, focus and dedication of a skilled person who needs to apply their mind and creativity to your project. The money you compensate them with affects all of that.

The Foundation: Trust

A bad client can make a developer's life hell. Think micromanagement / changing requirements / just one more thing / late payment / unresponsive to questions / email barrage. These things are unfortunately not uncommon.

If a developer detects the possibility of any of these things when they first talk to you, they'll either walk away or hike up their price to tax bad clients. Your job is to build trust that you're going to be a good client to work with.

When a developer knows they'll be happy to work with you you'll avoid the bad client tax. A good way to establish trust is to pick a short, well-defined initial project (paid of course) to work together on.

Familiarity with the language and platform

There are a tonne of software languages and platforms. No developer can know all of them! It's tempting for a developer, especially one in a dry spell, to go for projects in a language they haven't used before.

Good developers constantly update their skills as the field moves forward, so this isn't unusual.

You'll be paying for the bottom of their learning curve if they haven't used your platform before. For a permanent role this is much less of a problem than getting the right person, but if you're paying hourly they will be less productive initially than a platform expert.

If you're paying by the task/project their estimate will likely be wrong. It'll be too either high, as they've priced in learning and setup of this new platform, or too low, as they've underestimated the work involved. While it may seem pricing too low is good for you- beware that this is the model situation where your project is deprioritized vs. other better priced clients.

When hiring non-fulltime developers prefer those who've worked with your software and platform before.

Intellectual curiosity

New frameworks, platforms and language versions come out constantly. This means there's also a software graveyard of old and stale things to work with. If you employ old and stale software it's going to cost you more to hire: both as the pool of people familiar with it is smaller and the fact that no-one wants to work on it anymore.

Then we have established technology. It's been around for at least a year or two and is used widely. Widely used software equals lots of talent to draw from.

At the other end of the timeline are new and shiny things. Risky because not many people are using them yet to iron out the bugs, and that they may disappear just as quickly as they came!

Software development can also be boring and mundane, routine, or very challenging and complex.

To get the best deal on development you should to be mostly using established technology with routine tasks. Seems obvious, right? However there's a nice hack here that can get you a great deal on above average developers.

These developers are intellectually curious, so if you can offer them an opportunity to work with new and shiny and/or very challenging and complex things you can hook them vs. an old and stale, boring and mundane client.

They will often also price themselves lower than usual to get the opportunity of winning the work. Money is not a primary motivator for them as they know they can command high rates, they want to challenge themselves and add interesting things to their portfolio.

Working conditions

Setting up a computer for software development isn't like unwrapping your new iPad and adding a 'develop software' app from the App Store! It's much more like starting with an empty living room and furnishing it until it's just right.

They've got everything just right on their machine so that they can be as comfortable and as productive as possible. That's a great benefit for you. So over specifying things like the machine, tools, method and process they need to use to build software is at best going to slow them down, introduce mistakes and cost you more.

As we covered earlier, trust is the foundation of your relationship. If you don't trust your developer- get a new one. Specifying things like using screen recording software or that they be instantly available during working hours on skype/slack/email makes your developer feel they aren't trusted. Trustworthy developers will balk at being tracked and micromanaged like this: lower productivity/focus equals more expensive projects.

Haggle their rates

Or rather, don't. When a developer gives you a price it's tempting to view this as the starting point of a negotiation. But most developers aren't adept at negotiation, so it's more like 'this is what I think I'm worth'. You can see where this goes if you use the tried-and-tested lowball offer haggling technique here: a developer feeling undervalued and less engaged with you.

Similarly if you collect quotes from several developers and then try to pitch them off against each other it's probably going to end in a mess.

All's not lost. There are certain things that you can do to increase the value of your project for a developer, leading them to give you a better deal.

Long term commitment. If you can offer a set number of hours over a certain period of time this becomes more valuable to a freelancer's often choppy schedule. If it's significant enough they'll reward you with keener pricing.

Remove the fat. If you're going for a fixed-price project your developer will have priced risk into the quote. Identify this risk with them and reduce it.

Deploy resources efficiently. You don't want a $100/hour developer doing things your $30/hour assistant can do. For both fixed price and hourly projects identify opportunities like this and put the right people on the right tasks.

Align your goals. What goals does your developer have? Do they want to learn a new language, contribute to an open source project or build a generic app. If you can bend your requirements to accommodate this then there's an opportunity for their rate to be adjusted too.

Repeat and refine

Developers are not easily fungible. Build your relationship over time in line with the techniques we've shown in this guide and you're going to get a great deal on development work: much better than trying to shave $5/hour off of the rate.


Older Post