4 ms·
Day Rates (2023)
- RamVasuthevan 2y agoPatio11 has similar advice to charge by the week https://training.kalzumeus.com/newsletters/archive/consulting_1 https://training.kalzumeus.com/newsletters/archive/consultin...
- gervwyk 2y agoGood 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.
- nbk_2000 2y agoDon'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).
- tightbookkeeper 2y agoGood 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.
- jeroenvlek 2y agoAs 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.
- cranium 2y agoI 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).
- lelanthran 2y ago> 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.
- fguerraz 2y agoFor 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.
- b5n 2y agoI've found hourly with an initial up front minimum works well.
- angra_mainyu 2y agoAs someone transitioning into contracting (Senior dev), do you have any advice? Was thinking of hitting up recruiters with my rates.
- mpeg 2y ago
- niobe 2y agoWell, 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.
- hinkley 2y agoWe 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.
- hinkley 2y agoI 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.
- AmericanChopper 2y agoI 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.
- tightbookkeeper 2y agoI'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?
- 2y ago
- jokethrowaway 2y agoYou 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).
- cranium 2y agoRelated 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 https://www.youtube.com/watch?v=jVkLVRt6c1U
- tightbookkeeper 2y agoThat was kind of long for not a lot of information, but a few good points. thanks for sharing.
- dieselgate 2y agoAny chance you could summarize for us since you’ve watched? :)
- tightbookkeeper 2y ago- 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
- dieselgate 2y agoThank you!
- a_c 2y agoThe other day there was a Show HN about a youtube summarizer. https://news.ycombinator.com/item?id=40843528 https://news.ycombinator.com/item?id=40843528 I haven't tried as it is chrome only.
- padjo 2y agoIf 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.
- deleted 2y ago[deleted]
- seanwilson 2y agoI 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.
- DishyDev 2y agoThe 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.
- Lio 2y agoI 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.
- TomK32 2y agoWhy 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
- jt2190 2y agoIf 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.
- flir 2y agoWhen 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).
- mattbee 2y agoIt'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.
- jot 2y agoI 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/ https://jonathanstark.com/ His book “Hourly Billing is Nuts” is particularly good: https://jonathanstark.com/hbin https://jonathanstark.com/hbin
- brtkdotse 2y agoJonathan’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.