Skip to content

Six ways to be a better client for your developer – Point 5

Dear Reader,

Point 1 – Understand that you alone know the problem
Point 2 – Understand that they probably know the best solution
Point 3 – Don’t be sold a solution
Point 4 – Don’t set a deadline, set milestones

Are you a good client for your freelance programmer? I hear both sides of this conversation from different friends. Freelancers complain that clients and potential clients just don’t have a clue. They feel the need to figure out what the client needs instead of listening to what the client wants. Clients complain that no matter how much they explain what they want, the developer is rarely listening and is usually just waiting to speak.

For the purposes of this article series, I will use the word developer when I mean freelance developer, internal development team or external development company. Most of these points apply to all three.

Know your budget

Let your developer know up front how much you have to spend, don’t make them guess. They know what they can build projects for and letting them know up front helps them decide what tools to use and even whether they can afford to take the project or not.

After you give them your budget, but before you commit to the project, ask your developer for references, and then check them. When you talk to the references, ask how close the final bill came to the original estimate. If you get wildly varying numbers then that is a red flag that the developer has trouble estimating. Make sure your developer gives you both an estimate and a maximum charge guarantee. Make them guarantee in writing that the project will cost no more than $XX where $XX is usually 10%-20% over the estimate.

Know this though, once they have guaranteed that price, you can’t make changes. No “We saw this yesterday and want you to add it in.” or anything of the sort. If you are making them live within a specific budget then you have to live with the agreed upon solution, period, no exceptions, ever.

A good developer will refuse even small changes once the contract has been agreed upon and instead quote you each change as a separate request. This gives you the power because you can then weigh the request against it’s impact on the budget and timeline (it WILL impact both) and decide whether or not a request is worth it. This is not your developer being “money grubbing thieves” as I’ve heard it put. This is them protecting your budget, schedule and their reputation. If your developer concedes to an endless list of what you think are small changes, this should be a red flag. Either they don’t understand the impact of the changes on the project or they grossly over chaged you to pad the budget for these changes. Both are signs of a lack of professionalism.

Honor their refusal to make changes and respect it for what it is, professionalism.

Until next time,
I <3 |<
=C=