Silent Running?

Wednesday 10th July, 2013

For small developers, meeting a new client for the first time is always a fun and educational experience. Every business is different, and you can get a good idea of what’s important to them from the questions they ask you.

But every first meeting has one thing in common: the initial question they ask is not the question they want answered - “How much is this going to cost me?” So, let me answer that question right now, without any more prevarication.

Dyce & Sons charge a flat £50+VAT per hour, with a maximum of £500+VAT per day.

Developers I’ve talked to about this were surprised that we’re publishing a specific figure. Other developers reading this might be surprised at the figure itself (for differing reasons), but I suspect the majority will be surprised simply at the fact of it. Customer pricing seems to be a closely guarded secret. Some small developers don’t want to price themselves out of a job, and like to hedge. Some like to offer a fixed price, once a spec has been written. Some change the price depending on the size of client. Each approach has it’s pros and cons, but after more than 20 years in the business, I believe a flat rate is the simplest method, and in both parties' interest, for a number of reasons.

Don’t ask, don’t tell

Developers who won’t tell you their price up front may playing one of two games which in the extreme might be characterised as “I’m desperate for the work, so don’t want to frighten the client”, or “I can’t figure out how hard I can squeeze before the pips squeak”. Which tells you that the developer is thinking about the money, and not the job.

Let the wookie win

Others get a really tight spec, and figure out exactly how long the job will take, and then give out a fixed price. This never works out well, for either party. Unless its a really small job, or the developer has already done exactly the same job for someone else, there is no way they can price the job accurately enough. Either they’ll cut corners to save being screwed by the customer, or they’ll take the hit and mutter soto voce, or (more likely) the customer will be paying more than they need to. And in each case the end product will be compromised: a poorer user interface than it should have, a grumpy developer who didn’t honestly do their best work, or a product that could have been better for the same money.

Cut the cloth

“Smaller customer equals economy price list” sounds fine, but it leads to ‘economy product’ type thinking (and think carefully about the converse.) A developer should be attempting to do their best work for every client. Having a different price structure based on company type or size also adds a subtle bias to a developer’s choice of job: which means less breadth of experience, and risks tying the developer into the one type of job cul-de-sac.

Keep more than a hammer in your toolbox

When you start to treat pricing as the ‘secret sauce’, the thing that means you’ll get the gig over the competition, then pretty soon, it becomes the only tool in the box. You should only do the jobs you want to do. This is not a rehearsal, and whatever your chromosomal makeup, there’s a limit to the number of jobs you can appear to do simultaneously. Using price to make a disagreeable job worthwhile enough to take on will only last so long. You will soon come to resent working on a job if the only reason you’re doing it is for the money, and you won’t be doing your best work.

So where’s the upside?

The benefits of fixed rate pricing are manifold, but two important ones come to mind: Once clients know have seen you in action, know how you work, and have an idea of how long it takes you to do stuff, they can start to price work for you. Or at least, make a rough stab at it in their own heads about how much it would cost to implement X feature, or remove Y inefficiency. They may be wrong, and you may surprise them (pleasantly) with your estimates. (Is the inverse relationship between how difficult the client thinks a feature is to implement and the reality of implementation a corollary of NP-completeness? Discuss.) Working with a small developer can be liberating experience for a business - bespoke software is not as expensive as they thought, and they can get things done just the way they want it - and being able have come up with a ballpark figure for costs often frees them to think of new ways of solving existing problems or instigating business efficiencies.

Fixed rate pricing coupled with the 80/20 rule also means that both developer and client get a chance to more clearly identify the arrival of diminishing returns - that point when doing another hour’s work is not going to be cost effective for the client, and less than entertaining for the developer. And therefore an easier way to segue into “err thanks, but can we stop now/do something more interesting instead?” This isn’t some “developers are all artists” manifesto or even the “all customers get the developers they deserve” aphorism.Honest pricing lets everyone know what the job is worth. As developers, if by some mutually agreed measure (time, worry, cash) you don’t save the customer more than what you cost, then you shouldn’t be able to sleep at night. [Hows this for synchronicity forcing one’s hand? I’ve had this post sitting in my drafts box for about two weeks, almost finished, when Cole Henley’s annual freelance web survey pinged into my inbox. If you’re interested in the state of things right now, at least for web designers (not database work sadly), take a look at this ]   [ I believe that the image is actually not from the film, but from the marvellous www.destinymodels.co.uk, who appear to share a similar taste to mine - need to persuade the wife to go for an eagle transporter… ]