What’s wrong with billable hours

I also don't compete, I'm not on any "freelancing" websites, I don't apply or bid for work. My clients always come to me, I get an email, a phone call asking if I'm available. So this race to the bottom nonsense is utter crap. I'm a consultant NOT a freelancer.

I've been doing this since 2011, that's the last time I had an employer. This year I'm on track to bill out between $360k and $400k. If that's "amateur" so bet it. Considering I have no debt, my house is paid for, my luxury SUV I paid cash for, my actual monthly bills are around $2,500 a month. I really couldn't care less what someone who writes an article like this thinks of me. The writer is advocating for the client, they aren't giving me advice that helps me. I also have no interest in scaling, on bringing on employees. I'm making bank, I left CA in 2013, currently live in Wyoming with a 40 minute drive to Park City UT and a 60 minute drive to Salt Lake City.

To anyone reading this article and thinking they are offering you helpful advice, consider their motive. What are they trying to sell you? Are they trying to change the current consulting landscape to benefit themselves as a business owner?

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 professional means having multiple tools in your toolbox and knowing how and when to use them. Drafting contracts is all about deciding how the risk will be shared - you need the right risk-sharing model for each situation.

(edit: spelling)

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 higher-end of the field, like what happens in automotive and military/commercial aerospace- it's all very closed-doors). Especially less in the methods/metas of the field and the business surrounding it.

But software people? HN is flooded everyday with long form exposition just like this blog post. And it's honestly been pretty eye opening reading how much people pontificate in this area. Like, goddamn. I'm starting to think people talk about their ways of work more hours of the day than they actually.... you know... work.

<< Just an observation; don't kill me. >>

I do a combination of fixed price and time and material work.

Sometimes fixed price is a good model, sometimes time and material is a good model.

Fixed price works when you know the scope, and are confident that there won’t be roadblocks and rabbit holes. If a project takes longer than you think, you are eating the difference.

There’s nothing wrong with charging per hour if you know the value of your hours. Charging by hours gives you a level of certainty regardless of scope change.

IMO the smart consultant/contractor will use both models, then pick the right one for the project and client.

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 very specific cases), so either your customers will try to do feature creep or they'll accept the initial specs and be disappointed, and probably blame this on you.

But in contrast to the name there is nothing fixed price about it. As a provider of such project deliveries, unless you truly are an 'amateur', you still are acounting cost plus if the project goes into overruns. The way you do this through 'change requests'.

You see, you can't nail down a contract taking into account every possible interpretation of details on a bespoke software project. So the customer will always need to clarify and adapt. This will be translated by your sales team into additional costs until a margin is met.

The only way out is using of the shelf product, and even then you will probably have an 'integration project'.

If you are happy about where you are in life and are making close to half a million dollars a year, like some on this thread, feel free to ignore his advice.

If you are stuck in the race to the bottom and wonder why, for example, the company's management doesn't pay attention to anything you say, then read his blog.

About 90%+ of the work you get from these companies is done by their junior employees, even if the senior partner that sold you swears otherwise

Especially if you are not one of their top clients

For most companies, it’s better to get a small firm or an individual. You’ll get better communication, better work and sometimes even better price

The whole article feels like asking GPT to add filler for the first 3 pages.

Working with a few customers as a freelancer, I agree, a lot of time they can't express what they actually want. They know it when they see it, but they can't express it correctly so you end up building a product, and having a thousand change requests - basically the customer uses you as a prototyping machine until you build what they want.

Obviously this can't work with fixed pricing, BUT this is where the point of the article comes in. If the only thing you can offer to your customer is writing code based on a requirement - you're racing to the bottom because thousands can write code based on a requirement.

BUT, if you focus on outcome - I will build you what you want, AND I'll help you figure out what that is!! That service will include asking the right questions, helping the client figure out what they want, and you can put all of that in your fixed price offer. At this point you aren't just writing code for them, you are their business partner, you want them to succeed, and you will use your experience to offer advice. If you become good at this, you are much more than just a programmer, or what the article calls "technician".

So, thanks for the article, I found it interesting and have some food for thought.

I work for a consultancy that works for some of the biggest investment funds in the world. We do some flat rate and we do some hourly. Sometimes hourly is exactly what the customer wants and is aligned with our interests. Sometimes it's not. I have also freelanced successfully with the same experience, and as a customer there are things I absolutely want hourly.

For example, discovery should always be hourly, or you screw it up by making discovery that leads to a no-go conclusion unlikely, even if no-go is the Right Thing. One of the best things I ever learned for consulting was how to do this - clients who have paid you a reasonable fee to discover that they are not ready to go ahead will be talking about your honestly and credibility to anyone who will listen. Managing when things should be hourly or not is a huge part of what builds credibility. Blanket statements about how one should never be trying to do hourly work reveal nothing but business ignorance.

As an hourly billing freelancer, my only reply to this article can only be “so what?”

Clients don't care about hours I spend, my hours bring no value to them. They desire a certain result, and they know how much that result is worth to them.

For my freelance tasks, I've put forth a rather steep one-time price for the solution of the specific problem at hand. The condition: The price is paid when the problem is solved, if not, the service was not delivered, they don't pay.

This works out beautifully for the client, they run no risk (except the delay in waiting for me to fail so they can try someone else), and they know exactly what they pay.

It works out nice for me, since I have a reasonable idea whether I can solve the problem or not.

Hourly rates for those tasks have been close to $1000, including failed tasks where I spent some days not solving the problem.

In the end, it's also very fair to both parties.. It's reasonable to expect the agreed-upon result when paying someone to do something.

It's also unreasonable to expect to get paid for not doing what was agreed upon.

A concrete example I can talk about was a client whose database had started "acting up a lot" and they had no idea what was wrong, they were very friendly and told me they had contacted another company too who had quoted an hourly price around $200 but were unwilling to estimate how much time they would need, since they didn't know what the problem was. So I said, "I'll try and fix it, if I succeed it'll be $4000", that's a fair amount of money, sure, but it was pretty good value to them to get their inventory database back up. It turned out to be an unhandled edge-case that only showed up years after when they introduced a new kind of item into the database. I had to learn a little bit of VBA(!) to fix it, but in the end, it took about 2 hours, and you might argue that price is too much for those two hours, but they didn't pay me to spend 2 hours, they paid me to get their database working again.

I don't share the perspective on hourly making someone a commodity. Fixed outcomes can also be commodities. Clients can and do shop around estimates for the best price. The race to the bottom exists whether you're billing by hour or by outcome. You avoid the race to the bottom by what you sell, not how you bill. Wordpress themes are mostly a race to the bottom, regardless of how you're billing.

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.

I feel like a retainer of sorts may make sense, but that seems a hard sell for some projects. "Make us this 5 page app that does XYZ". "Ok, pay me X/mo forever". Both consultant and client would need an exit that I'm not clear on. Also, to be honest about it, the consultant should limit their clients to some reasonable number so that they can serve them in reasonable time.

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)?

They ghosted me!

In retrospect, a "very large company" didn't reach out, a relatively junior person at the company did. I should have worked within their constraints. (Or just not taken the job, which, I guess, is effectively what I did).

Generally consultants are not selling a product. They are hired to bring knowledge and experience to a team, to be there when needed, and to offer flexibility for which it would be time and cost prohibitive to develop an internal employee.

Yes, that's the point. As a software freelancer you have no responsibility to take on risk for a client company that you have no ownership in. You'd be a fool to do otherwise.

Every hourly billable contract I've signed has included a detailed scope. Contracts that very clearly delineate responsibilities and compensation. Both parties are agreeing to the value the freelancer is providing. You'd be a fool to hire a freelancer without understanding the value they provide. And as a freelancer you'd be a fool to sign a contract without clearly defined responsibilities.

The author seems to believe the method of compensation determines the value provided. But these things are orthogonal. I've worked with multi-million dollar agencies that bill by the hour. They provided a lot of value, they knew precisely the outcomes they were responsible for, and delivered those outcomes.

Blog posts like this come along every so often, usually when a freelancer discovers that there are circumstances where they can make more money on a fixed cost contract. For instance "This project will take me 40 hours. If I charge $100/hr I'll gross $4000 total. Or I could quote a fixed cost of $5000 total, and net an additional $1000".

The downside is estimating software is hard, mostly because the end product is almost always a moving target. Generally speaking, clients have a good idea of what they want. But "what they want" almost always changes as a project progresses.

The upside for the freelancer is that if the scope can be nailed down, and a client is predictable, a fixed cost model allows the freelancer to capture any additional value/profit from their productivity.

Which is why savvy businesses are fine with paying hourly rates. They want to fully capture the value of the freelancer's productivity.

In my experience, from a freelance point of view, it tends to be a wash. There are many fixed cost projects where you will come out ahead. But there are always projects with tons of scope creep, and cost increases are almost always more difficult to negotiate on fixed cost contracts. But YMMV, and there's no single correct answer.

They get the money upfront, before they do any work

So, from the get go they know the minimum they are going to make, and they never get stiffed (also because most people don’t want to get into legal issues with a lawyer)

If you are an honest person and do business the right way, T&M is the way to go. If you want a higher effective hourly, then you would pad fixed. That doesn't make you professional though; it makes you dishonest if you purposely inflate.

If the company needs it to be fixed to compare apples to apples or their finance dept requires it, then submit your fixed scopes and run your business. It's professional to be flexible. And to not fight client processes and procedures.

You will not win a lot of great business if you have only 1 way to run your projects. Some larger companies will take a vendor that costs way more but offers better terms like net 45 or net 90.

I'm a professional. I run a business with employees that's grown every year. We do both, but it's better T&M. All time is logged with descriptions of what was done. We bill based on seniority.

We still do time estimates on items that are T&M so my team is accountable, thinks about their approach and time, and so the client can have an idea of what they are committing to. They don't care if it goes over, it just can't get out of control. And they need this information to triage and approve requests.

T&M with time estimates is a professional way to go. Some of your estimates will be off, some will be under. Just make sure clients understand that and traffic your wins and losses. And if you find out your 24 hr task is going to take 60 hours, notify the client as soon as you discover that to avoid surprises.

I'm experimenting with a more traditional contingency budget which is explicit in the estimate. In that manner, a fixed bid would be done but the client would be aware that there could be unknowns that result in tapping the contingency budget. And if it's not tapped - they don't pay it. So rather than try to bake the unknowns into the fixed which the client would pay regardless, I can have the contingency reserved if needed but be more palatable against a competing bid that wraps it into their fixed.

So say, 100k fixed bid, separate 20% contingency for unknowns for my bid. Versus another company's 120k fixed bid, no contingency. Both possible 120k spend. One may not use contingency and thus be 20k cheaper. The other - 120k is paid no matter what.

Anyone do that on their larger projects? How is that received?

I won't pretend I have years of experience in the freelancing world... I am fairly new to it myself. But I do know as engineer who also has done some stints in product, sales, and business side, that, just like in software, there is no one "right way" and that one of the most consistent challenges business face is choosing the best of many reasonable options, especially when one of those choices is viewed as a "best practice" but the team lacks the direct experience to answer the question of "best practice for who and when?"

I fully agree with the author that there are some real market forces that can make hourly work not the ideal for many situations... but I also think it massively over simplifies the different types of work that are done as "freelancing".

Whole new products, new features in existing products, taking over projects, rescuing projects, consulting with less experienced teams, embedding in teams, integrations of external tools, is probably only 25% of the type of engagements a single consultant may come across and probably only 1% of the type of engagements that exist. Combine that with the huge range of attitudes of companies and very quickly we are in a space where no single solution exists.

It seems like the author's true point is in the conclusion, that you should focus on driving value and results for your customer and you should structure work to align with that, which is absolutely true. The general take of "hey engineer guy who isn't as business savvy, that value might not be best delivered via hourly billing!" is not bad advice. If you do hourly billing because it is the most straight forward, you should probably think about it... but you also shouldn't move to project based billing because of some people calling it a best practice either.

My advice to any engineer looking to freelance (but really to almost anyone everywhere in this industry) is to not take the easy way out when facing decisions outside your domain. I think so often work seen outside of code is seen as "lesser value", and because of that, shortcuts are made by just taking the easiest or "best practice" answer to a problem and running with it, and not gaining any understanding of the problem space. No one can be an expert in everything, but when you can't make this decision someone else's job, like when a business doesn't have some expertise (which in freelance is always the case) then you can't afford to not put in the time to learn enough to at least be informed. If you then do decide to do the easiest / best-practice thing, at least you know why you choose that option and can later evaluate how it is working for you.

In summary, there is no simple answer, be thoughtful and keep trying new things. What works for one gig may not work for another.