What’s wrong with billable hours • Hacker News Board

Re: What’s wrong with billable hours

#91

Post by ghaff » Tue, Sep 05, 2023, 6:02 PM UTC

calvinmorrison wrote: post #16

the_af wrote: post #6

Well, I found this article insightful, even if I've no plans of going freelancer (though of course... "life, uh, finds a way", so who knows). I think my most immediate objection is one that is raised in the comments from TFA: customers don't know what they want. For a flat rate to apply, you have to work to an initial set of requirements set in stone, and we know these requirements are almost always wrong (except for…

Then you finally do all the research and they reject your quote. The most valuable part of my job is typically the engineering or architecting not writing the code. Depending on the client we do T&M or quotes but we never do free research. Well do a short proposal to quote you a big proposal

>Well do a short proposal to quote you a big proposal

Did that for a pretty large client project once. Basically brainstormed/did some research to pick out some technology areas they might be interested in and why. Then did a bigger project to dive deeper into areas, conduct interviews, etc. that resonated with them.

Re: What’s wrong with billable hours

#92

Post by leepowers » Tue, Sep 05, 2023, 6:03 PM UTC

mk_stjames wrote: post #48

One thing I've noticed more now that I read HN more than other places... Software people sure like to talk/write a lot of about their business. Like, a lot. I'm a mechanical/aerospace engineer, and I've done some short term consulting for startups (but now mostly retired). There is verrry little online in the form of blog posts like this mulling over how people work in that type of engineering (especially in the high…

In this particular case the author is using a controversial headline to drum up attention for his business, which he plugs about 2/3rds of a way through the article. I think web developers in particular are more familiar with SEO and web-based sales and are more likely to write about software in an attempt to funnel eyeballs towards their software business ventures.

Re: What’s wrong with billable hours

#93

Post by TuringNYC » Tue, Sep 05, 2023, 6:05 PM UTC

Some clients are absolute pains with flat costs. They argue over scope, then argue over the definition of done, then they argue over features that were not in scope and refuse to pay you until you do them (for free.)

For these "special" clients, I found the best model to be a pre-paid declining balance retainer. Nothing gives more focus to clients than a slowly ticking meter. Further, i'd set the rate to be something that is worth even bothering with such clients.

Re: What’s wrong with billable hours

#94

Post by LaundroMat » Tue, Sep 05, 2023, 6:08 PM UTC

poulsbohemian wrote: post #47

chrisoconnell wrote: post #41

Earlier quoted context omitted.

Have you considered a monthly retainer with an hour cap? This prevents you from being treated like a salaried employee, maintains your work life balance, and ensures the client is still providing solid requirements and thinking through their ideas. We have found a lot of great success with this model, and our clients respect it. It ensure we can have multiple clients, without one taking up all of our time, and taking…

At this point in life, I've moved on to a new field altogether, but some of the ideas you are sharing above are exactly the types of models I experimented with.

What did you learn from these experiments?

Re: What’s wrong with billable hours

#95

Post by swader999 » Tue, Sep 05, 2023, 6:11 PM UTC

poulsbohemian wrote: post #35

ChristopherM wrote: post #15

I charge by the hour and will never change. It forces the customer to focus on getting the requirements right instead of hand waving it like "oh yeah, that's just what I want" and then come back later "I didn't want that, what I meant was" repeat ad infinitum. You see they are paying for my time, not results. If they choose to waste it... doesn't matter to me, it's all billable just the same. I will do my best to ste…

Here's the challenge I ran into, so I'm curious how you handle it... If you bill by the hour, first they fight you over the hourly rate. Then they want to argue over how many hours it will take to do the work. Then they want to argue over you billing them for all the project management and planning hours you are spending with them, they only want you to bill them for "the work." Then when they get the bill they want…

In fifteen years of contracting, 20+ clients , I've never had issues or questions about my hours. All software project based work on projects that span months to at most two years.

Up front, the hourly rate is agreed to, the expectation that I typically bill forty hours a week is set, we agree that overtime is only undertaken with written permission. I tell them I don't bill for lunch or breaks and that if they can't provide me with work to do, I still bill but that I inform them persistently when undertasked.

I only estimate work by giving complexity numbers. They all ask well how long does that take??? I say over the last x months, my average complexity points accepted in production is y points per two week period. So expect this five pointer to be done in a week plus or minus two days.

Do you need a better estimate? Then it will cost you two unproductive days for me to fully spec out the work and I'll need three hours of your time for this feature to give you an estimate that has a tighter variance.

This is the way it's done folks. I know what I make, I can easily have a life, wife, family. Companies make sure they have me work on most important things first and they end my project when they feel it does enough of what they need it to do.

I'm visible, I show real progress frequently and they get value out of released features early on and continuously throughout the engagement.

Sometimes I lower my rate for equity, people I enjoy working with, working on tech or a business domain that interests me. I'll of course raise it for the opposite.

In the fifteen years I've had three weeks in 2008 where I couldn't find work. I've billed between 95-155/hr CAD. Mostly enterprise custom applications. Billing systems, engineering process systems, banking apps, trading apps. Typically lead dev roles. Working in a Canadian city or remotely for USA companies. C#, ruby, scala, python. Not a great programmer, I'd get laughed out of the room on a leet code exercise but I've repeatedly delivered projects and systems where the previous teams have failed. There's only been a few of the 20+ projects that haven't been rescues.

Re: What’s wrong with billable hours

#96

Post by gizmo686 » Tue, Sep 05, 2023, 6:17 PM UTC

Aurornis wrote: post #53

ddkto wrote: post #9

Professional business people are familiar with different business models, and when to apply them. For instance, hourly billing makes a lot of sense if the scope is vague - the client carries the scope risk. Fixed price is amazing when the client has a specific, measurable problem that they don’t know how to fix (but you do). You can solve it cheaply, get paid waaay more than hourly and have a happy client. Being a pr…

> Fixed price is amazing when the client has a specific, measurable problem that they don’t know how to fix (but you do). You can solve it cheaply, get paid waaay more than hourly and have a happy client. What about fixed price makes the client happy in this situation? It's definitely not the fact that the contractor billed "waaay more than hourly". The upside of fixed price is that it's more predictable and it align…

Is it "inflating the bid" or "charging a premium for fixed cost".

You are welcome to haggle on price or not hire them. As a freelancer or bussiness owner, not every prospective bussiness deal goes through. That is not a failure of their model, just the realities of commerce.

Re: What’s wrong with billable hours

#97

Post by dalore » Tue, Sep 05, 2023, 6:23 PM UTC

This doesn't account that software is (relatively) easy to change, vs say building a house (to use a cliche). The client will want to see it as it progresses, and then change based on what they have learned is possible. This is the agile way.

How would one account for a fixed cost then? Do you say ok it's a fixed cost, and you get 6months base on our estimate (but if the 6months has finished the contract ends, and isn't that just a time based project). Or do you tell the client no changes after the initial requirements (which doesn't sound flexible and you end up building something the client doesn't want)?

Re: What’s wrong with billable hours

#98

Post by swader999 » Tue, Sep 05, 2023, 6:26 PM UTC

tptacek wrote: post #83

swader999 wrote: post #76

Earlier quoted context omitted.

How do you deal with clients that perceive and expect to have you available and working more than eight hours a day? What do you do about when your not immediately answering during lunch etc. What do you do about days where you detect l weren't fully engaged by the client for a full eight hours?

Don't set that expectation. Don't work with clients that expect you to track hours when you bill days. The threshold for productivity and exclusivity I've had has been "if I billed you for a day, I'm not going to bill work for anybody else in that day"; that's as far as I go. In 15 years of doing this kind of work ('05-'20) I never had a problem --- but we did bail on RFPs where clients made it clear they'd be lookin…

I've never had to fix bid for work, always had hourly gigs in the wings. I hold the philosophy that sw dev is a product development, iterative exercise, not a construction metaphor that is predictable.

Yeah, I expect you would be able to do the same if you billed hourly. If a client insisted I bill daily, I'd probably have no issue with it either. It's just so rare to bill daily in my circles that I've never considered it, I'm often rebilled by my client to their end customers for specific features so they need hourly tallies to pass on.

Re: What’s wrong with billable hours

#99

Post by poulsbohemian » Tue, Sep 05, 2023, 6:26 PM UTC

LaundroMat wrote: post #94

poulsbohemian wrote: post #47

Earlier quoted context omitted.

At this point in life, I've moved on to a new field altogether, but some of the ideas you are sharing above are exactly the types of models I experimented with.

What did you learn from these experiments?

A number of years ago, the term "F*ck you, pay me" was going around in popular vernacular. That jives with my own experiences - ask for deposits up front, make payment net-15, tack on a giant fee in the event of slow / failure to pay, and make sure your contracts are written so that the client pays legal bills in the event you have to sue. Create contract disincentives to encourage good behavior. Keep your rates high and don't give anyone a deal. Be willing to say no both to prospective clients as well as individual projects - even with good clients.

Re: What’s wrong with billable hours

#100

Post by atoav » Tue, Sep 05, 2023, 6:27 PM UTC

the_af wrote: post #27

atoav wrote: post #14

Earlier quoted context omitted.

As a freelancer I always told my customers how many hours I plan to work for them, including a rough overview of how much time we use at which phase of the project and what is expected of them. And I do that before I agree to work for them.

Interesting. Wouldn't that require a firm understanding of the project scope and a steady hand at rejecting any attempts at feature creep or redefining the scope (with the politeness required for not losing them as customers)? In other words, wouldn't this scoping and pre-planning go against the latest findings of lowercase agile?

That depends entirely on the type of projects you are known for (read: are willing to take). Some software projects agreeably will be next to impossible to estimate, others not so much.

That being said I always bill per day of work, rarely ever a fixed sum (in fact only for good friends that are poor artists). So if the scope changes and there are more days, they know my rate and it will be their decision if they want to pay for that. Also they will have the insecurity of me not having time because I work on other things — risks that I clearly communicate before they agree to have me.

I expect a certain amount of changes and feiction that is included in my original estimate, so this "extension" period is rarely ever needed and when I am faster the customer has to pay less than they expected which typically makes them happy.

It doesn't always work that flawlessly, but it was never catastrophic and my customers value the up-front clarity.