Everything I wish someone had told me (about freelancing)
megrobichaud.tumblr.com
megrobichaud.tumblr.com
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.
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.
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.
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.
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.
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.
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.
Generally speaking, the tax implications of being a freelancer are less complicated than small scale retail (e.g. no inventory).
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.
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.
If you're looking for a cushion to reduce the impact of receivables, it's a good option.
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.
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. ;)
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.
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.)
Go buy it.
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.
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!)
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.)
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.
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.
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, 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.
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.
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.
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.
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.
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.
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.
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.
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.
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>.
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.
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]
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.
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"
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.