4 ms·

This poll seems to be doin it rong. I couldn't put a single figure on it and say "I won't get out of bed for less than this" because so long as my hourly rate i

by dools 16y ago

This poll seems to be doin it rong. I couldn't put a single figure on it and say "I won't get out of bed for less than this" because so long as my hourly rate is satisfactory, I'll do 30 minutes work and bill someone for it. I work out my hourly rate like this: There are about 219 work days in a year after leave and entitlements. As a freelancer I'll probably stay billable 3/5 of those and on average I can hope for 6 effective billable hours per day, so there are about 788 billable hours per year. I then think of my target yearly salary and divide by number of billable hours per year. I actually have some indirect overheads, too so I add a margin on that, but if you're straight up freelance you may not need to. That's your base rate. So long as your timesheeting, invoicing and accounting systems aren't drastically inefficient (ie. you can raise, issue and track an invoice in under 5 minutes) you can work for 30 minutes, charge for half an hour, issue the invoice and be done with it. If I get a longer contract, I usually reduce the hourly rate commensurately by increasing the ratio of billable to non-billable hours I'm expecting in that year as a result.

mattdeboard 16y ago
So long as your timesheeting, invoicing and accounting systems aren't drastically inefficient (ie. you can raise, issue and track an invoice in under 5 minutes)... What systems do you recommend? Excel spreadsheet for tracking + invoice template is really inefficient for me.
- dools 16y ago
  I wrote an invoicing system years ago that is still limping along (although I'm looking for a complete online accounting package that has a timesheeting API because ... ) I do all my timesheeting through an IRC bot which works really well. The bot reads tasks from my task system (I just create pages in my CMS and expose them through the API) so I type things like: askl start client: job name where client and job can be partial matches. When I make an entry it goes into the timesheet and I can either use that to generate my invoices directly (in the case of billable hours) or use it to offset a loss against a sales invocie (in the case of a fixed price quote).
  - mattdeboard 16y ago
    Ah very interesting way of going about it :P Specifically the IRC bot. What's the rationale behind an IRC bot to read your task system?
    - dools 16y ago
      Maybe I should do this as a blog post ... basically we use our own product, Decal CMS for managing our tasks. It exposes all your pages and data in an XML API. We have "tree" templates and "sprint" templates. A sprint page is added as the child of a tree page. You can timesheet against a tree, if you're doing some unplanned maintenance or something that just crops up, or you timesheet against a sprint if this is actually what you're supposed to be working on (this allows us, theoretically, to tell when a sprint is late because someone has been pulled in too many other directions, but in practice we don't have tools to report on this yet). So the IRC bot reads from the task system so that you can just type like: askl: start decal in order to start working on decal if you're doing some unplanned support or maintenance work, or if you're helping someone else out with their work, basically this is seen as an interruption from what you're scheduled to do. Otherwise you can do this: askl start: decal: some release to timesheet against a sprint (we block off time in google calendar to allocate work). Each "sprint page" has a structured xml component on it (this is like, Decal terminology that won't make sense until you try it - we should have a live demo ready in a few weeks so you can give us your email address by going here if you want to be told when that happens: http://www.decalcms.com/page/Try_it_Out http://www.decalcms.com/page/Try_it_Out). This structured XML component is where we put the client name, dates for the sprint and costs basis (either fixed price or amount per hour). This information is then used to make entries in the timesheeting system so we can tell whether to mark time as billable (in the case of per hour) so that it will generate an invoice, or not in the case of a fixed price where I raise an invoice separately and then the profit made on that "sale" is offset by the "loss" made in the development hours. All of this is very ad-hoc, strung together with duct tape and pixie dust and most of it works most of the time. The most important thing is that all our hours and work are logged, and that's how we work out leave entitlements at the end of the year. ie. each person is expected to put in 6 billable hours per day for 219 work days per year. So at the end of the year we just sum the hours you worked, and whatever is left over is how much leave you get the following year. Right. yeah. I should really do a blog post at some point about this :)

by dools 16y ago

mattdeboard 16y ago

So long as your timesheeting, invoicing and accounting systems aren't drastically inefficient (ie. you can raise, issue and track an invoice in under 5 minutes)... What systems do you recommend? Excel spreadsheet for tracking + invoice template is really inefficient for me.

dools 16y ago
I wrote an invoicing system years ago that is still limping along (although I'm looking for a complete online accounting package that has a timesheeting API because ... ) I do all my timesheeting through an IRC bot which works really well. The bot reads tasks from my task system (I just create pages in my CMS and expose them through the API) so I type things like: askl start client: job name where client and job can be partial matches. When I make an entry it goes into the timesheet and I can either use that to generate my invoices directly (in the case of billable hours) or use it to offset a loss against a sales invocie (in the case of a fixed price quote).
- mattdeboard 16y ago
  Ah very interesting way of going about it :P Specifically the IRC bot. What's the rationale behind an IRC bot to read your task system?
  - dools 16y ago
    Maybe I should do this as a blog post ... basically we use our own product, Decal CMS for managing our tasks. It exposes all your pages and data in an XML API. We have "tree" templates and "sprint" templates. A sprint page is added as the child of a tree page. You can timesheet against a tree, if you're doing some unplanned maintenance or something that just crops up, or you timesheet against a sprint if this is actually what you're supposed to be working on (this allows us, theoretically, to tell when a sprint is late because someone has been pulled in too many other directions, but in practice we don't have tools to report on this yet). So the IRC bot reads from the task system so that you can just type like: askl: start decal in order to start working on decal if you're doing some unplanned support or maintenance work, or if you're helping someone else out with their work, basically this is seen as an interruption from what you're scheduled to do. Otherwise you can do this: askl start: decal: some release to timesheet against a sprint (we block off time in google calendar to allocate work). Each "sprint page" has a structured xml component on it (this is like, Decal terminology that won't make sense until you try it - we should have a live demo ready in a few weeks so you can give us your email address by going here if you want to be told when that happens: http://www.decalcms.com/page/Try_it_Out http://www.decalcms.com/page/Try_it_Out). This structured XML component is where we put the client name, dates for the sprint and costs basis (either fixed price or amount per hour). This information is then used to make entries in the timesheeting system so we can tell whether to mark time as billable (in the case of per hour) so that it will generate an invoice, or not in the case of a fixed price where I raise an invoice separately and then the profit made on that "sale" is offset by the "loss" made in the development hours. All of this is very ad-hoc, strung together with duct tape and pixie dust and most of it works most of the time. The most important thing is that all our hours and work are logged, and that's how we work out leave entitlements at the end of the year. ie. each person is expected to put in 6 billable hours per day for 219 work days per year. So at the end of the year we just sum the hours you worked, and whatever is left over is how much leave you get the following year. Right. yeah. I should really do a blog post at some point about this :)