Everything I wish someone had told me (about freelancing)(megrobichaud.tumblr.com)
megrobichaud.tumblr.com
Everything I wish someone had told me (about freelancing)
http://megrobichaud.tumblr.com/post/22147155867/everything-i-wish-someone-had-told-me-about
81 comments
Steve Friedl's So you want to be a consultant...? ( http://www.unixwiz.net/techtips/be-consultant.html ) is also a must-read. Not only is Steve a Unix expert (and the brother of Jeff Friedl, regex legend), he's an excellent writer as well.
That's the link that I needed most in this world right now. Thanks for posting it.
My pleasure! Glad to hear you found it helpful. It played a large part in shaping my course (and later success) as well.
One not so minor point: you can't just "write off unpaid invoices"
- if you're on an accrual basis (i.e., you record income when you bill), then you can "write off unpaid invoices", but what you're doing is simply subtracting the unpaid invoice from the income you earlier recorded;
- otoh, if you're on a cash basis (i.e., you record income when you receive it), which is far more common for small biz, then you never recorded the income for that unpaid invoice, so attempting to write it off will get you in big trouble with the IRS (or the equivalent in the Great White North).
One additional note:
Automate wherever possible. Especially if you're a developer there are no excuses. Automatically log your time using something like Time Sink ( http://manytricks.com/timesink/ ). Adopt a convention for your git commits so that you can use some of your git messages as line items for your invoice (e.g. anything with "Feature: " in the front)
I wrote a gem called "Big Bucks No Whammies" ( https://github.com/aantix/big_bucks_no_whammies ) specifically for my billing purposes.
Automate wherever possible. Especially if you're a developer there are no excuses. Automatically log your time using something like Time Sink ( http://manytricks.com/timesink/ ). Adopt a convention for your git commits so that you can use some of your git messages as line items for your invoice (e.g. anything with "Feature: " in the front)
I wrote a gem called "Big Bucks No Whammies" ( https://github.com/aantix/big_bucks_no_whammies ) specifically for my billing purposes.
I'm a little confused by web developers' fascination with time tracking. In my practice, if I'm working for you for a significant chunk of a day, that's the day, gone. I am more likely to just do work for you for free than to bill in less than 8-hour increments.
Do you really invoice clients for "11 hours, 3 minutes"?
I think I'd go so far as to say that the "N minutes" part of that invoice actually looks a little unprofessional. (I'm sure you're a consummate professional, though!)
Do you really invoice clients for "11 hours, 3 minutes"?
I think I'd go so far as to say that the "N minutes" part of that invoice actually looks a little unprofessional. (I'm sure you're a consummate professional, though!)
I think time-tracking has fascination for a certain bracket of freelancers because it is an easy, low-stress way to rescue waste from the business: you are actually doing more work then you are invoicing, so if you actually tracked it better your billings go up and your client will be happy and it doesn't hurt any shadow beliefs about the evilness of making money.
There are better ways to accomplish these goals, like switching to daily rates (or weekly rates). No client worth having cares what your work structure looks like if you're capable of producing -- just move to a day rate, give them your honest best effort, and deliver results.
e.g. Most of my clients are pretty happy with me. None of them would perceive value from me slicing out 7 minutes from an invoice because, e.g., I wrote a post on HN. (They just profoundly don't care about that, they care about the deliverables, the feeling of happiness they get working with me, and -- ideally -- measurable results as a result of the engagement.)
There are better ways to accomplish these goals, like switching to daily rates (or weekly rates). No client worth having cares what your work structure looks like if you're capable of producing -- just move to a day rate, give them your honest best effort, and deliver results.
e.g. Most of my clients are pretty happy with me. None of them would perceive value from me slicing out 7 minutes from an invoice because, e.g., I wrote a post on HN. (They just profoundly don't care about that, they care about the deliverables, the feeling of happiness they get working with me, and -- ideally -- measurable results as a result of the engagement.)
I figured you'd say something like this; just to make my bias clear, I'm pretty close to thinking "use of automated time tracking or paying for web services to manage time tracking is a symptom of a broken business model". Harvest is a lovely web application, but something would have to have gone wrong with my consulting practice for us to want to use it.
"No client worth having cares what your work structure looks like if you're capable of producing"
That is very easy to say when you are an established freelancer with work being thrown at you. Just starting out though, there is a fine balance between what's ideal and staying afloat.
That is very easy to say when you are an established freelancer with work being thrown at you. Just starting out though, there is a fine balance between what's ideal and staying afloat.
If you want to run your business suboptimally in the hopes that it will attract your first clients, that's fine, but you shouldn't do so while pretending that it's the right way to run a business. I have a hard time thinking of clients who are particularly well-served by, say, 3-hour billings. Customers that need sporadic work like this are probably far better served by retainer arrangements. If you find yourself doing lots of 1, 2, and 3-hour projects, you should consider a staff augmentation arrangement instead of project billing.
For the most part, I think all consultants kid themselves about how productive they are juggling multiple projects in a day. It's not as if this is some great insight on my part. I'm a developer; I've read all the same stuff as you. I just paid close attention to the stuff about getting "in flow". Re-read Joel Spolsky's "Fire and Motion" essay.
For the most part, I think all consultants kid themselves about how productive they are juggling multiple projects in a day. It's not as if this is some great insight on my part. I'm a developer; I've read all the same stuff as you. I just paid close attention to the stuff about getting "in flow". Re-read Joel Spolsky's "Fire and Motion" essay.
> Do you really invoice clients for "11 hours, 3 minutes"?
I would certainly hope not. I personally tend to round to the half day (including down to zero), and sometimes to the next hour depending on the client, the frequency of work, how much we've worked on together over time, etc.
I think you might be skipping over the personal benefit of time tracking. Sure after a few years of freelance development, Most estimates get easier, but only because you know how long things have taken in the past.
If I didn't track all my hours in the past, I'd have no idea how to estimate tasks, much less entire projects. The hardest part when I was first starting out was estimation. After a couple years of getting it wrong - and eating hours instead of food - I was finally able to get my estimates within a couple days.
Of course when projects get more innovative, it gets difficult to judge how long things will take, but I can still count on the parts I already know to build a groundwork for how long most of the project should take.
Otherwise, I've found charging down to the hour can be a good practice for new clients with small intro projects to make it immediately clear that they will pay my high hourly rate for the work they request. It's a filter. Over time, I'll probably eat plenty of hours for one-offs and whatnot. But I certainly don't want a new client to think so until a relationship has been developed.
I would certainly hope not. I personally tend to round to the half day (including down to zero), and sometimes to the next hour depending on the client, the frequency of work, how much we've worked on together over time, etc.
I think you might be skipping over the personal benefit of time tracking. Sure after a few years of freelance development, Most estimates get easier, but only because you know how long things have taken in the past.
If I didn't track all my hours in the past, I'd have no idea how to estimate tasks, much less entire projects. The hardest part when I was first starting out was estimation. After a couple years of getting it wrong - and eating hours instead of food - I was finally able to get my estimates within a couple days.
Of course when projects get more innovative, it gets difficult to judge how long things will take, but I can still count on the parts I already know to build a groundwork for how long most of the project should take.
Otherwise, I've found charging down to the hour can be a good practice for new clients with small intro projects to make it immediately clear that they will pay my high hourly rate for the work they request. It's a filter. Over time, I'll probably eat plenty of hours for one-offs and whatnot. But I certainly don't want a new client to think so until a relationship has been developed.
> In my practice, if I'm working for you for a significant chunk of a day, that's the day, gone.
In my practice, I'm more productive working on two or three different projects throughout the day. So I bill for the part of the day I'm actually using for that client.
In my practice, I'm more productive working on two or three different projects throughout the day. So I bill for the part of the day I'm actually using for that client.
I would be more productive if I worked nights and weekends, but since nobody would pay the bill rate premium that inconvenience merits, it benefits nobody for me to do that.
Sometimes programmers actually want to interleave multiple projects. Maybe you have two totally different codebases to work on; perhaps one is backend async code, and the other is Javascript UI. Both are a week's worth of work, but you'd burn out if you did either straight through.
Fine: interleave the projects. But that decision is orthogonal to your billing increment. Bill full days exclusively.
You will find as your business matures that every single client you want to keep won't blink if you round that 5-hour project they need up to a full day. Call it your minimum billable increment. Offer, if you want, to chunk a bunch of small projects into a day; this is one way to prospect for more hours at a long-term client.
Sometimes programmers actually want to interleave multiple projects. Maybe you have two totally different codebases to work on; perhaps one is backend async code, and the other is Javascript UI. Both are a week's worth of work, but you'd burn out if you did either straight through.
Fine: interleave the projects. But that decision is orthogonal to your billing increment. Bill full days exclusively.
You will find as your business matures that every single client you want to keep won't blink if you round that 5-hour project they need up to a full day. Call it your minimum billable increment. Offer, if you want, to chunk a bunch of small projects into a day; this is one way to prospect for more hours at a long-term client.
Hourly billing gives a freelancer a lot more flexibility on their day. What if the number of hours you work for a client on any given day (or week) is highly variable? For example, you work off hours when you can. Or you are splitting time between clients. Or the amount of work a client has on-site wanes and spikes unpredictably. Or you feel like leaving at noon every Thursday and Friday. I am still newish to freelancing, but I do not feel comfortable billing an full 8 hour day for just showing up in any of the above scenarios. And I certainly would not want to give me time away for free if I did not hit some minimum.
What if the number of hours you work for a client is highly variable? Bill them for a full day.
What if the client genuinely just needs a 1-line change every once in awhile? Set up a retainer arrangement that allocates 1-2 billable days to them every month, use-it-or-lose-it.
The clients who will both refuse to arrange a retainer and refuse a minimum increment are almost by definition pathological, and you should not work for them. In reality: virtually everyone you'd ever want to work for is fine with a 1-day minimum. If you are so low on the food chain that your clients aren't, I strongly advise you to climb up the food chain instead of figuring out better ways to extract value from terrible clients.
What if the client genuinely just needs a 1-line change every once in awhile? Set up a retainer arrangement that allocates 1-2 billable days to them every month, use-it-or-lose-it.
The clients who will both refuse to arrange a retainer and refuse a minimum increment are almost by definition pathological, and you should not work for them. In reality: virtually everyone you'd ever want to work for is fine with a 1-day minimum. If you are so low on the food chain that your clients aren't, I strongly advise you to climb up the food chain instead of figuring out better ways to extract value from terrible clients.
That variability is precisely why I'm freelancing, so I bill hourly, in quarter-hour increments no less. I worked 13.25 hours yesterday, for 3 different clients, and I'm getting paid for all of them. Last Friday I worked 6 hours, because I slept in a bit, and then it was nice out so I did some yard work. I billed for 6. Sunday I worked 4 hours for a client and 2 hours for my own projects, billed for 4. I've billed as little as 15 hours in a full week (due to time spent on personal projects) and as many as 90.
If I billed daily, how can I justify that schedule? I've worked with hourly freelancers before who said "You're going to pay me for the whole day, and between 9 and 5 I'm all yours", which is fair. I don't make that commitment to my clients and I would not take a client who required it. I commit to specific goals and bill them however long it takes. I tell my clients my goal is to be as replaceable and fireable as possible, because I have plenty of other interesting work to do and I don't need to spend time doing crap work to pad a budget.
Do I run a timer or punch a clock? No. I look at the clock when I start, and when I end. If I'm bouncing between two projects all morning, I just split the time. I don't obsess over minutes spent on quick phone calls or responding to important emails or IMs.
I also don't want someone to "use or lose it", whether that's the last two hours of a slow day where I'm blocked, or a retainer agreement, because then they're going to "use it" on something dumb because it's now a sunk cost.
Perhaps I'm misleading myself, but I don't think this is because I'm low on the food chain, and it's certainly not bending to the wishes of an evil client as these are my own rules. I think it's just a matter of work/lifestyle and I wouldn't have it any other way.
If I billed daily, how can I justify that schedule? I've worked with hourly freelancers before who said "You're going to pay me for the whole day, and between 9 and 5 I'm all yours", which is fair. I don't make that commitment to my clients and I would not take a client who required it. I commit to specific goals and bill them however long it takes. I tell my clients my goal is to be as replaceable and fireable as possible, because I have plenty of other interesting work to do and I don't need to spend time doing crap work to pad a budget.
Do I run a timer or punch a clock? No. I look at the clock when I start, and when I end. If I'm bouncing between two projects all morning, I just split the time. I don't obsess over minutes spent on quick phone calls or responding to important emails or IMs.
I also don't want someone to "use or lose it", whether that's the last two hours of a slow day where I'm blocked, or a retainer agreement, because then they're going to "use it" on something dumb because it's now a sunk cost.
Perhaps I'm misleading myself, but I don't think this is because I'm low on the food chain, and it's certainly not bending to the wishes of an evil client as these are my own rules. I think it's just a matter of work/lifestyle and I wouldn't have it any other way.
If I am regularly working onsite at a client, and I leave early on my own accord, I am not going to bill a full day. How would that be fair to the client? Sure, billing for a full day is optimal for my business, but I don't see how it's optimal for the client.
I do not use hourly increments because my clients are awful or because I am low on the food chain. I choose hourly because it's the most straightforward way for me to provide my clients a hired hand while retaining flexibility on any given work day.
I do not use hourly increments because my clients are awful or because I am low on the food chain. I choose hourly because it's the most straightforward way for me to provide my clients a hired hand while retaining flexibility on any given work day.
Your definition of the word "fair" is broken.
You've defined it to mean "extracts from the relation, at all feasible cost, the maximum amount of value for the client".
That's not what "fair" means. "Fair" means that both the client and the consultant agree that the terms of the engagement are equitable: that the consultant is being compensated in accordance with the value they're generating.
The clients you want to work with will universally agree that, absent some other arrangement, it is "fair" to establish a minimum billable increment of a full day. That full day increment accounts for the cost to you, the consultant, in terms of lost flexibility and opportunity to serve other clients for the remainder of that day; it also accounts for the amount of time you're inevitably spending "ramping down" from one project before "ramping up" to the next, and for the complexity that client is adding to your schedule. It also acknowledges the fact that virtually anything you could be doing for them is worth at least one billable day.
What I find most amusing about discussions like this is the stridency of opposition to 1-day minimums. Freelancers on HN are, frequently, proud of the fact that they're screwing themselves, and proud that they're leaving money on the table.
You've defined it to mean "extracts from the relation, at all feasible cost, the maximum amount of value for the client".
That's not what "fair" means. "Fair" means that both the client and the consultant agree that the terms of the engagement are equitable: that the consultant is being compensated in accordance with the value they're generating.
The clients you want to work with will universally agree that, absent some other arrangement, it is "fair" to establish a minimum billable increment of a full day. That full day increment accounts for the cost to you, the consultant, in terms of lost flexibility and opportunity to serve other clients for the remainder of that day; it also accounts for the amount of time you're inevitably spending "ramping down" from one project before "ramping up" to the next, and for the complexity that client is adding to your schedule. It also acknowledges the fact that virtually anything you could be doing for them is worth at least one billable day.
What I find most amusing about discussions like this is the stridency of opposition to 1-day minimums. Freelancers on HN are, frequently, proud of the fact that they're screwing themselves, and proud that they're leaving money on the table.
> being compensated in accordance with the value they're generating.
I think the above phrase is the key to understanding "per-day" vs "per-hour" billing thinking.
I suspect most developers don't think in terms of value they're generating--partly because they don't know the value they are generating.
It's easier to think that you're billing based on "how long I'm sitting in front of the computer typing" rather than "how much value I'm generating" because then you don't need to think about how much value you are generating.
From a client's point of view, they're never paying for you to sit in front of a computer, they're paying for the value you're providing to them.
I suspect part of the issue is that "per-day" still seems like a measure of time not a measure of value.
I think the above phrase is the key to understanding "per-day" vs "per-hour" billing thinking.
I suspect most developers don't think in terms of value they're generating--partly because they don't know the value they are generating.
It's easier to think that you're billing based on "how long I'm sitting in front of the computer typing" rather than "how much value I'm generating" because then you don't need to think about how much value you are generating.
From a client's point of view, they're never paying for you to sit in front of a computer, they're paying for the value you're providing to them.
I suspect part of the issue is that "per-day" still seems like a measure of time not a measure of value.
Don't be smug and insinuate I am screwing myself. I am also not against daily or weekly rates. I think they are great. But so is hourly.
Working in a development role, the amount of time I put in on a project is highly correlated with the amount of value I add to a project. If I work every day for a year on a project, I will likely provide more value than if I worked a month. If I work every day for a month, I will likely provide more value than if I worked a week. And so on.
The amount of value added for the sake of compensation gets really tricky, but that's why freelancers have a best guess hourly/daily/weekly rate.
Therefore, over a period of time for a given client, I find it silly to assume a day where I show up, change a line of code, and go home is of the same value where I put in a full 8 hours of work. Equally silly would be a client suddenly finding themselves in a tough spot and needing some extra hours put in and me going uncompensated for the extra value added.
A daily rate works great when all days are relatively equal in productivity/time or your necessary threshold for showing up for a client is much higher than an hour or two of work. Mine is not. And it's not because the client is screwing me or I'm accidentally leaving money on the table, but because sometimes I just want to go home and not work a full day. A client should not pay for that.
Working in a development role, the amount of time I put in on a project is highly correlated with the amount of value I add to a project. If I work every day for a year on a project, I will likely provide more value than if I worked a month. If I work every day for a month, I will likely provide more value than if I worked a week. And so on.
The amount of value added for the sake of compensation gets really tricky, but that's why freelancers have a best guess hourly/daily/weekly rate.
Therefore, over a period of time for a given client, I find it silly to assume a day where I show up, change a line of code, and go home is of the same value where I put in a full 8 hours of work. Equally silly would be a client suddenly finding themselves in a tough spot and needing some extra hours put in and me going uncompensated for the extra value added.
A daily rate works great when all days are relatively equal in productivity/time or your necessary threshold for showing up for a client is much higher than an hour or two of work. Mine is not. And it's not because the client is screwing me or I'm accidentally leaving money on the table, but because sometimes I just want to go home and not work a full day. A client should not pay for that.
Note that most labor laws require workers be paid for a 3 hour minimum. If you get called in for 10 minutes, you get paid for 3 hours. If you get called in at certain inconvenient times, your wage skyrockets. This applies to unskilled labor jobs. Think about why that is. There is much more to "value" than the total number of minutes you warm a chair.
If it is possible to be smug while telling someone "you're worth more than you're charging clients", guilty as charged.
You're not against weekly billing. Ok. I am against hourly billing. The logic I perceive in your argument is, "the client is paying me for X amount of code". I'm telling you that that's not all they're paying you for.
You're not against weekly billing. Ok. I am against hourly billing. The logic I perceive in your argument is, "the client is paying me for X amount of code". I'm telling you that that's not all they're paying you for.
The client isn't paying me for lines of code added (I would often lose money if that were the case!), but they are clearly looking for me to add some sort of value. Otherwise I could just show up every day, give out some fist bumps, and go home while billing my daily rate.
Since directly measuring value added for the sake of compensation is not so straightforward, freelancers use rates (for better or worse). My argument is, the more <measurement of time> I work, the more likely I will add the value the client is looking for. Since I like a lot of flexibility in my schedule and want to still bill fairly (for both the client and myself), I use hours as my <measurement of time>.
Since directly measuring value added for the sake of compensation is not so straightforward, freelancers use rates (for better or worse). My argument is, the more <measurement of time> I work, the more likely I will add the value the client is looking for. Since I like a lot of flexibility in my schedule and want to still bill fairly (for both the client and myself), I use hours as my <measurement of time>.
If you work for 7 hours and 58 minutes, do you give them a two-minute discount out of a sense of fairness? Probably not. patio11 and tptacek's point is that for the kind of clients you probably want, a three-hour discount is not significantly more "optimal" than a two-minute discount. If the client agrees to a minimum billing increment of a day and you are doing the work you're paid to do, then it's fair. If you give them more than that, what you're being isn't fair, it's generous.
Actually, "generous" isn't even the word I would use.
The clients you want are paying for (a) determinism and (b) flexibility. They can't achieve (a) and (b) with full-time hires; they'd either face uncertain expenses in ramping up people (and possibly hiring bad people), or they'd be locked in to paying for a particular basket of skills full-time for a year.
If you are providing determinism and flexibility, real clients don't care whether the number of hours you bill is 1 or 8. For most projects and most values of "hours" below, say, 40, the end result is cost effective compared to full-time hires. The client is happy to have a slot into which they can push dollars and have a predictable amount of working software come out the other end.
So, back to "generous": when you set yourself up for sub-1-day billing, you're doing a bunch of stuff that doesn't generate value for the customer. You're giving them "loose change" invoice amounts that don't impact their budgets. You're forcing them to think about the amount of loose change you're giving them. You're setting yourself and your client up for potential disputes --- any dispute is going to cost the client something commensurate with a billable day anyways. And you're burning yourself out by working harder for less money, which the client doesn't want; they want to know that 2 years from now, the same slot will still be there, accepting dollars and spitting out working software.
This discussion obviously stumbles across some nerdthink neural tripwire. "I worked for an hour, I should bill an hour!" That's perfectly understandable nerd reasoning. If it helps to translate nerdthink into business language, think about the minimum 1-day billing increment as a way of expressing your bill rate properly; you're not "billing for time you didn't work", you're just doing a variable bill rate in which a 1-hour project costs 8 times as much as an 8-hour project. Or something like that.
The clients you want are paying for (a) determinism and (b) flexibility. They can't achieve (a) and (b) with full-time hires; they'd either face uncertain expenses in ramping up people (and possibly hiring bad people), or they'd be locked in to paying for a particular basket of skills full-time for a year.
If you are providing determinism and flexibility, real clients don't care whether the number of hours you bill is 1 or 8. For most projects and most values of "hours" below, say, 40, the end result is cost effective compared to full-time hires. The client is happy to have a slot into which they can push dollars and have a predictable amount of working software come out the other end.
So, back to "generous": when you set yourself up for sub-1-day billing, you're doing a bunch of stuff that doesn't generate value for the customer. You're giving them "loose change" invoice amounts that don't impact their budgets. You're forcing them to think about the amount of loose change you're giving them. You're setting yourself and your client up for potential disputes --- any dispute is going to cost the client something commensurate with a billable day anyways. And you're burning yourself out by working harder for less money, which the client doesn't want; they want to know that 2 years from now, the same slot will still be there, accepting dollars and spitting out working software.
This discussion obviously stumbles across some nerdthink neural tripwire. "I worked for an hour, I should bill an hour!" That's perfectly understandable nerd reasoning. If it helps to translate nerdthink into business language, think about the minimum 1-day billing increment as a way of expressing your bill rate properly; you're not "billing for time you didn't work", you're just doing a variable bill rate in which a 1-hour project costs 8 times as much as an 8-hour project. Or something like that.
One productivity hack that I've used a few times is to flip it around. Rather than track work time - I track non-work time.
I set aside 20 hours (or whatever) of coding time for a project during the week - and then track all the things that stop me doing that and subtract it from the total.
By focusing on tracking the interruptions rather than the work - the impact of poor multi-tasking/poor-scheduling becomes much more obvious.
[Edit: And in case it wasn't obvious - the time is tracked for me, not the client]
I set aside 20 hours (or whatever) of coding time for a project during the week - and then track all the things that stop me doing that and subtract it from the total.
By focusing on tracking the interruptions rather than the work - the impact of poor multi-tasking/poor-scheduling becomes much more obvious.
[Edit: And in case it wasn't obvious - the time is tracked for me, not the client]
This is an excellent idea.
That's exactly what I do for long term clients with open ended projects. I use Freshbooks' timer to track my time. Whatever that totals to is what gets billed.
For close-ended projects I generally quote up front and track my time for my own purposes. For scope changes and other additional expenses I often use a timer and bill actual time.
For close-ended projects I generally quote up front and track my time for my own purposes. For scope changes and other additional expenses I often use a timer and bill actual time.
Depends on the project and client. If the client cares at all, I just write down how long something took. If it's 1.05 hours, so be it.
BUT... I don't generally do anything that isn't at least a half day, totaled up. But if I do 3 things in that half day, I find some clients benefit from seeing how much time each thing took. It helps them to get more realistic about their time expectations. Other clients could give a toss, and for them, I just send a one line invoice: "Web development: $x,xxx"
BUT... I don't generally do anything that isn't at least a half day, totaled up. But if I do 3 things in that half day, I find some clients benefit from seeing how much time each thing took. It helps them to get more realistic about their time expectations. Other clients could give a toss, and for them, I just send a one line invoice: "Web development: $x,xxx"
I round to the nearest quarter hour, and yes I time things exactly. If I stop working to browse the web I'll pause the clock. At the end of the day I'll round the time to the nearest 15 minutes and record it.
This is a pretty good post; the latter half, I think, probably applies well to all solo consulting practices.
I particularly liked how flexible her thinking was on billing. "Hourly, with a cap" is one good way to do it; we tend to do "flat rate, fixed schedule" to similar effect. My only critique is with using "hourly" as your time quantum. Hourly sucks. It's probably some kind of standard in design, but even if you're a designer, I recommend pushing it at least to "daily".
Has anyone else here obtained a "line of credit" (say from a bank)? Do we think she just means "get an Amex card"?
Two other points I'd add:
* Incorporate: LLCs are (very) cheap and absorb most of the risks that are most likely to bankrupt you or take your house away.
* Get an accountant. Less cheap, but almost certainly cheaper than doing your taxes yourself; in several of the last 7 years, my accountant has made me money.
I particularly liked how flexible her thinking was on billing. "Hourly, with a cap" is one good way to do it; we tend to do "flat rate, fixed schedule" to similar effect. My only critique is with using "hourly" as your time quantum. Hourly sucks. It's probably some kind of standard in design, but even if you're a designer, I recommend pushing it at least to "daily".
Has anyone else here obtained a "line of credit" (say from a bank)? Do we think she just means "get an Amex card"?
Two other points I'd add:
* Incorporate: LLCs are (very) cheap and absorb most of the risks that are most likely to bankrupt you or take your house away.
* Get an accountant. Less cheap, but almost certainly cheaper than doing your taxes yourself; in several of the last 7 years, my accountant has made me money.
About line of credit: she is Canadian, and in Canada line of credit is a revolving debt instrument pretty much like credit card, but with lower rate and no card attached to it, so it is less convenient to pay from it. This is designed for medium-ticket one-off purchases, like say TV or washing machine.
Wow, I had no idea that was just a Canadian thing. What do Americans do?
It isn't just Canadian. The French do it that way too. Interestingly, you can also have a credit card without having a line of credit associated with it, at least in France, I don't know if it's the same in Canada... I personally have an Amex and a Visa card, both linked to the same bank account, which has no line of credit.
Europeans do the same, btw. It's very uncommon to have a credit card that is not attached to a bank account in Europe (Netherlands, Germany).
I don't know if this is uncommon, but on both business checking accounts (in the US) I've set up, I asked for and got attached lines of credit. Basically, it lets you bounce above and below a zero balance in case your cash flow is tight. You could certainly use it to get yourself into trouble, but I didn't and it was very useful.
Business with significant capital get loads secured against that capital. Smaller or low-overhead businesses get loans personally guaranteed by the company officers (often against their personal assets) Or they get by with corporate credit cards (which they used to hand out like candy at the doctor's office) and work out separate payment terms with the vendor for any bigger-ticket items.
Those corporate credit cards are still pretty easy for an individual to get because they don't fall under the same bankruptcy laws as personal cards.
Bank loans are all but unobtainable by many (most?) fledgling entrpreneurs. Credit cards fill the gap.
If you have a good enough credit score, one stategy is to continually try to transfer your balance to new cards with low (0% if you're lucky) introductory rates, while paying the minimum monthly requirement.
If you have a good enough credit score, one stategy is to continually try to transfer your balance to new cards with low (0% if you're lucky) introductory rates, while paying the minimum monthly requirement.
You can get a line of credit in america too. Especially if you have a house, those are called "Home equity lines of credit" - very common.
The work like checking accounts in reverse, you write a check off of the account to pay for things (or do a bank transfer), and you send them money to pay it down.
You can also get unsecured lines of credit but those are harder to find.
The work like checking accounts in reverse, you write a check off of the account to pay for things (or do a bank transfer), and you send them money to pay it down.
You can also get unsecured lines of credit but those are harder to find.
While I generally agree with and recommend getting an accountant, I've found a personal satisfaction over the past 8 years of doing my own taxes (10 years of freelance development). It can be tedious and confusing, but it forces me to stay in tune with the laws as well as my own income / expenses.
It doesn't hurt that it costs far less than an accountant, although that time can be considered lost considering the billable time lost gathering information, adding it all up and entering it properly (Mint.com has shaven days off of this process for me).
Every year I tell myself I'll go back to having an accountant, but then I feel I'll miss that couple days of better understanding where my money came from and where it's gone. I also appreciate understanding the details behind the chunk I send to Uncle Sam.
It doesn't hurt that it costs far less than an accountant, although that time can be considered lost considering the billable time lost gathering information, adding it all up and entering it properly (Mint.com has shaven days off of this process for me).
Every year I tell myself I'll go back to having an accountant, but then I feel I'll miss that couple days of better understanding where my money came from and where it's gone. I also appreciate understanding the details behind the chunk I send to Uncle Sam.
Some people are like you. I suspect more people are like me. If you're not sure whether you're going to enjoy / be good at doing your own taxes, screwing them up is not a good way to find out. I managed to get myself into quite an annoying hole by not delegating this particular business problem.
I asked my lawyer about this when setting up my LLC. He told me to get an accountant for the first year, watch what they do, and then you'll be able to do it yourself every year after that.
Interesting perspective. +1 for using Mint.com for business - my partner set us up and it's a great way to get a global view of the inflows and and outflows.
I've gone the opposite route (hired an accountant) and feel I have a much better understanding of what's going on than when I did it myself. I have the accountant walk me through everything - no more guessing my way through Turbotax and having an anxiety attack each April.
I've gone the opposite route (hired an accountant) and feel I have a much better understanding of what's going on than when I did it myself. I have the accountant walk me through everything - no more guessing my way through Turbotax and having an anxiety attack each April.
> Get an accountant.
This is where I specifically fumble on. From all the research I've tried to do online, I'm still not sure how to look for an accountant. Are there different types that specialise in the work that freelancers/contractors do? Is there a specific title that I should research? etc.
This is where I specifically fumble on. From all the research I've tried to do online, I'm still not sure how to look for an accountant. Are there different types that specialise in the work that freelancers/contractors do? Is there a specific title that I should research? etc.
Accountants are like mechanics. You are only going to find a good one by word of mouth... and even then you have check to make sure that he fits your business. You should approach an accountant like a job candidate; ask questions about his business practices and those that pertain to your business.
I found my accountant through a network of co-workers that all have the same type of freelancing business (single founder; very few clients). I know he makes a lot of money doing my taxes, but he ends up saving me more money than what he's charging me and keeps me worry-free with regard to the CRA (IRS; US-equivalent).
If you are in the Vancouver area, I can recommend a good accountant that works with small/micro businesses. Hit me up on Twitter.
I found my accountant through a network of co-workers that all have the same type of freelancing business (single founder; very few clients). I know he makes a lot of money doing my taxes, but he ends up saving me more money than what he's charging me and keeps me worry-free with regard to the CRA (IRS; US-equivalent).
If you are in the Vancouver area, I can recommend a good accountant that works with small/micro businesses. Hit me up on Twitter.
One of the main differences in accountants is risk tolerance. Freelancers have considerable leeway in the way they structure their taxable income and accordingly can have considerable variation in their risk of an audit. Make sure you interview a couple accountants and try to find an accountant whose risk tolerance matches your own. Don't expect that a big firm will be more conservative than a small one--the opposite is often the case.
I would suggest finding someone who's trusted in working with local small businesses - probably themselves a small local shop with a few accountants - ask your hardware store owner, coffee shop owner, etc. If you are within a taxing municipality it can be helpful to have someone who knows the local ins and outs.
Generally speaking, the tax implications of being a freelancer are less complicated than small scale retail (e.g. no inventory).
Generally speaking, the tax implications of being a freelancer are less complicated than small scale retail (e.g. no inventory).
But note that the tax implications of being a freelancer are way more complicated than those of being a W2 worker.
I learned this lesson the hard way several years ago.
I can't stress enough the importance of making sure wherever you go isn't a place that just rubber-stamps W2 returns.
I made the mistake of going to H&R Block during the year I was 1099'ing, and aside from the person doing my return having to go ask someone for guidance at every line item on the forms, I ended up getting a letter in the mail from the state saying that they'd calculated I overpaid by a few grand.
I can't even fathom how bad of a job they must have done, if the state was the one to inform me that I'd given them too much money.
I can't stress enough the importance of making sure wherever you go isn't a place that just rubber-stamps W2 returns.
I made the mistake of going to H&R Block during the year I was 1099'ing, and aside from the person doing my return having to go ask someone for guidance at every line item on the forms, I ended up getting a letter in the mail from the state saying that they'd calculated I overpaid by a few grand.
I can't even fathom how bad of a job they must have done, if the state was the one to inform me that I'd given them too much money.
My account finding tip would be to avoid focusing on the amount that they charge, but get references and find out how much money they saved their clients. Cheap accountants generally provide less value in my experience.
My company has a line of credit from our bank. Thankfully, we've only had to draw heavily on it once, but it was a life saver at the time.
We had a situation where we simultaneously hired new employees, kicked off several sizable consulting projects and were stuck with late payments on several projects. As a result we were cash-flow negative for several months. Drawing on the line of credit helped keep payroll, AP, etc running smoothly. As a small company it's a nice low cost way to have ready access to money which you can use for anything (not just purchases).
With decent credit we were able to get a line capped at about 1/6th of our yearly revenues with a ~4.25% interest rate. This was a much higher limit and better rate that we could get with AMEX advances. The only downside is the amount time and paperwork involved, since you generally need to provide tax returns, P&L, balance sheets, AR statements, and go through lengthy approval process.
We had a situation where we simultaneously hired new employees, kicked off several sizable consulting projects and were stuck with late payments on several projects. As a result we were cash-flow negative for several months. Drawing on the line of credit helped keep payroll, AP, etc running smoothly. As a small company it's a nice low cost way to have ready access to money which you can use for anything (not just purchases).
With decent credit we were able to get a line capped at about 1/6th of our yearly revenues with a ~4.25% interest rate. This was a much higher limit and better rate that we could get with AMEX advances. The only downside is the amount time and paperwork involved, since you generally need to provide tax returns, P&L, balance sheets, AR statements, and go through lengthy approval process.
I'm not sure about all banks, but my credit union offers an unsecured line of credit for up to about $10k with a rate around 9%. They go a little higher for small businesses.
If you're looking for a cushion to reduce the impact of receivables, it's a good option.
If you're looking for a cushion to reduce the impact of receivables, it's a good option.
At the mega-bank in my neighborhood, they try really hard to sell a line of credit to every business customer, even if it's only a couple thousand dollars. Their standard small business application package has a checking account, savings account, debit card, and credit card and then they try to up-sell a line of credit.
If you're freelancing, you need to read Design Is a Job by Mike Monteiro. It's an absolutely brilliant overview of the entire client/contractor relationship, and how to operate in a way that protects both you and your client from any potentially hairy situations. Can't recommend it enough.
http://www.abookapart.com/products/design-is-a-job
http://www.abookapart.com/products/design-is-a-job
Every time I read about this book I really want to buy it, but I hesitate because I'm not a designer; how designer-specific is it? Like, the drama involved in getting clients to accept a creative brief is interesting, but it's not very relevant to what I do.
It's not designer specific. It feels more like the word 'designer' is being used in terms of being a creative, rather than specifically a graphic specialist. So it applies to freelancers who invent, but doesn't touch developers issues either, so its weighted to professionals who need taste to acomplish their job. It's a good book, I like Monteiro's no-BS approach to things.
I just finished the book and while it's weighted toward designers, a lot of the lessons can apply to various industries. Namely: dealing with clients, negotiating contracts, getting paid on time, and the importance of developing a working and business process.
Go buy it.
Go buy it.
Post seems pretty enlightening, makes me wish I could find something similar regarding software development specifically.
The "Fuck You. Pay Me." slide aggravates me. No matter how you dress it up with asterisks, you're still swearing and showing a lack of class. I agree that a large part of freelancing is making money (getting paid), but there are nicer ways to say it. The rest of the presentation is really well put together, but this particular slide seems out of place.
This is a reference to an infamous talk given by Mike Monteiro who's infamous in the design community.
http://www.youtube.com/watch?v=vZGra65Nob4
http://www.youtube.com/watch?v=vZGra65Nob4
Which in turn was a reference to Goodfellas:
http://www.youtube.com/watch?v=5ydqjqZ_3oc
http://www.youtube.com/watch?v=5ydqjqZ_3oc
I'm not sure why he or the talk is considered infamous. (Full version here: http://vimeo.com/22053820) When a client orders work to be done, that work should be billed as agreed and then the client should pay for the work they ordered. In design and web development, there seems to be some moral confusion among some clients whether they actually have to pay for the work the ordered. The speaker argues, and I believe rightly so, that this is bullshit.
Heh yeah, I was referring to the Mike Monterio talk. But in the actual talk that I'm giving at the school I changed it to "Hey you. Pay me" if that makes you feel better?
"Fuck You. Pay Me." is a pretty well established philosophy, not just a curse word.
https://vimeo.com/22053820
https://vimeo.com/22053820
The only thing that aggravates me about it is that she put an asterisk in "Fuck" as if it makes some kind of a difference.
If you actually read the article, you will see that the slide that you're referring to is sarcastic. The actual text just says the facts and is not laced with profanity or emotional words.
The biggest mistake I made when I started freelancing is I had NO plan on how to take care of maintenance after I closed up shop.
Websites are living business cards that are almost always changing. So when you take on 5 projects over a year. You're never really going to get away from them. They are perpetual. You will always get calls later on about "fixing this" and "changing that". And if you think you can simply give the client all the code so they can go on to someone else, it's not that easy. Especially if you're hosting everything for them (which I now understand is a big mistake). Clients don't understand code well enough to be able to do that, and the changes they need are sometimes so vital to their business, you'd feel like an asshole for not giving in. Sure you can charge them for the changes but again: If you get busy later on in life you'll always be haunted by your former clients. It's hard to let go.
Learn from my stupid mistake. Before you even create index.php create a plan on what you're going to do when you get sick of freelancing. Set everything up around the idea that one day you will need to pass this all onto someone else.
Websites are living business cards that are almost always changing. So when you take on 5 projects over a year. You're never really going to get away from them. They are perpetual. You will always get calls later on about "fixing this" and "changing that". And if you think you can simply give the client all the code so they can go on to someone else, it's not that easy. Especially if you're hosting everything for them (which I now understand is a big mistake). Clients don't understand code well enough to be able to do that, and the changes they need are sometimes so vital to their business, you'd feel like an asshole for not giving in. Sure you can charge them for the changes but again: If you get busy later on in life you'll always be haunted by your former clients. It's hard to let go.
Learn from my stupid mistake. Before you even create index.php create a plan on what you're going to do when you get sick of freelancing. Set everything up around the idea that one day you will need to pass this all onto someone else.
But on the other hand, you've created customers that are practically guaranteed to produce repeat business dollars.
How do you handle that sort of thing? Is there a cut-off or something? I've never done any web development, but I can see how this would be a hairy situation.
You put it in your contract - it should be crystal clear. If at some point, you don't want to continue (i.e. extend your contract), just refer them to another developer. It's not that big a deal.
Oh it's quiet a big deal when you're not set up for it from the beginning, and it costs you time and money to transfer your client to another developer.
When you handled everything for your client from domain registration to hosting to ftp and email accounts and some of the scripts require relative URLs (relative to your hosting account's directory on your hosting company's server) and their mysql databases are with you. Surprise! You've got a few hours to a few days of work ahead of you. Sure you can charge the client. But again, if you're sick of that shit you can't just ditch them. If the other developer wants to do it, they can't because there's no way you'd give them admin access to your server. And since you're on a shared hosting server you don't have the privileges to create a temporary admin account that only allows access to the things that need to be transferred. You're stuck doing all this work.
If you want to get rid of the client you now have to oversee that all these things are successfully transferred. And no one can do this but YOU. The more complex the client's site the more of a pain in the ass things become. Things add up quickly.
Oh, Just a few things you need to do. :)
- make backups of absolutely everything
- Transfer the domain (up to 7 days)
- Setup and reteach the client their ftp details
- transfer email accounts and if they have an IMAP account, have fun backing up all their emails and attachments and transferring them to the new IMAP acount. Same applies to an archiving POP3 email account.
- Go into all 3rd party scripts and reinstall everything
- change all relative paths on all of those 3rd party scripts as well as changing the mysql details (some scripts aren't simple "drag and drop then reinstall" scripts) they are instead a pain in the ass to migrate because certain options aren't stored in the mysql database that you just backed up. Instead they're in the filesystem and you have to back that up and drag and drop everything over, and if you re-install it you lose all those settings so you have to spend a whole day planning out what exactly needs to be dragged and dropped over.
- transfer all backups little by little to their new destination
- transfer over all the mysql databases
- RE-train your client to understand ALL of these new changes and answer any support emails when they have problems or something is wrong. (NO they won't send emails to the new developer, they'll send them to you)
- Answer emails from the new developer who doesn't understand exactly how everything was done.
And a lot of this requires everything at the other host to be somewhat setup, which requires a bit of cooperation between you and the new developer. And when it takes most people 5 days to respond to an email because they're overloaded with work (something I'm guilty of right now). A complete transfer after ironing out all the kinks could take over a month.
If you were smart and planned ahead you would have just created a whole self contained account with a host and had everything wrapped up together so when you transfer your client to a new developer you just hand the new developer the admin username and password to the control panel and leave. But you didn't. You're Chris Norstrom and you're new to this crap and so you did things the wrong and long way. ;)
When you handled everything for your client from domain registration to hosting to ftp and email accounts and some of the scripts require relative URLs (relative to your hosting account's directory on your hosting company's server) and their mysql databases are with you. Surprise! You've got a few hours to a few days of work ahead of you. Sure you can charge the client. But again, if you're sick of that shit you can't just ditch them. If the other developer wants to do it, they can't because there's no way you'd give them admin access to your server. And since you're on a shared hosting server you don't have the privileges to create a temporary admin account that only allows access to the things that need to be transferred. You're stuck doing all this work.
If you want to get rid of the client you now have to oversee that all these things are successfully transferred. And no one can do this but YOU. The more complex the client's site the more of a pain in the ass things become. Things add up quickly.
Oh, Just a few things you need to do. :)
- make backups of absolutely everything
- Transfer the domain (up to 7 days)
- Setup and reteach the client their ftp details
- transfer email accounts and if they have an IMAP account, have fun backing up all their emails and attachments and transferring them to the new IMAP acount. Same applies to an archiving POP3 email account.
- Go into all 3rd party scripts and reinstall everything
- change all relative paths on all of those 3rd party scripts as well as changing the mysql details (some scripts aren't simple "drag and drop then reinstall" scripts) they are instead a pain in the ass to migrate because certain options aren't stored in the mysql database that you just backed up. Instead they're in the filesystem and you have to back that up and drag and drop everything over, and if you re-install it you lose all those settings so you have to spend a whole day planning out what exactly needs to be dragged and dropped over.
- transfer all backups little by little to their new destination
- transfer over all the mysql databases
- RE-train your client to understand ALL of these new changes and answer any support emails when they have problems or something is wrong. (NO they won't send emails to the new developer, they'll send them to you)
- Answer emails from the new developer who doesn't understand exactly how everything was done.
And a lot of this requires everything at the other host to be somewhat setup, which requires a bit of cooperation between you and the new developer. And when it takes most people 5 days to respond to an email because they're overloaded with work (something I'm guilty of right now). A complete transfer after ironing out all the kinks could take over a month.
If you were smart and planned ahead you would have just created a whole self contained account with a host and had everything wrapped up together so when you transfer your client to a new developer you just hand the new developer the admin username and password to the control panel and leave. But you didn't. You're Chris Norstrom and you're new to this crap and so you did things the wrong and long way. ;)
Ouch.
Could you not build up a network of people who you would trust to do a decent job of maintaining the website after you moved on? Then recommend these others to clients if the need arises.
I know some developers will offer "understudy" type services where the code is always available to at least 2 developers. One will do the majority of the work and the second will simply look at changes incase they need to take over.
I know some developers will offer "understudy" type services where the code is always available to at least 2 developers. One will do the majority of the work and the second will simply look at changes incase they need to take over.
This is one of the biggest reasons I've decided to focus on native apps. No server to maintain.
real gem, in the mix. Oh, the definites, very.
Thanks for the Joey Tribbiani strictness.
Of course we are not supposed to reply to spam, but this has me curious and amused. Why is there a markov bot posting on HN? In hopes that it will be coherent enough to get enough upvotes to be useful to someone?
Learning to say no is one of the most important things IMHO.
In the Discworld books, there's a bit where the Best Smith In The World shoes Death's horse. It's a thing he HAS to do now and then, because otherwise, well, he's just not the Best Smith In The World anymore, is he? It's a little weird and unsettling, but he does it, and he does it well.
Every now and then a job comes along that makes me feel like that. It's something that the client is coming specifically to ME for, not just because they like my style but because I am one of about three people in the world who could do justice to this idea. And when one of those comes along, I make room in my schedule for it. I warn the client that it may take a while - but it'll be worth the wait.
But most of the time? Most of the time, I politely say "no". Once you've gotten your head above water, this is not a luxury; keeping your workload under control and not having twenty unfinished projects hanging over your head makes you AND your clients happy.
(Underpricing yourself is also a terrible idea, and one this piece doesn't address. Most of the stories of nightmare art commissions my friends tell are of a too-cheap piece where the client demands endless re-dos for free.)
In the Discworld books, there's a bit where the Best Smith In The World shoes Death's horse. It's a thing he HAS to do now and then, because otherwise, well, he's just not the Best Smith In The World anymore, is he? It's a little weird and unsettling, but he does it, and he does it well.
Every now and then a job comes along that makes me feel like that. It's something that the client is coming specifically to ME for, not just because they like my style but because I am one of about three people in the world who could do justice to this idea. And when one of those comes along, I make room in my schedule for it. I warn the client that it may take a while - but it'll be worth the wait.
But most of the time? Most of the time, I politely say "no". Once you've gotten your head above water, this is not a luxury; keeping your workload under control and not having twenty unfinished projects hanging over your head makes you AND your clients happy.
(Underpricing yourself is also a terrible idea, and one this piece doesn't address. Most of the stories of nightmare art commissions my friends tell are of a too-cheap piece where the client demands endless re-dos for free.)
wow. thank you for that helpful post!
> You’re not your own boss, you’ve got about 30 different bosses
As a freelancer, you get to choose those bosses. Much harder to do at a regular job.
> If you’re not on twitter, it reflects poorly on you. The design community is strongly linked to the start-up and web-dev communities.
Minor nitpick: Our design community is strongly linked to the start-up and web-dev community. But other design communities exist outside of the software world :)
Good information in the article. Shared it with friends who are getting started with freelancing. I'm sure they're in a better position now than me, when I was starting out.
As a freelancer, you get to choose those bosses. Much harder to do at a regular job.
> If you’re not on twitter, it reflects poorly on you. The design community is strongly linked to the start-up and web-dev communities.
Minor nitpick: Our design community is strongly linked to the start-up and web-dev community. But other design communities exist outside of the software world :)
Good information in the article. Shared it with friends who are getting started with freelancing. I'm sure they're in a better position now than me, when I was starting out.