I notice that Dave is based in the UK, as am I. We have one big problem with day rate billing here and that's IR35.
IR35 is the dreaded tax code that forbids contractors from appearing to be "disguised employees".
There's no published fixed set of rules as to what is and isn't inside or outside IR35 but the guidance I've seen seems to me mostly centred on control and direction of labour.
The advice I've had from my accountants is that it's much easier to demonstrate that you're outside IR35 if you charge for deliverables and rather than time.
If you're just a bum on a seat, doing exactly what you're told, then you're indistinguishable from an employee for tax purposes.
As such you can be liable to be taxed twice retrospectively without receiving any benefits of employment such as sick pay, pension, holiday or expenses. That can happen years down the line even when your accounts were fully signed off and paid up.
When the tax liability for a "disguised employee" decision fell on the contractor, the clients were unconcerned. Now the tax liability falls on the end-client, they're extremely gun shy. IR35 is vague by design - its intention was to create a climate of uncertainty (IMO).
It's an anti-avoidance measure from when IT contractors benefited from (historically) lower business taxes while taking no actual business risks.
The rules are lengthy because they're trying to be precise. If you read the guidance on gov.uk, I don't think they're not vague at all. There's even a step-by-step "wizard" so you can determine if a particular contract falls inside or outside the rules.
IMO the only people "dreading" the IR35 rules are the people still trying to dodge them.
Why not both? A fixed project rate and all the extra that inevitably and uninvited show up cost by the hour. The reasoning being that 90~95% of the project are easy to complete with the rest often taking up an unknown amount of time and resources
If you know today that 5% of your projects have an “infinite downside” (i.e. an “unknown amount of time and resources”) you need to fix your contract to cap that to a reasonable amount.
I had a boss at a consulting company who really chewed on this idea. In the face of a potential boondoggle project, the discovery phase may be close to the last time your company turns a profit on a project.
Why not get the payments for helping them define the project requirements, and then if you still smell boondoggle, you can quote them an estimate that you can actually profit on but may make them run to a competitor for a lower bid. Now your calendar is clear for projects you’ll actually make money on, plus one of your competitors now can’t compete as well on your next bid.
But he ran into the same problem: an explicit discovery phase gets summarily rejected. Even though it would benefit everyone. I suspect deep down they know what they’re asking and they want to trick you into saying yes and getting sunk cost fallacy before you sober up and start telling them no.
I agree that it usually doesn’t fly with clients, unless you already have a good relationship and track record with them. But I don’t think it’s supposed to be a trick. On the client side somebody either has some funding for a project and needs to know whether you can deliver within the budget, or they need to go and apply for some funding to complete the project, but in either case the deliverable they’re committing to provide in exchange for this funding is the completed project, not a scope for the project.
From that perspective the “discovery project” is just a much worse version of “contact us for pricing”, it’s “pay us $5,000-$20,000 or more for pricing”. Paying a lot of money to find out how much something will cost, or what you’re going to get from it (if anything) just isn’t a valuable proposition to a lot of people, and doesn’t fit in nicely with their existing business processes.
I've been advised to charge for a discovery, but at a ridiculously low price, say $500. It's likely they can expense it without approval, shows they are serious, and, helps you feel good about putting effort into a serious proposal.
The deal is that you’d have to provide the customer not just with a price quote but a complete requirements doc based upon the discovery. They can shop this to other contract houses. Just a bid leaves them I’m the hole with absolutely nothing to show for it.
I think this depends on the scope/size of project.
In a previous role, I worked at a product-led consultancy in a niche industry which delivered multi-year + multi-phase projects. These were projects were delivered (on our side) on a time and materials basis, and could easily get into the tens of millions in fees.
There would typically be a 'requirements gathering' phase of the project where we held business workshops, where the output was a more concrete project estimate with potential timelines.
This is what would go into the signoff/contract of the project-proper. At this point the client could in theory walk away, with the documents we had produced as part of that phase. Think business process diagrams etc.
The client would pay for the requirements gathering, although I suspect like everything, there would have been discussion about how long it should be/how much it should cost up-front. The projects we had all had a similar phase, simply because it was very hard to know how much there was to do (on both sides) without detailed discussions about what their existing business looked like.
I currently work for a consulting company that specializes in SAP migration to cloud. A hefty portion of our business is what we call "advisory services", which is essentially just assessment, scoping, costing and documentation work before the real project. Sometimes a $50-100k advisory engagement turns into nothing, but sometimes it turns into multi-million dollar contracts.
As a freelancer myself I go one step further and actually charge hourly rates. This granularity helps both with short workshops and fulltime projects because with the latter I'm often asked to work overtime or I have personal errands to run. Charging by the hour smooths this quite a lot.
I went the other way (hourly -> daily) and found it much more enjoyable. I have multiple clients and it's clearer for everyone what days I'm available for them. Otherwise I might juggle between "urgent" work for two clients and have a call for a third, which is suboptimal. Now, I'm considering adding back some hourly rates for calls outside my working days and for overtime work, to align incentives of all parties.
Rates and what you charge is a major interface with clients so it's worth taking the time to come up with a structure that suits you (first).
> I went the other way (hourly -> daily) and found it much more enjoyable.
Doesn't work too well with maintenance on existing products; clients really would rather not pay for the hours between a PR being submitted and the PR being merged. Toss in a good dose of 'waiting for your tech lead to answer these questions', 'waiting for feedback on this proposed document', 'waiting for infra to give me access', etc, and many clients completely balk at daily rates[1].
For complete products daily billing works nicely.
[1] This is because they know that a turn-around time for granting access to their labyrinthine infra for all the machines that might be needed is going to take more than a day.
I think hourly attracts cheaper clients that will want you to be extremely exact in your timesheets.
Day rate clients often don't necessarily care what you do with the time as long as your deliverables are being met – but it still helps them to pay on a time-basis as it's an easier model and more predictable
The thing I don't like about day rates is where I've seen large consultancies pile in large inexperienced teams propped up by one or two seniors to do the actual job that needs doing.
With pay per day deals sometimes success for the consultancy is how many people they can get on a project, and less experienced people give higher profit margins. Being successful doesn't pay better than running late, and few clients have the knowledge or oversight to not get ripped off.
I know reality is far murkier than that and fixed price comes with different problems.
I think hourly vs fixed vs weekly vs value billing involves a lot of personal preference, as well as depending on the project and the client. We'd all be doing it the same way if there was one best way.
Most of the discussion tends to be centered around profit, but there's other factors e.g. weekly billing sounds good for being booked up but you'll have less freedom over your day-to-day schedule, hourly can be good for unpredictable/flexible work but you'll probably have to keep more fine-grained timesheets (which is a drag, and are awkward when you have to explain why things got held up from some inevitable tech/code problem), fixed/value based projects with large budgets can be high pressure when things aren't going as planned.
Then from a client perspective, a non-technical client is probably going to be more comfortable with a fixed price, and tech clients are going to be more understanding with daily/sprint based charging as they'll know how unpredictable coding can be.
It's interesting how for salaried work compared to contracting work, the way people are paid is standardised and there's usually little negotiation power there for choices.
Good article. An additional problem I find with this, is on bigger projects, it is time consuming and frustrating when a client try to micro-track what was done per day. Not the recording of what was done, more the non-technical explanation of what it means and why its required.
I’m thinking to also charge for such reporting requests and communication, but that feels weird.
Don't feel weird. I'd even itemize the task being being requested on their invoice (e.g. "reporting requirement fulfillment"). My perspective changed on this after doing a gig for Boeing, where they charged us for invoicing them. When we complained about this, they instructed us to bill them for their invoice fee, which they explained was how their internal cost structures worked so that the accounting department could calculate their profitability. After that revelation, I stopped asking questions and just put in the contract that all reporting requirements are considered billable work (duh).
Good management means defining when success criteria are evaluated. Shorter time increments are necessary in low trust environments, or with reports who need a lot of management.
"check-ins" should be defined and negotiated in the contract. Charge the ones who want frequent check-ins extra.
Readit News
IR35 is the dreaded tax code that forbids contractors from appearing to be "disguised employees".
There's no published fixed set of rules as to what is and isn't inside or outside IR35 but the guidance I've seen seems to me mostly centred on control and direction of labour.
The advice I've had from my accountants is that it's much easier to demonstrate that you're outside IR35 if you charge for deliverables and rather than time.
If you're just a bum on a seat, doing exactly what you're told, then you're indistinguishable from an employee for tax purposes.
As such you can be liable to be taxed twice retrospectively without receiving any benefits of employment such as sick pay, pension, holiday or expenses. That can happen years down the line even when your accounts were fully signed off and paid up.
The rules are lengthy because they're trying to be precise. If you read the guidance on gov.uk, I don't think they're not vague at all. There's even a step-by-step "wizard" so you can determine if a particular contract falls inside or outside the rules.
IMO the only people "dreading" the IR35 rules are the people still trying to dodge them.
Why not get the payments for helping them define the project requirements, and then if you still smell boondoggle, you can quote them an estimate that you can actually profit on but may make them run to a competitor for a lower bid. Now your calendar is clear for projects you’ll actually make money on, plus one of your competitors now can’t compete as well on your next bid.
But he ran into the same problem: an explicit discovery phase gets summarily rejected. Even though it would benefit everyone. I suspect deep down they know what they’re asking and they want to trick you into saying yes and getting sunk cost fallacy before you sober up and start telling them no.
From that perspective the “discovery project” is just a much worse version of “contact us for pricing”, it’s “pay us $5,000-$20,000 or more for pricing”. Paying a lot of money to find out how much something will cost, or what you’re going to get from it (if anything) just isn’t a valuable proposition to a lot of people, and doesn’t fit in nicely with their existing business processes.
Have you seen anything like that succeed?
Of course no customer would accept that.
In a previous role, I worked at a product-led consultancy in a niche industry which delivered multi-year + multi-phase projects. These were projects were delivered (on our side) on a time and materials basis, and could easily get into the tens of millions in fees.
There would typically be a 'requirements gathering' phase of the project where we held business workshops, where the output was a more concrete project estimate with potential timelines.
This is what would go into the signoff/contract of the project-proper. At this point the client could in theory walk away, with the documents we had produced as part of that phase. Think business process diagrams etc.
The client would pay for the requirements gathering, although I suspect like everything, there would have been discussion about how long it should be/how much it should cost up-front. The projects we had all had a similar phase, simply because it was very hard to know how much there was to do (on both sides) without detailed discussions about what their existing business looked like.
Rates and what you charge is a major interface with clients so it's worth taking the time to come up with a structure that suits you (first).
Doesn't work too well with maintenance on existing products; clients really would rather not pay for the hours between a PR being submitted and the PR being merged. Toss in a good dose of 'waiting for your tech lead to answer these questions', 'waiting for feedback on this proposed document', 'waiting for infra to give me access', etc, and many clients completely balk at daily rates[1].
For complete products daily billing works nicely.
[1] This is because they know that a turn-around time for granting access to their labyrinthine infra for all the machines that might be needed is going to take more than a day.
Was thinking of hitting up recruiters with my rates.
Day rate clients often don't necessarily care what you do with the time as long as your deliverables are being met – but it still helps them to pay on a time-basis as it's an easier model and more predictable
https://jonathanstark.com/
His book “Hourly Billing is Nuts” is particularly good: https://jonathanstark.com/hbin
With pay per day deals sometimes success for the consultancy is how many people they can get on a project, and less experienced people give higher profit margins. Being successful doesn't pay better than running late, and few clients have the knowledge or oversight to not get ripped off.
I know reality is far murkier than that and fixed price comes with different problems.
Most of the discussion tends to be centered around profit, but there's other factors e.g. weekly billing sounds good for being booked up but you'll have less freedom over your day-to-day schedule, hourly can be good for unpredictable/flexible work but you'll probably have to keep more fine-grained timesheets (which is a drag, and are awkward when you have to explain why things got held up from some inevitable tech/code problem), fixed/value based projects with large budgets can be high pressure when things aren't going as planned.
Then from a client perspective, a non-technical client is probably going to be more comfortable with a fixed price, and tech clients are going to be more understanding with daily/sprint based charging as they'll know how unpredictable coding can be.
It's interesting how for salaried work compared to contracting work, the way people are paid is standardised and there's usually little negotiation power there for choices.
"check-ins" should be defined and negotiated in the contract. Charge the ones who want frequent check-ins extra.