3 ms·

Side tangent (and maybe this should be its own thread), but I would be interested to know what is generally considered billable time - where do you generally dr

Side tangent (and maybe this should be its own thread), but I would be interested to know what is generally considered billable time - where do you generally draw the line? Learning a common tool (say Rails) that you will have to use for the project? Learning a very specific tool (say a function-specific library for some particular part of the project) that you have not previously claimed prior knowledge of? Studying the clients own existing code? What about negotiations? Research into the required work needed for particular functionality?

mattdw 12y ago
My projects are generally quoted, so a lot of this is not always relevant to me (although they affect how I quote things), but, my thoughts: - Learning core software/skills is not billable. "Core" is "any decent dev in this niche already knows this stuff." That's the stuff you read up on in your evenings. (One way my main client works around this is to have a senior dev always quote the tech side. Even if a junior dev does the work, they only get paid the quote, so they effectively self-adjust their hourly rate according to their skill level.) - I would charge (and have charged) reading the docs, figuring out how to compile, and integrating a third-party payment lib I'd never seen before. So, specific tools/libs outside of the norm, I consider chargeable. - Research for what I do is usually a write-off, but I can sometimes work a couple hours into the quote for a prototype if there are big unknowns. Or, before quoting, I say "give me a couple of hours to prototype, with the understanding that if we go ahead it's a component of the quote, if we don't go ahead you'll pay me anyway." Sometimes I don't charge the prototype, but it's instrumental in convincing the client to go ahead at all, so it's still a win. - Tangent of a tangent, but kinda related to your 'research' point – quoting is really hard, mainly because quoting thoroughly approaches the complexity of doing the work for real. So a lot of my quotes are "if things go how I hope they will this will take 1 hour. If things go badly I'll come back and talk to you because we could be looking at days." Unknowns are really hard to quote without just doing the work.

mattdw 12y ago

My projects are generally quoted, so a lot of this is not always relevant to me (although they affect how I quote things), but, my thoughts: - Learning core software/skills is not billable. "Core" is "any decent dev in this niche already knows this stuff." That's the stuff you read up on in your evenings. (One way my main client works around this is to have a senior dev always quote the tech side. Even if a junior dev does the work, they only get paid the quote, so they effectively self-adjust their hourly rate according to their skill level.) - I would charge (and have charged) reading the docs, figuring out how to compile, and integrating a third-party payment lib I'd never seen before. So, specific tools/libs outside of the norm, I consider chargeable. - Research for what I do is usually a write-off, but I can sometimes work a couple hours into the quote for a prototype if there are big unknowns. Or, before quoting, I say "give me a couple of hours to prototype, with the understanding that if we go ahead it's a component of the quote, if we don't go ahead you'll pay me anyway." Sometimes I don't charge the prototype, but it's instrumental in convincing the client to go ahead at all, so it's still a win. - Tangent of a tangent, but kinda related to your 'research' point – quoting is really hard, mainly because quoting thoroughly approaches the complexity of doing the work for real. So a lot of my quotes are "if things go how I hope they will this will take 1 hour. If things go badly I'll come back and talk to you because we could be looking at days." Unknowns are really hard to quote without just doing the work.