Home > About Me, Essays > Why I Don’t Negotiate on Price (and Why That’s Good News)

Why I Don’t Negotiate on Price (and Why That’s Good News)

I recently quoted $250 in response to a client with a particular feature request.  The reply I got was asking if I could add this feature for $125, citing perfectly good and valid reasons of it not seeming like that much and a desire to keep costs down.

Here is my exact reply:


Whenever I let a client name the price I turn into a poor businessman indeed, and it puts me on a slippery slope of devalued self worth trying to please clients who will nickel-and-dime me and don’t really value my time.  Most damaging is that it tends to prevent me from doing the great and interesting things with my talents that I’m committed to doing in this lifetime.

Poetic waxing aside, I have a LOT of real world data that the price I charge for the value I provide is above-average fair and, relative to other vendors, sometimes ridiculously cheap.

Now then on this particular price, I’m not hosing you to make a couple extra bucks as though I were a shoe-in for the work: between transitioning mentally from other projects, sorting out your request, pre-pondering the best solution, doing the coding (which I reckon is what you figure should cost $125, and reasonably so), testing it, launching it, testing it live, being generous with any tweaks/enhancements you might request (has it been your experience that I’m fairly generous with these?  It is my aim that it has, and please let me know if I’ve fallen short!), and the sliver of added complexity that it entails for future maintenance/trouble shooting, I stand by my estimate of 2 hours.

(A common alternative to this is quick, get-er-done style work where one change breaks something else, perhaps familiar to you! :)

That said, you might have noticed that a lot of items in the list of things above represent the overhead of doing a non-trivial amount of work of ANY size, and you would be right to think that that sort of overhead is roughly constant no matter how much substantial work is to be done.  I do my best to have evolving and tweaking a system be as fast, easy and painless as possible (and I understand I do pretty darn good at it relative to my industry), but the general rule still always holds: that we’ll both always get a better value for our time and money the more you can batch feature and change requests together (a full day’s work in my experience is generally the tipping point).

Whatever you think for this one is totally cool by me.  If the day ever comes that you want to transition from me for any reason, be it price or whatever (or in the event that I need to move on myself) I am completely reliable to be 100% cool and helpful in facilitating that transition.  I’ll even train the next guy on the code and be available for quick questions (in the past for clients I really liked I’ve even done this training for free).  I’m committed that you NEVER have the experience that you’re stuck with me when you could do better.

Whew, that’s lot!  I didn’t mean to talk your ear off with the above, and know that I don’t mind your request at all.  Hopefully you’ve gotten some nuggets on how to get the best bang for your buck out of me.


Looking back there are a lot of things about this communication that I like.  It is a candid look at how I work with and honor my client relationships that I am happy to share publicly: it gives some insight as to how to get the best value of out me, reveals that a lock-in is NOT part of my business model, and gives the freedom to choose.  Negotiation-wise there are a lot of points made and I want to add a few more to round out the exposé of my thoughts on the matter.

My stance on not negotiating price serves both me and my clients because it keeps me honest and true to my standards.  Coupled with my willingness to facilitate anyone in transitioning to another developer, it holds me to a standard of being the best and giving the grade-A experience of working with me. If I don’t perform at the level I say I do and thereby someone can get a better value with someone else, I will lose that business and I should.  Short-cut jobs with me are simply not on the table, though the option to get one somewhere else is.

Psychological factors play into it as well.  When I know I’ll be earning what I feel I’m worth for a piece of work, it’s easy and a joy to put the shine on it and go the extra mile, and my clients regularly reap the benefit of this.  By contrast, in the past when I’ve allowed myself to get beat up on price I had to fight against the devil on my shoulder telling me that just meeting the spec-doc minimums was acceptable.  I always won, but those then were the clients I eventually fired.

If nothing else, not negotiating on price forces me to work with the right clients.  For a mom-and-pop business looking to get a website online, I’m expensive.  For a million-dollar company for which custom software is an integral part, I’m cheap.  In some cases ridiculously cheap.  So if I’m getting push back on my price, it’s a sign that we’re not a good fit, and acknowledging that sooner than later is useful for both of us.

And in case you were wondering, my rate of $250 was accepted via email reply 14 minutes later.


This is Programmer for Hire, a series of essays and explorations on the art of being a great programmer doing on-demand custom software development.

  1. Proof & Testing Police
    January 3rd, 2014 at 01:14 | #1

    I’m impressed by what you say about your skills and ethics, and your opinions often match mine. I, too, am a quality-obsessed perfectionist with abilities to cover the full SDLC AND the documentation and training most programmers don’t want to do or can’t do.

    I’ve always liked to think that my attention to quality proves itself in ALL the work I do–in writing in English as well as in computer languages–and so *I* proofread and correct my “communications”, documentation, etc., just like I proof and correct my code. And I NEVER release it without full review and testing.

    Your essays, while generally excellent in content, are so full of typos that it undermines your claim of being a programmer without peer. Please make it easier on your readers, and do yourself the favor of removing evidence of sloppiness in your work: proofread and correct your articles! (In the future…BEFORE they are released!)

    • John
      January 3rd, 2014 at 09:38 | #2

      Wow, fuck me, you’re right! Nearly 3 years after writing this, now giving it a careful read I found 5 typos quite ripe for correcting in this post alone.

      I generally re-read essays 2-3 times and make corrections before hitting publish, so what you see is I suppose about as good as I do with that model (it probably doesn’t help that I do this in the same span of time as writing it, so the eyes start to glaze over passages that are by then already so familiar). This particular one may be a little more rough because the email reply was pasted verbatim in the interest of authenticity.

      I don’t know that I’ll go through the whole of this blog for such word policing anytime soon, so it may have to trundle along, warts-and-all for a bit longer. Still, I’m all for this writing going down more smoothly for readers, so thanks for the heads up!

  1. No trackbacks yet.