[devs1010]

In my opinion, the concept of paying per hour is one of the biggest fallacies in software development. I am salaried but I don't get paid based on hours worked, I have deliverables that I meet, its irrelevant how much time is spent on meeting those and is impossible to quantify because often the hardest problems are solved in my head when doing something else, could be when stepping out of the office to go for a walk or while on the commute home, etc. We are paid to use our brains and this does not correlate directly with the traditional concept of billing for time. Also,things I do outside of work often positively benefit me, such as working on a side project or reading a book about new programming styles / concepts, however this would never be considered to be "billable hours".

Its my goal to one day work on a per-project basis, I haven't quite figured out how to make a go of this yet, however I really think this is how most software should be done for anyone with a few years experience under their belt. Working software is valuable and if you can commit to something and deliver, the concept of time should be immaterial (outside of meeting a deadline)... its all about value delivered. By tying ourselves to hourly billing rates, I think software development as a profession is held back and part of the reason it may not be as well respected as it should be by "business" people. It takes standing up and proclaiming the value that you bring every now and then to make people realize this isn't an assembly line type of job and never will be.

[ErrantX]

I've recently been experimenting with this; it can be dangerous for you (read on) but if well managed it can be more flexible for both you and the client.

For a long time I've been playing around with how I charge; a few weeks ago we had a discussion r.e. hourly vs. daily rates (I prefer the former, as it works best for me).

But in the last ~2 months I've been working on ways to charge on a target basis. Or to put it another way; I agree a schedule with my client, and they pay as I reach each milestone.

This takes time almost entirely out of the negotiation.

It has other benefits too; for example it forces the client to work on a formal specification (as an engineer, this is crucial!) for a project.

I have flexibility on how I reach the goals we agree - I might give a deadline estimate (two weeks for milestone 1, a further week for milestone 2). Whether I do the work on a Monday, or part of Weds and Fri, is irrelevant to them. And so I have the flexibility to schedule all of my work as is convenient.

Internally I am figuring out that it requires X hours work for each milestone - but the client never sees this, they just see my quoted figure and the delivery date. But I have found that this way I can up my rates significantly - I suspect because clients are measuring cost in terms of deliverables, rather than hourly or daily rate.

I spent a lot of time working up my rate from £40/hr (three years ago) to £100/hr through various mechanisms. But I have struggled to breach that barrier for a while now. My ultimate aim is £200/hr (which, as a full-stack engineer with years of experience & happy clients, is what I think my time is worth). This new method is currently "testing" at around £120/hr and I am slowly increasing it, without issue so far.

This also helps for existing clients too; if you start working with someone at £40/hr it's hard to build your rate up significantly without putting them off [I lost a very solid client on the jump from £60 - £100]. But if clients don't know your rates, upping them by £10/hr will be much less visible, and they only have to judge whether the total cost is worth the outcome.

So, I think I would be happy in saying - your theory is sound, and seems to be working out for me in practice :)

[devs1010]

Thanks for the reply, its encouraging that you have been able to keep growing your rate. I have only a few years experience but have crammed a lot into that time period so am hoping to get out more on my own going forward and the idea of being paid for milestones is appealing. I think its always hard to convince someone to pay you more when they have been paying you one rate. For me, there have even been situations where I was an contracted hourly rate employee, quit that position for a higher paying job and then they still asked me to do some side work at my old rate. In this industry, employers will almost always try to take advantage no matter what value you are creating so I think more developers need to learn the business side to get fair compensation.

[btilly]

When clients pay for value delivered rather than effort spent, they are willing to pay more because they have less risk and have no need to worry that you're padding your hours.