Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Day Rates (2023) (davesmyth.com)
148 points by herbertl on Oct 11, 2024 | hide | past | favorite | 52 comments


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.


Yes, there was a legion of "IT Contractors" that were effectively salaried workers in all but a few main factors:

    1. Their self labelling as "Contractors"
    2. Their employment rights
    3. Tax.
And everyone knew this was the case. You'd have people working 2, 3 or more years at a company and people at the company wouldn't even know they were technically contracting.

Of course when there was little or no enforcement, it was rampant.

The act of shifting liability to the client was a work of genius to clear out all these disguised employees.

Big Companies went from incentivised to dis-incentivised to engage in this practice.

You can still contract "inside IR35" too, you just need to pay tax as such. Of course companies would rather engage "outside IR35", but any "barriers" are just clarifications about what a contractor is.

"Why can't I act just as an employer/employee would but not pay employers' NI" is not a reasonable position.


Inside IR35 does not in fact exist.

Every contracting advert which lists inside IR35 actually means "umbrella company". Agencies in my experience do not in fact even understand there is a difference.

This means you cannot use your company, or the accountant you've had for decades, and you must now pay a third party (the umbrella), and you have little choice about the umbrella - the agency will require you to use one of the two or three they present, with whom they have agreements and get a percentage.

It's a rigged game. Everyone is dipping their fingers in the pie, and the person at the end who gets it in the pants is the guy doing the actual work.


Of course "Outside IR35" doesn't really exist either, it's just "contracting", but companies find it useful to have labels to clarify their position.

I agree I wouldn't touch the kind of umbrella arrangements you're describing, but short-term or set-term employment contracts do exist too, although usually come about from circumstances different to advertising for contractors.


Personally, I find the "tax dodger" talk to be unhelpful.

When I was contracting HMRC would not give me a hard list of rules to follow even if I wanted to.

For example if you deliver some piece of code and the customer asks you to provide support for it, is that inside or outside?

The initial software is a deliverable and so within your control.

Support though is usually based on time and issues that the customer brings to you. That could be said to be out of your control.

So is the contract inside or outside? You and your accountant can only guess.

That wizard you mention only gives guidance, it does not provide a legal answer.

Plus HMRC can and do retrospectively change the rules to reopen accounts years after they were originally accepted.

There's no finality there and the longer you run your business the bigger risk.

At the time I couldn't find a suitable insurance service to cover that risk. I believe there are now finally IR35 cover products but it worried me enough that I just closed my contracting business down.

I can only assume that as HMRC were happy with that winding down that I was not a "tax dodger" all along.


The first page of the wizard says "HMRC will stand by the result you get from this tool." You can reference any check you make with, assuming you answer honestly.

I think it's fair to challenge the "tax dodger" brush if a lot of people are suddenly made "tax dodgers" unfairly. But you've got to read the room. Personal Service Companies were a scandal that were legislated against. If you want to carry on doing certain kinds of work and not _think_ about tax, just pay tax as a Sole Trader, forget about the rest of the rules.

If you want to try to hang on to tax advantages (that have been all-but-eroded), feel free but if you want to earn big money and optimise your tax accordingly, yes, you do have to keep up with rule changes, or maybe pay the price later. But I'd say IR35 isn't relevant to the average worker any more.


> Support though is usually based on time and issues that the customer brings to you.

You’ve just identified a risk to your contracting business: Under these (unclear) terms the customer can dictate an infinite amount of support hours for a fixed price. As a business owner you need to protect your profitability by ensuring that there are clear terms putting controls and limits in place.


That "wizard" is completely bogus. It's a rigged game.

It assumes mutuality of obligation, that the contractor is required to accept further work from the client, and the client is expected to provide that work, a key requirement to prove someone is an employee.

The fact that this is so gives a good sense of how IR35 is being used by the State.


> IMO the only people "dreading" the IR35 rules are the people still trying to dodge them.

That observation seems vaguely circular. The dread is because someone might be able to avoid the tax but has to do something inconvenient, or because there is a risk of misinterpreting the tax law's provisions. So yes, the people who dread a tax are exactly the people trying to avoid it.

And this is the nature of taxes. The economics of society are largely structured by tax avoidance schemes, people put huge amounts of effort into not quite making a normal income for tax purposes.


HMRC's guidance maps very imprecisely to legislation and case law.

Eg the CEST tool asks "Will this work take up the majority of your available working time?"

Guidance for that question is here: https://www.gov.uk/hmrc-internal-manuals/employment-status-m...

Can you tell me why they ask it? What light it sheds on the central question of contract-of-service vs contract-for-service?


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.

Have you seen anything like that succeed?


I’ve seen folks successfully implement a process where discovery is ‘free’ if the client hires them for the implementation. Otherwise discovery is $10K or whatever


I haven't had problems with discovery projects. The framing is usually that both sides genuinely don't know enough about what needs to be done, you'll produce a rough plan at the end of it, and you've agreed to a rough ballpark budget beforehand where discovery is helping you decide on the scope and specifics.

Otherwise, even for simple projects, the process is usually you do a couple of rounds of questions for a few hours, then you're forced to give a quote when you don't know enough which is bad for both sides.

People get weird about charging for discovery, but gathering requirements, evaluating the current situation, researching options and proposing a solution, is tricky and valuable work, and doing this properly can save a lot of pain later.


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.

Of course no customer would accept that.


Yeah.

Back in the day a proper requirements doc was something a client would pay for. It’s a tangible thing with real value.

These days we sell design sprints that produce validated prototypes instead (thank god for Figma). This is a much easier sell and still gives the client the opportunity to decide if we implement the thing or if they hand it off to someone else.


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.


For me hourly rates work best too. I charge only for real work, not for breaks, because really working an 8h day is unrealistic for me.


As someone transitioning into contracting (Senior dev), do you have any advice?

Was thinking of hitting up recruiters with my rates.


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


I've found hourly with an initial up front minimum works well.


I highly recommend reading Jonathan Stark’s material on this topic. It changed the way I think about billing for software projects and advisory work.

https://jonathanstark.com/

His book “Hourly Billing is Nuts” is particularly good: https://jonathanstark.com/hbin


Jonathan’s stuff I awesome _however_ if you’re someone who slings code for a living you’ll probably have a hard time implementing his ideas.


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.


Patio11 has similar advice to charge by the week https://training.kalzumeus.com/newsletters/archive/consultin...


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.


Well, author's caveats noted, but the big problem with day rates is that ALMOST EVERY CLIENT I EVER HAD WANTS A FIXED PRICE QUOTE. This will no doubt vary by country/region/industry quite a bit, but it's almost a given for my customer base, public and private sector.

On the other hand, fixed price quotes can also be a little less than transparent, and clients like transparency about how you're charging.

I use the best of both worlds:

- Bigger jobs: anything more than 5 days, I quote a fixed cost, BUT I provided my estimated work effort in days in the quote and client can deduce my rate from there.

If I do it quicker, great, client is not worried, they already agreed to the quote, and I'm incentivised to be efficient (but also maintain quality or I wouldn't get the repeat business). If a job goes a bit longer, well that's on me and my estimates as a first point. Over the years I've got quite good at estimating work effort, and antipating issues and things that will slow projects down, so there's really been few issues with this approach. As a second point, if something is really going long I can just ask for a variation. Usually I will only need to do this if there's a strong justification, and in 100% of those situation the client has approved extra charges.

- Small jobs: just a fixed price

This is for simplicity and because small jobs have a disproportionate amount of admin and project mgmt overhead. Rather than inflating my rates for small jobs I would rather just pick a reasonable total price and then make it work at my end.

No real issues with this in over 12+ years of technology consulting. The one minor thing is when I'm subtracting to a company that does NOT like to be transparent, and then I'm basically arming them with the information to take advantage of me. So here and there I've had my services marked up 30-50% from what I'm charging (up to 20% is reasonable) but it's a relatively rare situation.

Note: internally I always track time in 15 minute increments and round up or down. So I also have the data if it's asked for but more importantly the ability to see if I'm on budget and if my quoting is accurate.


“Please don't use uppercase for emphasis. If you want to emphasize a word or phrase, put asterisks around it and it will get italicized.“

https://news.ycombinator.com/newsguidelines.html


At least in the UK day rates are extremely common, much more than fixed price for individual contractors.

I actually prefer fixed price with the right client – as sometimes the actual work ends up being say 2-3 weeks stretched over a couple months but you get paid £50-100k because the project is fixed cost.

What I would say away from is fixed price for anything under £15-20k – it's just not worth it and they will often try to extract as much time as possible


We had a cost plus project with state government once but the project owner got drunk on the ability to change his mind whenever he wanted and eventually his boss had a fit when he figured out how little progress we’d actually made due to all of the requirements shifts. And then come a new year we were on a fixed price project with a guy who couldn’t change gears that fast. It did not end well. In large part because we started by lying to ourselves about how long it would take.


I used to operate as you're describing and appreciate the skill required to do so, but I eventually found it impacted my ability to transition a fixed scope engagement into an open-scope engagement. I've since found it more enjoyable, profitable, and beneficial to the client, to bill daily rates and let the client stretch the scope as much as they like (which they often do once they see the value my company brings).


What type of projects are they exactly?


Related to pricing and contracting with clients, this talk by Mike Monteiro (accompanied by his lawyer) is a gem: "F*ck You, Pay Me", https://www.youtube.com/watch?v=jVkLVRt6c1U


That was kind of long for not a lot of information, but a few good points. thanks for sharing.


Any chance you could summarize for us since you’ve watched? :)


- make sure you have a contract, negotiate it because they build it as a wish list - make sure you have a lawyer to help you with contracts. If they bring a lawyer to a call, get your lawyer - ask directly for money when it’s due, or when you’re pitching. Don’t ever act like anything other than a business (emotional desperation bad) - develop relationships inside client org who will help you


Thank you!


The other day there was a Show HN about a youtube summarizer. https://news.ycombinator.com/item?id=40843528 I haven't tried as it is chrome only.


You probably want a mix of both, daily/hourly rates to give you stability, fixed cost to charge based on the value you provide instead of the time spent.

With fixed cost my hourly rates can easily be 3x normal rates but I'm also getting more risks (extra meetings or overtime, clients not paying).


If your clients are happy to pay a day rate of course that’s what you charge. Way less risk on you. Many clients don’t want that though, they have a budget and need the project done for that amount and are paying you to take that risk on.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: