Didn't expect this note at the end, but what a good move:
> Give back to the tools that make you successful - I give a percentage of my earnings every year to support software tools that help me do my job - iTerm2, Vim, Go, Postgres, Node.js, Python, nginx, various other open source projects.
I agree for the most part, but the trick is knowing what the inputs are in the first place. A software consultant may miss a critical primary input such as WHO is actually signing the contract.
I've seen instances whereby a contract was signed between a colleague and his client, but the signature was between him and the signing agent, and not the company per se, so when the guy that contracted him suddenly left the company, the contract was declared null and void even though it was halfway through. He thought he signed with the company, but legally he only signed with the representative as laid out in the preliminary parties clause.
Lawyers are trained to spot those gotchas, much as developers can spot "off by one" errors in computer code instinctively.
Given the motivation to read and learn, a developer can read and modify legal 'code' just as easily as a lawyer can read and modify software 'code'. The question is what exceptions are thrown at compile time? In most SW stacks, you find out where your errors are pretty quickly. Unfortunately with legal code, "compile time" may not occur until the code is executed in a court of law. Are you sure that's when you want to do your debugging?
It seems the implication here is that the contractor has a rather severe and enforceable penalty for not receiving payment on time, which also makes it easier to collect a late fee. You may not always choose to exercise this option, but having it in your back pocket can deter some sketchy behavior on a client's part.
If you don't have it in writing, the case or settlement may take longer to resolve, which means you'll have to cough up more in lawyer's fees, which means the client may be more willing to bet you won't pursue legal action.
With that said - in many cases lawyers from the other side would fight to remove "AND ON TIME" wording. Which is somewhat OK (delays do happens), but "IN FULL" should be firm and present.
Same experience. In fact I have never signed a contract that wasn't modified in some way. Actually there was one exception: a very large Pacific Northwest based company. Their standard consulting agreement was very fair, I imagined due to a desire to reduce "legal support costs" that would arise from prospective vendors constantly requesting the same set of edits. Probably also for fear of future litigation.
> Their standard consulting agreement was very fair, I imagined due to a desire to reduce "legal support costs" that would arise from prospective vendors constantly requesting the same set of edits.
That was our motivation at BindView (now part of Symantec) for developing what many customers' lawyers said was the greatest vendor contract they'd ever seen: We didn't want to spend our time repeatedly negotiating the same T&C changes like gerbils in a wheel. This was especially true as the game clock was running down at the end of the fiscal-reporting quarter. [0]
Not sure about funny looks in Africa, but I'm European myself.
In Europe contracts tends to be more on a "fair" side of equation (less opportunistic sneaky clauses but more in-your-face bummers).
In North America the initial paperwork scale quality greatly depends on absurdity levels of lawyers at the other side (lawsuit-prone enterprises, large corps with unlimited budgets "just because they can" and heavily regulated industries claiming "this is industry-standard contract" BS).
In my past - after prolonged, fruitless battle with IBM lawyers - I accepted all [ridiculous] IBM terms and was rewarded with 5 yrs of doing well-paid, WFH, interesting, creative, cool stuff.
So there is no hard and fast rules - go with your gut sometimes is a best advice.
"Read contract yourself then get back to company and request to either remove all one-sided clauses or make them equally two-sided."
I did that not too long ago, to a potential client. The client's response was "Well we have used this standard contract with other freelancers and they have never complained about it. Take it or leave it" I left that client.
I've had that response but I wanted the work and pushed back with my reasons. Turned out the directors just hadn't really ever read it and everyone else had just signed it.
Opened up a good conversation, and we all signed something we were happy with.
Piggybacking on this, here's a talk I couldn't possibly recommend enough, in which Mike Monteiro discusses the importance of 1) an attorney and 2) contracts in freelance work (40min):
Charging for a full week will make you lose a lot of clients. In the case of software development: The client never knows the full spec of the project and you'll have weeks were 10 hours is enough. Charging for those extra 30 hours is terrible deal for your client and he won't take it.
What you should be careful about is how much you charge per hour. You may set different rates based on context like: for a full time project project you charge X, for future maintaining (which is on demand ) you charge 1.5 times X.
Hourly also protects you agains scope creeping.
Charging by the week/project/milestones requires a near full specification and it's done at an agency level where you've a team. I've been working hourly and I love it. You can try to spec out any project as much as you can, in the end you can't predict scope changes and/or unexpected problems: API is broken, missed an important email, build system is failing for no obvious reason, server went down, etc, etc.
You have to figure out when charging by the hour/week/month/milestones is reasonable. Just because someone is making 120K a year in San Fran, doesn't mean you've to make the same amount while freelancing. It heavily swings from client to client.
I believe you'll find that overall consensus on HN will strongly disagree with you on this point.
Here's the post most people will direct you to for an explanation of why you'll want to avoid hourly billing, and how to get to a place where you don't need to bill hourly:
For what it's worth - all of the people I know who have been able to do software-related consulting successfully over the long term don't bill hourly. They'd actually agree with you that having a minimum billable period of a week lots them lots of clients - but it lost them the clients that would try to nickel and dime them to death and complain about every invoice no matter low the hourly rate was.
It sounds like your experience has been different though, so I'm happy to hear you've found something that works for you.
The HN consensus has simplified things in such a way that any shades of gray are tossed out.
When you are just starting out charging by the hour and starting with small stuff is fine. But your goal should be to transition to charging by the week as soon as you can afford it, because you can't afford to charge by the hour for your whole career.
Keep in mind that those that have 'arrived' tend to take their life experience and then condense it down to bullet points without nuance, after all, unqualified statements sound so much better than qualified ones. But it's all about the balance and to get to charging by the week you may need to start by charging by the hour.
I agree with all of this, but I'd warn that unless you really know what you're doing and what can go wrong, jumping from weekly billing to project billing can be super dangerous and you're taking on a lot of risk. Most people aren't great at locking in scope for projects, let alone estimating the work it will take once the scope is locked; once you agree to per-project billing, you've committed and are on the hook for errors on both fronts.
This is what I am currently doing...plus, since everyone loves a "deal", I charge a slightly higher hourly rate then give away "one hour FREE" because we all know that FREE is the most powerful word in marketing.
Basically, I figure out what I would be happy with for 5 hours for work and then give them 4 hours plus one FREE hour for that amount.
This has the added benefit of nudging my hourly rate higher, since I always have a hard time raising my rates.
So true. Hourly billing is BY FAR the best way to get going. I’ve swapped to weekly contracts for a few contracts but only after an extended working relationship. Most folks won’t spring for that sort of payment, especially long term. Everyone understands and gets hourly billing.
Having any rate helps to do algebra too. Clients can suppose that $x/hour ~= $8x/day ~= $40x/week ~= $1760x/year. So even if you quote an hourly rate the discussion can still be "how much should we budget for a team of ten people next year."
Maybe the correlation between hourly billing and bad projects is not causal.
I don't understand this comment as a response to your parent one. The condensed bullet point that it linked shows that dropping hourly rates wouldn't happen until step 5. As I understand it, all you describe would fall under the period of time one takes to get through 1-4
One sticking point I rarely see discussed with the prevailing line of thinking (noted by tptacek, patio11 and others), is that a week is a measure of time.
If that's true, there is only time-based billing, and project-based billing. I've done both types, and project-based billing has been much more dangerous for me due to the need to accurately scope (or eat costs), usually for a client that has no idea how difficult "simple" additions can be (and often when you yourself cannot). Software scoping is effectively impossible to do accurately, and I've found the only way to get close is when you have already built the system in question before (or better yet, have a codebase you can reuse to hit 90% of the features in the first ~week of "work").
Hourly billing (whether you roll it up into a day/week/month) provides a way to cover myself from bad estimation, but limits you to charging for time to build and screws up incentives.
Project billing means I eat costs from bad estimation, but with the possibility of reward from over-estimation, along with the fact that you can charge for what the deliverable is worth (i.e. the value you deliver, not the time it took you to build the product).
As far as weeding out clients who aren't serious -- you can do that with a high-enough hourly billing (and generally you can get a feel for this from the client themselves)...
Could someone explain how I'm understanding the avoid-hourly-billing ideas wrong? It seems reasonable but it just doesn't seem to work for me in practice with the estimation thing, never mind the fact that clients need regular updates and rarely value good software development practices (so may seem like you've spent a week doing nothing if they can't immediately see the result/how it will save them time over the lifetime of the project).
[EDIT] - Another thing that I've realized when I was last thinking about this that I didn't include was that as complexity unfolded (and I realized my estimation was wrong), I did not increase prices/communicate this effectively to the business -- maybe that's where I'm getting it wrong? It feels like it would chip away at client trust to do so.
For those who are wondering what I actually do when I take projects on these days -- I just set a high hourly rate, possibly bundle it into weeks/months, and avoid project-based estimation because of the difficulty of scoping and the likelihood of scope changes. This also gives me an edge when the scope changes -- it's no longer "can this fit", and it's more "sure we can fit this in, it will take longer though".
You'll have happier clients as well, because with experience, the buffer in project-based estimations needs to be large enough that no possible hidden complexity can deplete it (barring complete show stoppers). Clients will usually be better off with time-based billing when the per-project cost estimate would come from an experienced provider.
OK, so then in my head the advice is now: "do time-based billing but avoid hourly increments, instead opting for weekly/monthly but never disclose how many hours per week you work".
It seems inevitable that clients wonder/ask why you can't get X, Y, and Z done in a "week", when they hold a definition of what a "week" means to them. If you're billing for a week, they're going to assume you're billing for 5x8 hour days -- is the idea just to let them assume that, but you actually work however many hours it takes to get the deliverables for the week done? If so, that's basically forcing you to over estimate, or work a full work-week anyway, and then you might as well be pricing by hour (whether you show them or not).
What I've done recently is charge for X days/week, with a written agreement specifying what constitutes a "work day" for me. Clients normally don't care/micro-manage (there's enough mutual trust), and when we meet to show/discuss progress, I let them know how how "on schedule" we are (so at "based on how quickly I'm working at the current clip of 3 days/week, it looks like everything will be done in 4 weeks"). This formula would be wrong according to the usual HN advice though -- it's way too easy to translate X days/week w/ a set amount of hours that constitute a work day to X-per-hour billing.
> What I've done recently is charge for X days/week, with a written agreement specifying what constitutes a "work day" for me. Clients normally don't care/micro-manage (there's enough mutual trust), and when we meet to show/discuss progress, I let them know how how "on schedule" we are (so at "based on how quickly I'm working at the current clip of 3 days/week, it looks like everything will be done in 4 weeks"). This formula would be wrong according to the usual HN advice though -- it's way too easy to translate X days/week w/ a set amount of hours that constitute a work day to X-per-hour billing.
Why do you need that "written agreement specifying what constitutes a "work day" for me."? That sounds like it's just encouraging the client to micromanage; you don't want a client that doesn't trust that you'll do a decent week's work in a billed week. And it gives you the disadvantages of a conventional job: you're now tied to working X hours/day Y days/week rather than taking a long lunch some days, working late some days, stopping early some days, and trusting that it'll all average out.
I think that most clients in my current part of the world (Tokyo) have a set expectation of what a work day is -- normally ~8(+) hours. I have that in the agreement to avoid this misconception if a certain client expects me to be available/reachable during all of their own working hours.
Also, I do maintain flexibility in how I work the hours -- I don't say when those hours will be worked, just how many "days" are being billed per week. Sometimes I split it up over several days, and I almost always split it up into multiple chunks on a single day. This is the part I like most about the arrangement and my current lifestyle. Eventually you have to do some work, and the number of hours/day is the number I'm comfortable with working (it's less than 8).
Now this completely goes out the window for project based pricing jobs -- If I am charging for project/milestone completion, then I do not mention "work days" because they're irrelevant, there's only the deadline and whatever scheduled checkups/sync meetings, doesn't matter if I completely ignore the project for a whole week.
This comes back to my point before -- it seems to be the only real dichotomy is whether you charge for 1 unit of time (before/after the project deadline) or whether you charge for some derivative of hourly wages (due to the preconception of what a "workday" means in most people's heads).
Assuming you understood my previous point, are you suggesting that I should just leave the definition of "work day" vague? and treat a weekly contract as a project based one? I guess this could work, but it feels more to me like project based pricing split up into milestones that happen to have weekly delivery dates -- not what everyone is saying to "charge by week". And the problem there is the same -- how do you avoid/deal with bad estimation?
I think in part it depends on the type of client you're working with and the type of relationship you're building.
Non-tech/software clients (ie a business paying for custom software they're going to use themselves) care a lot about the total cost of $features, and often try to manage risk of cost overrun by treating estimates as part of the contract with the developer (even if it wasn't a fixed bid contract), and will hold you accountable to the project milestones: eg they don't care why things are taking longer - 'you should have considered that risk in the estimate - it's your fault'.
Tech customers (ie a software licensing or sass company) that use contractors to supplement their internal workforce usually understand the variability better, think of the contract more as buying the (expertise and) time of the developer, and they're managing more of the project and risk themselves. When things don't go to plan, they understand that many/most times this isn't the 'fault' of the developer, it's simply the inherent risks in the task being uncovered.
It's much simpler to arrange weekly rate contracts with the second type of customer than the first.
Just wanted to note that this is spot on -- I've found I've enjoyed working with customers in the tech sphere a lot more than non-tech/software clients.
I end up just assuming that I just don't have the tooling/skillset just yet to handle the former set of clients well yet.
> This comes back to my point before -- it seems to be the only real dichotomy is whether you charge for 1 unit of time (before/after the project deadline) or whether you charge for some derivative of hourly wages (due to the preconception of what a "workday" means in most people's heads).
No. There is a huge difference between counting hours and counting weeks in terms of how much overhead it imposes on you, and how much opportunity it gives a client to nickel-and-dime.
> Assuming you understood my previous point, are you suggesting that I should just leave the definition of "work day" vague? and treat a weekly contract as a project based one?
No. I'm saying charge time-based, but by the week rather than the hour: that is, do not quibble about the difference between 39 hours and 41 hours, and do not work for clients who want to.
We really do mean what we're saying. Charge by the week, not by the hour, really does mean charge by the week, not by the hour. No more and no less. It really does make a difference.
> No. There is a huge difference between counting hours and counting weeks in terms of how much overhead it imposes on you, and how much opportunity it gives a client to nickel-and-dime.
> No. I'm saying charge time-based, but by the week rather than the hour: that is, do not quibble about the difference between 39 hours and 41 hours, and do not work for clients who want to.
Yeah but both of these things are what bad clients do, who we agree are weeded out (usually) with higher rates.
Also "not quibbling" about the difference between 39 and 40 hours means that there is an expected amount of hours you're supposed to be working -- how does that get set? Is the answer to just not talk about it? Why wouldn't a good conscientious client ask how much time you're dedicating to the project per week, if they find your per-week scopes to be lower than what they think could be done in their idea of a work-week?
To reiterate, I think the real kernel of advice here is "charge more to weed out bad clients", and the "charge by the week" to be a red herring. Charging more is doing the hard work here, weeding out clients that might attempt to micromanage, not changing to weekly billing. When businesses have enough headroom to not worry about whether they're maximally extracting value from you, that's when they don't care how long your work week is/what scope you set for a "week".
The legal profession seems to have no problem charging by the hour, why should we?
> Also "not quibbling" about the difference between 39 and 40 hours means that there is an expected amount of hours you're supposed to be working -- how does that get set? Is the answer to just not talk about it? Why wouldn't a good conscientious client ask how much time you're dedicating to the project per week, if they find your per-week scopes to be lower than what they think could be done in their idea of a work-week?
One could say the same about minutes in an hour - if a conscientious client thinks you're not getting enough done in your billed hours, wouldn't they ask how much of that hour you're spending writing code versus coffee breaks / bathroom breaks / sitting thinking? And indeed bad clients will ask such things, but the clients you want will accept that an hour means only that the only work you did that hour was on their project (or at least, that if you bill n hours across your clients then that corresponds to n hours of clock time on which you worked on no projects outside their collective set) and that you made a good-faith effort to work for that hour. A good client can certainly decide that you're not getting enough done in the billed time and ask you to revise your rate, or ultimately stop working with you. But good clients won't ask e.g. whether you were taking too many short breaks during a billed hour, because that conversation can't ever go anywhere worthwhile.
> To reiterate, I think the real kernel of advice here is "charge more to weed out bad clients", and the "charge by the week" to be a red herring. Charging more is doing the hard work here, weeding out clients that might attempt to micromanage, not changing to weekly billing.
Not my experience - indeed I'd say a high rate billed hourly gives more encouragement to micromanage as the client tries to "get their money's worth". For my money you get less micromanagement when billing weekly even if you charge a (slightly) lower overall rate - how much precision you bill with sets an expectation for how much precision is appropriate in all your interactions. YMMV I guess.
> The legal profession seems to have no problem charging by the hour, why should we?
As per the other reply, it's a real headache there. The legal profession has lost a race to the bottom in how billing is done. I'm sure we will too in time, as developers reach market saturation. But make hay while the sun shines.
> The legal profession seems to have no problem charging by the hour
This is not true. The "billable hour" in the legal profession is a huge source of headaches for individual lawyers and the legal profession at large. The incentive is to work more, rather than work smarter, which is often in the client's interest.
I was certainly wrong in asserting that there were "no problems", but it is still the case that they predominantly charge by the hour. I agree that the incentive is to work smarter, not harder, as with most white-collar professions...
Surely the fact that the legal profession uses (begrudgingly or not) hours as a proxy for work (whether or not they actually work X hours, or who at the firm works those X hours) means something. The legal profession seems similar enough to ours (as far as this issue is concerned at least) and has been around long enough that they should have adopted a better way of doing things by now.
I think the important point is not that it can't be broken down to a hourly rate, but that the smallest incrememt is 1 week or a day. They simply can't book you by the hour.
Specifying what a week or day is, is up to you. In regards to time as well as money.
> It seems inevitable that clients wonder/ask why you can't get X, Y, and Z done in a "week",
As much as I like the 'per week' idea, there's often stuff I can't get done because someone is sick during a week. Client's don't particularly like that. If they wanted to be paying someone $x/week regardless of work output, they'd hire more employees - they're often using external contractors for multiple reasons, but efficiency is usually one.
Being paid by the discrete, incremental milestone assures the client you're not messing around and lets them know you expect to be paid after sign-off.
Having a net 10 or 15 with a ~3-4% discount is also a motivator to get paid sooner than a net 30.
Furthermore, you need someone good at collecting receivables and collections, be it you or someone else, especially dealing with education, healthcare, government, nonprofits or the military... because it will happen in spite of your selectiveness and client rapport, because some large orgs think it's cool to not pay their bills.
So this is what I do on project-based projects -- I write up spec sheets, attach them to the contract/work-order, and define some amount up front payment, and break down the rest in terms of 25%/50%/100% completion, as determined by items in the spec sheets.
As far as collecting receivables, I've been either incredibly lucky or smart -- it's never been a problem for me (I am also no longer in the US -- I'm in Tokyo for now) -- clients have been big enough that this wasn't a huge problem, and whenever I sense it might be I demand a certain amount up front.
I agree with what you've said, but how do you combat the estimation problem & scope creep? Discrete milestones are great but it's very rare that requirements don't change half way through a project -- what is the best way to handle that? The problem is that you often have to make the estimate with absolutely no idea what the existing conditions will look like, there's the never ending stream of "little fixes".
This!
One of the hardest things to learn on your own is how to say no and why. Learning how to identity problem clients and being able to say no to them in my opinion is one of the most valuable skills to attain. Not only for your sanity but also your success.
That comment describes building a small consultancy (= multiple people), which is the opposite of going solo.
Sure, if you want to start up a consultancy, hire people and run the risk of "you don't eat", do that, but that is a very different trajectory to going, and staying solo.
'patio11 has been at Stripe for 2 1/2 years and was solo for many years preceding. I think his reputation is pretty solid, and have a hard time imagining how being fully employed at Stripe for the past couple of years should now make his past advice require seasoning. Have conditions changed so much recently? Would you care to expand on what you personally are concerned about (as opposed to vague aspersions)?
Prior to being a full-time employee at Stripe patio11 and tptacek tried to launch a startup [unsuccessfully].
Prior to that patio11 had been running a Bingo Card Creator and Appointment Reminder.
Corporate Consulting - is a small part of patio11 career. He managed to burn himself on that consulting path. If you want to get similar result - you are welcome to follow patio11 advice.
He was, at one time, doing consulting for $20k-$30k a week for multi-week gigs. I can’t remember what his highest publicly stated billed rate was, but he has been fairly open and detailed about this.
I think he was in the process of jacking up his rates to $50k a week, but then he mysteriously stopped consulting. I’m curious about why. He has alluded to it before, but he was was very circumspect about the whole issue/experience.
I've been doing client-facing Fortune 500 and startup tech consulting for about 30 years. If you're good, be choosey about clients and only work with the ones who will pay by the week, or preferably, by the milestone. You want to know your time is going to good use and that they're not going to get resentful or have any question about delivery.
Keep them apprised of progress, manage expectations, issues and demonstrate progress consistently... toiling away head-down doesn't mean anything on its own. You want to deliver as fast and with quality as you reasonably can... non-blocking, get-it-done, tempered impatience work-ethic.
Also, a master agreement is a good idea. And then each contract is a short and simple diff off that. Makes it less painful for both parties.
To offer a counterpoint to the other commenters here:
I charge hourly and I wouldn't trade it for the world (unless I change the general concept on how I want to freelance).
When I freelance, I want freedom. For me that often means taking off the rest of the day spontaneously after lunch, or just ending the day early. When you are billing for a whole day/week that becomes much harder.
I also don't bill per-project, unless I have the ability to bring a trusted project manager onto the project as well, to provide me with some security against mismanagement, for the usual reasons like scope creep.
Charging hourly also makes it much easier to juggle multiple clients at the same time. For some reason, a meeting with all the stakeholders was set up on a day I am spending most of a day with another client? No problem, I just scoot right over, bill both client hourly accordingly, and nobody has any reason to complain.
As for clients being more prone to haggling over invoices with hourly rates, I haven't had that happen to me yet (~20 clients in 2,5 years). On the contrary, for project-based billing, there is usually a lot of time spent(/wasted) up front negotiating over pricing. I always send over a timesheet with my invoice, and if I had to guess I would guess that none of my clients ever checked that.
In the end, hourly billing gives me a much more relaxed life, a much more stable income stream, a much more stable growth in income, with far fewer headaches.
> When you are billing for a whole day/week that becomes much harder.
Daily/weekly are billing increments, not working increments. I still track hours internally; I billed a client last year for "one day" of work that took me a week due to other commitments. Made it clear up front that I was pretty busy at the time. He had no issues with it.
If you handle it like that (which is the same way I do it), it doesn't make much of a difference, if you bill hourly vs. daily, does it? The maximum of money your're going to lose out on, is the few hours of rounding up to a day, which with any significant client are going to be peanuts compared to the rest.
I would like to offer a different point of view here. Speaking as someone who has done consulting and owns a business. I would leave those hourly jobs for someone else. Focus on selling the result or business impact here. Frame and charge for it that way. You do not want to be some charge me by the hour consultant where they can just find someone cheaper, they will start to think of you like that, and will find someone else.
Do not overcharge or be dishonest about it. But, what is this result worth to them? I'd think of it that way. I have seen people pay 250k for a months work. But, the impact was massive for the company. I am positive this is on the small side as you work up the food chain. There is some free work up front in scoping things out, but then I would sell time in blocks or packages, and do not really get into what you are charing by the hour. They must have some budget for this project, the timelines, a general scope, etc. Make your proposal around that in the context of the impact to the company.
This depends on your field and clients too. But, I'd look to move as quickly as possible from hourly to package deal. There is risk but there is also big reward.
If someone pays you 250k for a simple project. Either you got a REALLY good deal or the project is complex and it will require you to hire people. On the latter it's not about solo anymore.
> You do not want to be some charge me by the hour consultant where they can just find someone cheaper, they will start to think of you like that, and will find someone else.
I can make the same argument about hiring someone else who charges less per week or full project. Simple.
The amount you get payed is highly dependable on the client. For most freelancers, charging for a week is a terrible mistake unless you've a proven track record and some reputation.
I'm assuming the vast majority of freelancer are software developers. The location has a major impact on how much you get payed. If you live in San Fran you can charge a lot because that place is terribly expensive. Don't forget Europe has good developers fluent in English. You'll face competition worldwide.
Also, it's easier to hire someone by the hour. The client can quickly see if you work great together and even give you bigger projects. It takes some time to build reputation and trust with clients.
> You do not have overcharge or be dishonest about it.
From a moral point of view, hourly is fair.
There are people in the ML fields right now getting those rates for 1-2 person shops. That is where I have seen this. It totally does depend on the field though. Look, I totally understand that you cannot walk off the street and get those rates for project. You need to work your way up, specialize, build a reputation, and cultivate the correct clients, etc. That is all I am trying to get at. My strategy would not be to charge by the hour after the initial stages. I was just trying to make the point that you can focus on the end results. But, different strokes for different folks. There is always multiple ways of going about things.
The thread rpeden references is a really sound way to implementing this plan.
>If someone pays you 250k for a simple project. Either you got a REALLY good deal or the project is complex and it will require you to hire people. On the latter it's not about solo anymore.
Sometimes it's about the value you deliver. I'll never forget walking into a pharmaceutical and them telling me they were loosing a million pounds a week because they couldn't get their compliance documentation out of the door. They had been looking for a solution for months and been unable to find it.
Not sure if you have experience doing software consulting or not, but you describe exactly what forces freelancers to negotiate their rates down and burn out, vs successful consultants who charge much more, work on much more valuable projects with better paying clients.
I won't repeat what patio11 and others always say here, but if you are a freelancer and charge hourly, I would encourage you try and follow their advice and see how it goes. I have, and it's been wonderfully successful!
> 250k for a simple project. Either you got a REALLY good deal or the project is complex and it will require you to hire people
simple is a relative construct, I've experienced project you could consider simple getting good money either because:
1. the client want to pay for the project and offset the risk of it to you (read as you make a few extra night if things go not exactly as initially planned)
2. the company tried things but didn't succeed, hence looking for outside help
3. you know the people making the decision and those will definitely not go on upwork.com to get cheap labor for the same reason no one ever question going to Oracle or IBM. Those people have the wallet and simply want result with your track record
Not sure of your background but clearly you did not work with enough clients to understand hourly is painful, invoices never paid in time, and you will get micromanaged very quickly.
Weekly makes the management forget about you, and also you will be automating the paying process while knowing you will have a fixed income for a certain time.
Hourly = Inconsistency, unpaid invoices, constant arguments over hours.
> clearly you did not work with enough clients to understand hourly is painful, invoices never paid in time, and you will get micromanaged very quickly.
As a full-time solo web developer for the last 8 years, I disagree and find your comment distastefully dismissive.
Hourly billing can provide flexibility, transparency and freedom. I have never had a problem getting paid for any of my hourly invoices and I have never had any arguments about my hours.
Different companies, projects and developers have different desires, needs and dynamics.
I totally buy that there are a large number of freelance developers who are billing hourly and would be better off switching to billing daily or weekly.
However, to claim that billing hourly is never the right choice is idiotic and naive. Hourly, daily, weekly and per project billing all have their upsides and downsides and work better in some circumstances than others.
Counterargument: charging per week risks questions about public holidays, long weekends, actual hours worked and so on. Not to say it isn't an appropriate workable arrangement in some cases. FWIW I don't understand why hourly billing risks unpaid invoices any more than weekly. In my experience clients will not pay any kind of invoice without discrimination.
Just like the sibling comment said. If you can charge it, and you are consistently getting clients at X/week. Why not charge that? Especially if you know you can produce quality work. Leave the smaller projects for others.
I agree that clients normally don't know full spec because no one works on that.
One way I find very helpful in mitigating this is by getting a prototype of system, a detailed prototype made which goes a long way to clarify specs for the client and help me understand the scope.
I found transitioning to non hourly project billing extremely satisfying.
There is almost no situation where it makes more sense to bill hourly instead of daily, unless you're really junior. And frankly, if they want you at all, they should be willing to go in for a week.
I'm totally at odds here with this statement, repeated by others here in other words.
Look - in some industries, working 10 or 11 hours is one 'day.' As an hourly consultant I'm hedged against this, which is super common in financial environments. Maybe the experience you guys have is in less stressful, less demanding worlds.
Agree. There's probably a reason why lawyers and accountants bill by the hour. FWIW I get the impression that the folks here holding their nose at the idea of billing by the hour, actually are billing by the hour, just in 40h quanta.
The problem with forums such as this is, while most of us are in a tech or related field, we're from all over the world, at all income levels, in all sorts of industries. I can tell you that NYC and London hourly contractors are more hedged against a terrible existence of 10+ hours a day, on average, than daily rate contractors. So much so that it's actively harder to find hourly than daily rates. Employers (or clients if we should call them this) aren't stupid, they're interested in maximizing cost/benefit.
Let me add something else. It depends on seniority and connections. If you folks are very senior-level software or systems architects, known in the business world or Twitter or through established experience, you can 'set the tone' and of course it makes more sense to, as mentioned above, charge weekly versus daily versus hourly and so forth.
In my industry (DevOps and Systems Infrastructure) it's incredibly elite to reach that level. I'd have to be blogging and doing presentations at tech conferences to be able to go to a Fortune 500 company and dictate project-level Scopes of Work. And perhaps one day I'll get to that! But my point is that this is an elite percentage of consultants.
I never took an hourly contract and my customers didn't want hourly contracts. They wanted a total project cost or consistent monthly cost instead. I got almost every job I ever bid.
Something else if you're a freelance developer:
In order to command a higher rate and not just be hired as a code monkey to implement a predefined task, it helps to position yourself as a consultant who can help the client discover the best solutions to achieve their goals.
Example: instead of just agreeing to develop a client's website per their initial specs, in your discovery call, find out what their goals for the website are.
Let's say they want to use it to capture pre-orders for an upcoming product. Based on this, you can propose a few ROI-positive solutions like integrating payments with their email marketing platform to engage customers and bring back cart abandoners, hosting a viral share giveaway, etc.
Author, if you read this, skip Ally for business accounts. They do not allow them and may freeze your account and hold your funds when they realize you're using it for business.
I didn't know this was an issue. After some research, I found that this is correct and not only do they not allow it but it seems they've shut accounts without contacting the account holders first. Appreciate the heads up.
> Make Sure Contracts Are Signed With the Company - The contracts you sign should be between the client you are working with and your company NOT between the client and you personally. Discuss this with your lawyer.
So simple, yet so many people fail to do so. They believe that since they are incorporated they are protected.
What does this even mean from a mechanical standpoint? What do you look for?
More importantly, where do you learn about all this low level mechanical stuff? Business books and HN comments always assume you know how to do that stuff. They don't teach it in school, at least for CS majors. (And yes, I took the "law for everyday life" class at my school. It was basically at the same theoretical level)
Usually the first sentence of the contract will describe the parties signing it.
“This agreement is between Acme, Inc (the Company) and Kevin Burke (Consultant)” is bad. The agreement should be between Acme Inc and whatever the registered name of your company is. Similarly on the signature line you sign as an agent of the company (CEO, Sole Member etc) the same way your counterparty signs it.
If someone hires a lawyer to incorporate their business, they need to enter in any and all contract agreements under their corporate name and not their personal name.
Ignorance and often EGO (me, me, me, me and.. this is minutiae) get on the way.
Get a lawyer, review contracts, hire an accountant, register as a company...is this really better than working a regular 9-5?
Sounds like the OP spends just as much time (if not more) doing paperwork, meetings, phone calls and other assorted meta-work as programmers in Big Tech Co, if not more.
Corporate America can be a drag, I get it. Annual reviews, backstabbing office politics, the wrong people get promoted, loud open offices full of clowns that prevent you from concentrating but from this write-up it doesn't sound like going solo is any hassle-free Shangrila, either.
For a certain class of people they like the "freedom" and hey, more power to you. By all means, enjoy the IC life. But I'd just as soon move to a different company if I'm unhappy at my job and not deal with this Kafkaesque amount of paperwork of being an independent consultant.
I am the OP and I spend far less actually... a few hours at the beginning of a contract sure but the average contract is multiple months. All of the bills are auto paid, I just need to choose the right card/account when I pay for something. Invoices take about two minutes to generate using a free site called “invoice-generator.com.” The accountant I would have hired anyway to do my taxes. I don’t pay for the lawyer if I don’t use them.
I also get to skip doing phone screens, interviews, being oncall... I am spending a lot more of my time focusing on product problems than I was as a full time employee.
Also - this might be obvious but the goal is to make more than you made as a full time employee or get more vacation time for the same amount per year not merely tread water.
I'm glad to hear I'm wrong. I'm certainly not rooting for anyone to fail.
But a couple of things.
One, the higher you rise in responsibility the more likely your work is to be meta-work. I saw your personal site and the services you're advertising, as time goes on you'll be offering more business-like services because inevitably that's what customers want.
Sadly most programmers have to choose between having the satisfaction of doing IC work and having their salary plateau or transitioning into management and/or biz dev consulting.
Second, it's hard to build equity as an independent. That is, if you work for Facebook or Amazon or whoever for 5 years, that's a hard skill you can trade in for a better job elsewhere, or at the very least your benefits start to accrue higher and higher (e.g. at my Big Tech Co: discount off public stock purchase).
How many 55 year old solo independent devs do you see out there in the wild? I'm sure they exist but unless the have some very specific skill set (e.g. COBOL programming for banks) it's hard to have a forever career as a generalist IC.
But again, more power to you if you can make it work. I'm not criticizing the lifestyle, only suggesting that it's not some peaceful freedom from BS that we'd all want to imagine it to be.
How many 55 year old solo independent devs do you see out there in the wild?
Lots.
Quick question? Would you prefer to be a 55 year old salaried senior dev, or a 55 year old specialist consultant? Same answer if you're one of those two, but currently between gigs and looking for work?
Being the "old guy" looking for a job is how you get discriminated against. "Why is this guy on the market now?" "How many years does he have left?" "Is he still any good?"
Being the "old guy" specialist consultant means you're going to be really good at the thing they need to bring you in to do. You're also really expensive, which just reinforces how good you must be. Nobody is going to hold your lack of inexperience against you when they have a problem their kids can't solve.
No need for the specialty to be Geriatric COBOL or FORTRAN either. A 55 year old Javascript guy today might have 24 years experience in it, and can certainly teach your front-end guys a few things about writing code that runs in browsers.
So yeah, when the time comes, make sure you're either consulting or running your own company.
Well there's no fact-based way to settle this debate, the evidence is all anecdotal, but I see discrimination against older consultants every single day.
Executives at Fortune 100 companies (in my experience) pick an agency speed, price and 'sexiness' -- I've never once heard them positively rate the age and experience level of a solo developer. And I have never, ever seen a F100 co bring in an old guy to tutor front-end devs. I can't even imagine.
I would absolutely rather be the old guy at a big tech co but I wouldn't be a solo developer, I'd be in management.
There's no question there's a path out there for solo devs in their 50s but is it really all roses and rainbows like you say? Seems like the harder path to me.
> How many 55 year old solo independent devs do you see out there in the wild?
I think this might be too young of a profession for that point to add up. I've been a solo independent Dev for 20 years and I'm only 40. I don't know if I'll be doing this for another 15 years, but I certainly don't expect to take a job anywhere.
I sincerely hope you can continue as you've been doing, but as you'll see from many testimonials here at HN ageism in tech is a real thing, people's reactions to you will start to change as soon as you "look" old.
Most of the ageism applies to FT work at Big Tech Co but IMO it sadly applies to solo, independent devs as well since 50% of it is how you market yourself, and "old" will equate to "out of touch" in too many people's eyes.
Have you ever done solo though? From reading your responses here I get the feeling no. Not that your views would be invalid if you haven't, but it does give a different weight to them vs someone who has been doing it a long time, especially who is now e.g. over 50
I have but not in many years. Maybe things have changed since then -- I don't know. But as I've said many times in this thread my point is not to say freelancing is terrible or not viable, just that articles like these seem to underrate some of the tradeoffs, which are significant. Glad it works out for the OP and you, I guess.
But when your wife is pregnant or your kids need to go to the ER life can get very expensive as a freelancer. Too easy to judge the career path as a single 20-something, IMHO.
> Second, it's hard to build equity as an independent.
Your description of "equity" sounds more like "skills". You can always buy stocks of companies, just make sure to charge enough to cover those benefits.
However, I argue that freelancing tends to accumulate skills. If you work at FB, you're going to be doing the same stuff with the same platforms; at best you change languages/platforms every couple years as you get moved between projects. Every freelance contract I've had has been a different set of languages and skills. In fact, one of my contracts came because I am such a generalist. I feel like the clients I've interacted with want an "expert"--someone skilled in the exact areas they need (as opposed to companies, which are a little more willing for you to have related experience but not exact experience), so the more different things you can point to having done, the more contracts are available to you. It also helps you credibly claim "I'm not very familiar with X, but I've been able to get up to speed in a day on my other projects"
Not skills. I meant more institutional knowledge, connections, reputation and advancement within a company. With solo dev you restart at 0 with every new contract.
You can definitely acquire skills freelancing. The question is, what is the endgame? What do you do at 50? If there are a lot of 45-65 year old solo devs out there I would LOVE to hear from them, have them share their experiences.
But my sinking suspicion is ageism in tech spans outward to include independent, generalist contractors.
Do you only work with software companies where you hand over your work and they take over the maintenance and keeping the software running in production?
Until recently I would've spoken as pro-independent, having been at it the last few years as an agency. I left Corporate America to increase "freedom" but regardless of whether you charge flat-rate, hourly, weekly, retainer, etc. you're also spending those "free" hours wondering / attempting to find + secure more work. And regardless of your pipeline, it is a dance with existing clients. Payment schedules getting out of wack, revisions delaying payment and so on.
What's the real net return? Living expenses covered? Compared to a 9-5, there is a significant risk. What I realized is that if I am going to play with such levels of risk, do so through equity plays and not services. Through end of 2018, I was services only. I am mid-process interviewing with larger companies and will happily dive into my skill set for _______ while doing side projects.
This is exactly what I'm talking about. You've been on both sides and can appreciate each. You should formulate your experiences into a longer Medium post (or blog post) and share with HN.
When people talk about "freedom" in this context, they don't mean freedom from meetings, paperwork or other boring aspects of corporate life. And being self-employed is definitely not hassle-free.
What entices people is that - for both better and worse - you are your own boss. You dictate what projects you say yes or no to, what hours you work, when you go on vacation and lots more.
It's true, and I've had enough horrible managers to understand and appreciate the appeal.
All I'm saying is when most programmers envision being a solo, independent dev they think of the freedom but it's really (IMHO) a series of tradeoffs that don't necessarily make it significantly better than working a 9-5 for most people.
Everyone's situation is different. For some it's a dream, I'm sure. But I read lawyer, accountant, contracts, billing and think I'd rather just go back to work.
If W pays you X to do Y you are not “your own boss”. You just have different type of employment relations. I’ve done both and find them equally “free”.
You skipped the other “freedom” you get when you work for yourself: free time.
When you hang out your shingle and quadruple your bill rate for short bursts of client work, you get the option of not immediately booking another gig after you finish the last one. For me, I’d usually toss in a quick 9-12 months of travel before committing to another gig.
But you’re right. I did have to fill out the longer version of turbotax, so maybe it all balances out.
Ha not sure "9-12 months" is "quick". If I wanted to quit my job and travel, I can do that with a regular 9-5.
Maybe others can do this (and if so, more power to them) but if I was taking "free time" while a solo dev I would just feel like I was constantly losing money.
Yes, because once you figure those parts (which is not that hard as you listed), you will be able to make 5x - 10x more money than you used to make with the same skillset.
9-5 for a developer pays 100k. Freelance gets paid 250k+. This is real.
Most devs I know make a lot more than 100K but maybe that reflects my old age.
But let's dive into the numbers for a moment. I have no doubt you can book 250K in a year...but you only referred to the base salary of a developer, not all the other paid-for benefits.
Health care is a huge one. Take a big number out of that 250K.
Paid vacation is a second. Let's say you get 2-4 weeks off in total PTO, that's worth thousands of dollars.
None of the expenses the author mentioned -- lawyer, accountant, etc.
Free computer hardware. An office space to work in. Colleagues you can call on instantly for help.
You don't have to spend unpaid time looking for work.
I'd love to a see a spreadsheet comparison of each lifestyle and see if it's really raining money down as a consultant, because my (admittedly unscientific) gut says it's not.
Health care is a massive one. Burke doesn't mention if he's single or has a family, but any kind of decent plan (health + dental + vision) that covers a family will be extremely expensive. I just left a company and the COBRA quote for my old plan was $2,600/month.
If ACA had been modified to eliminate preexisting conditions, this would have been even worse. I shopped on the open market before ACA and it was a nightmare.
Exactly. And presumably the OP is young and healthy but as you get older you'll need a lot of doctor's visits for the entire family and if you want a GOOD plan, not just some garbage one that barely covers anything, it's extremely expensive.
But it gets to my overall point -- a lot of freelance devs like to bandy around big numbers like 250K without subtracting any of the costs or drawbacks.
For some people I'm sure the tradeoff is worth it but on balance a good job at Big Tech Co to me seems like a better long-term prospect than freelancing forever. But it's just my opinion.
Ha, yes, that's fair. There are few worse features of corporate america than annual reviews -- not because of the process itself but more often because of how poorly they are run by untrained managers.
> Sounds like the OP spends just as much time (if not more) doing paperwork, meetings, phone calls and other assorted meta-work as programmers in Big Tech Co, if not more.
That's business ownership for you. The one thing you're almost certainly NOT getting (at least at the start) is more coding time.
As a business owner, I wish there was a way to outsource all the boring stuff. Last year I've even tried hiring someone to do all the beaurocratic stuff for me, but that didn't work out -- finding good people who want to work just a few hours a week isn't easy.
I guess at a certain size, you can hire a full time assistant to take care of that stuff, but at a small business you are going to do all the overhead work yourself.
And that's fine as long as you'r transparent about the tradeoff. But we tend not to frame solo dev as "mostly business-related work with a little bit of programming" instead we think of it as "Programming on your own! No boss! Wahoo!"
After the initial corporation, legal and accounting setup there’s actually little paperwork that really needs to be done and can actually be quicker than the 9-5 equivalent.
ie: if I need a new computer I just buy it and attach the receipt to the bank statement tracked by my accounting software and my accountant takes care of the rest, versus having togo through some procurement process involving making a business case for my purchase, filling in the expense report, getting that report signed by a manager, etc.
For me personally it was a huge drop in stress. I absolutely hated having bosses promise unrealistic deadlines and then crank up the pressure on the team when we flew passed promised deadlines.
I'd say it depends on the 9-5. I've worked enough terrible jobs to know they can definitely destroy your happiness but found a few good ones that make me happy to come into work every day.
For some people the tradeoff of going solo is worth it and good for them. But I read the OP's post and wait, I have to study contracts for XYZ? I'd rather just go to work.
This is great. Also interesting would be a similar guide on scaling from a one-person operation to a proper consultancy.
Personally I'm jealous of those who manage to found their own creative consultancies. Especially ones that mix design/VFX/videography/software talent, that focus primarily on things like interactive experiences or commercials.
For example, the Windows 10 default background.[0]
There's numerous other equally neat examples, but the gist of it is that they get to think up cool stuff and then sell that to their clients, who are usually massive brands that can afford to pay big money.
Getting one of those off the ground is probably exceedingly difficult barring deep industry experience and the connections to match, and even then I'm sure it's hard.
Sourcegraph CEO here. Kevin Burke (the author) worked with us at Sourcegraph for some important projects in late 2018 (including helping to prepare a big product release). It was a joy working with him. I’ve worked with a lot of contractors and would love it if more people followed these guidelines.
This recommendation, solicited or not, is a very strong example of how to market a consulting business. Sales for consulting businesses can be more than half the trick to making it go and selling services requires credibility. Most consulting businesses that I'm aware of start with one or a small number of existing relationships with built-in credibility and usually the business is started with at least one sale in pocket. When it's time to try and go beyond your initial customers recommendations especially public ones from past happy customers go a long way to establishing credibility and shortening the sales cycle. So it pays double or more in the long run if you can establish relationships with and take care of the directors, VPs and CEOs that you're working for regardless of who the hiring manager is.
The article mentions that incorporation is a protection against loss. The best protection are successes like these. Like what you do, and like helping other people even more.
Do anything you can to stay out of court and everything you can to leave on good terms. Having an LLC is not a license to mess up. If anything it raises the standards, and people will still come after you, sometimes even if you did a good job!
It is in a repository: https://github.com/langserver/langserver.github.io. We try to keep it up to date but rely on authors and PRs, too. We’ll do an audit (and if you see any outdated ones, please let us know).
BTW, I emailed you but didn’t hear back after you posted a similar reply to my last HN comment. Can you let me know what wording you’d suggest to avoid confusion? My intent is for the wording to be clear.
I'm in the same boat, with a pure technical background, I managed to tripled my salary in 2 years, the job has become much more interesting and without all the political noise. The hardest bit so far is the sales / pricing strategy. For example, my biggest problematic this month is to figured out how much is it realistic to charge a F500 to support & maintain a custom build solution we've created: 5k/month, 10k/month, 15k/month (was sounding totally crazy to me until some people told me their company charge that kind of money for support)
My experience has been to ask for a crazy amount (at least 50% more than you think you can possibly achieve). This anchors them high. Agree to “meet in the middle” and you will be better off than your starting point. Then deliver like crazy until they think you’re underpaid.
"""
I started out charging a monthly rate that was close to my full time salary / 12. This is not a good idea because you have overhead that your employer is no longer covering - health care probably the biggest one, you don't have paid vacations, there may be unpaid downtime between contracts and also companies might not pay you.
"""
When I started working remote 5 years back, I was just out of college and didn't care about those things...
I feel like this is standard stuff, especially coming from the UK and the huge amount of contracting in that market. The real hard parts of independent contracting (how much exact are market rates/how do I find & land leads for contracts without an existing contact at the client) don’t seem to be addressed.
I feel like going freelance/consulting is such as "figure it out on your own" ordeal even though there are so many people who do it. Seems like there's opportunity to help people who want to go freelance transition more easily.
I think a good analogy is hair salons that sell a seat you can rent as a hairdresser...are there places where you can "pay" for leads/intros to clients as part of a larger remote software consultancy?
You really don't have to figure out anything, it's all been written about many times over and posted all over. The post is a good summary but lacks details. I am a UX consultant, not a developer, I figured it out on my own (although I'm sure there are things I am not aware of that perhaps I should research and figure out further) but I probably didn't have to if I did some googling around first.
The biggest thing that makes you successful as a consultant is thinking like a business. You are not a person performing a service for the company (that makes you a hire / an employee figuratively speaking), you are a business, solving their business problem. When you think of yourself in this way and act accordingly, then everything becomes easier - saying no to bullshit, billing and collecting, charging way more.
I nodded my head when I read the point about increasing your rate for every new client. People think charging more is being unfair, but this is just business practice. You don't need to charge "your worth" whatever it may be. There is a supply of a very particular thing, and a demand of a very particular thing and the rate does not matter whatsoever when the return far outweighs the costs. A million dollar product is worth exactly zero if it cannot be produced and if you are the one to help see it through then you can charge whatever you like, given the margins make sense. These days I find myself increasing my rates for every new client. Sometimes, just for the heck of it, when I have many leads, I'll double my already high rate to see what happens ;)
It's an additional expense but I would add obtaining business liability insurance to the list. It's not generally too expensive but can save you a bundle in legal fees that you can't recoup even if you prevail in lawsuit. Additionally, while a corporate structure should shield you from personal liability, there's no guarantee that whoever is suing won't try and pierce the corporate veil to get to the corporate principals - hence the benefit of insurance.
This is so helpful- thanks for sharing! Also your own website is such a great example of taking selling yourself as a consultant seriously. Congrats on all the success here!
The biggest impediment for me would be finding clients. IME most programmers dont meet a lot plant potential clients when they are maintaining internal software. Even if they work for a consulting company, you can't use them due to restraint of trade clauses.
So how would you get the first customers? I'm just some guy off the street, no one is going bet money on me performing a function for their business.
Go to meetups, talk to colleagues who have quit your current company, try to attend or speak at conferences, start a blog and post at the bottom that you’re available for consulting...
There’s no rule that says you can’t pitch projects to people, if you think you could help make a company better call them up and pitch them on it.
1. What kind of meetups? I'm guessing developers are inclined to go to developer meetups, but it seems unlikely that potential clients would be there.
2. How have you managed to get hired by technology companies as a consultant? My clients are mostly folks that are non-technical and need someone to build them custom software. I'd love to work with tech-focused companies but am not sure how to find/pitch those opportunities.
Living in SF helps. I meet people at meetups, on Twitter, through Github, I reach out to people I think are interesting...
You could try finding a company you’d want to work for and take one of their engineers to work, or try to target companies that need your skill set. “Hi you really need a Go client library - I can build that for you” etc.
That's actually really helpful. It's tempting as a consultant to be reactive, but these are a few ways of being proactive that I had not considered. Thanks!
Any meetup that could have you next potential customer. For me it's meetup about Marketing, Sales, pure networking, Developer conf, .... Force youself to 1 to 2 meetup a week, this is not a one off thing but a long term investment if you want to be on the call when someone you've met hear about a project within their company.
> How have you managed to get hired by technology companies as a consultant?
For me, it's not really technology companies but companies that sees IT as a cost center, the usual scenario being they need a solution for a problem and don't have the know how to make it all work because IT isn't part of their core skills and the IT guys are only there to manage the network and debug their window machines
Dang, two meetups per week is quite a commitment, but I can see it being valuable over the long term.
My interest in technology companies is that, presumably, they have more interesting technical challenges and are willing to spend the time/money to build optimal solutions from a technical standpoint.
When recruiters inevitably try to recruit me (because software dev) I tell them I exclusively do contract work. My profile also mentions this. Some of them have clients that are open to this. They pitch the client to me. If I'm interested we discuss skills, rates and they pitch me to their client.
I've also reached out to a few recruiters that have seemed reasonable and gotten work that way.
LinkedIn noise/signal ratio isn't the best. Other sites have been better. But I've found work that way.
One issue I see is that GitHub ToS prohibit a single natural person from owning multiple GitHub free accounts, so you would have to pay for each one which could get quite expensive. Of course, larger business will have their own GitHub Enterprise or self-hosted Bitbucket/GitLab/etc that they can make you an account on.
We just maintain our own corporate git hosting account for clients who don't have their own. Not a significant expense. Although we actually use bitbucket rather than github for this.
Problem is, as a student I am trying to go freelance and start getting clients by doing small projects. And I read articles like this one and I have so many questions. I cannot pay for a lawyer or an accountant yet most of the people recommend it, am I not going to be able to go solo if I don't have those kind of securities?
> I cannot pay for a lawyer or an accountant yet most of the people recommend it
Things are simple. The rule is: "If you can't pay for it, you probably don't need it". I am also one of those solo consultant, personally I got mine when I found out the price I was paying my accountant was multiple time less than the loss of not having one. To give some numbers, if you give to your government more than $5k, it will be worth your while with all the tax cut you can claim.
For small projects you might not need a lawyer or accountant.
But when you feel the balance is right you should hire people who can help you with your problems.
At the moment you might do small projects but when project get bigger and your rate higher you will see that an accountant will become affordable.
And when you do multi million projects you will be able to afford a lawyer.
But one thing that is very important even when you are still 'small': register everything! What money goes in and what goes out. What the contracts are and all your email conversations with clients.
This will help you and future accounts and lawyers.
You might want to consider charging more and retaining some income to cover professional fees. That said those fees don't need to be huge. We typically pay our lawyer and accountant less than $1000/yr, and we have more business and more complexity than you'd have starting out. Note that these folks aren't doing actual accounting and contract negotiation for you, just providing advice on how to set things up, on fine details, final agreement review, taxes, stuff like that which you can't get from Wikipedia and SO.
That's a great start, but what kind of jobs are we talking about here? I'm asking because you might want to invest into building more experience before breaking off on your own. I'm talking about possibly larger projects, cooperating with other teams, driving products forward, working with PMs/customer requirements and so on. One way to get there is to work at a larger organization. People place value on experience.
I've been developing using Swift for three years and built several apps for myself and published them. Those jobs were coding purely in Swift developing apps from scratch and using frameworks I've never used and learning about them (like AVFoundation), I think that's a great start and some basic experience.
The tried and true approach to starting on your own is to land your first customer by being the cheapest, use that as a reference, and charge serious money once you have a track record that you can point to.
The alternative is to get a normal full-time job for a few years, build credibility, then go on your own using the contacts you made at your employer.
> "The tried and true approach to starting on your own is to land your first customer by being the cheapest"
That's definitely worth trying. But please remember, that is exactly what in an insurmountable amount of people is currently doing over at UpWork/Fiverr/Freelancer.com. You need some kind of advantage over them - if you want to nail your jobs and get paid a salary that can sustain you.
Dear Author, thanks for the write-up. Regarding "Market yourself"... You mention websites and so forth. Is most of your marketing online or most of it in networking events?
How do you deal with recruiters and LinkedIn recruiters - have you found a way around these?
Sort of on the same path right now.
Biggest obstacle I'm running into is that most of the work I'm finding is through recruiters, which of course means that a chunk of the money goes to the recruiter before I receive it.
The rates are still decent, but I'm not working with enough of a financial buffer to compensate for the downtime I'm having. I'm brand new at this though and I expected this sort of difficulty curve to start out with.
On a side note, if you've got an Angular or react project you are working on in the Atlanta area or remote and need some help, reach out to me :)
Start contributing to Angular or React core, reach out to developers on the team or conference sponsors, let them know you’re available for consulting, put up a targeted “Angular.js consulting” page...
Every company you reach thru the recruiters, if you make a good impression on the employees there tell them to reach out to you directly to hire you again if they move on.
I have no employees, so yes, “going solo” is an accurate description.
I would have an accountant anyway and frankly even if I was full time I would want a lawyer to review the employment agreement so not really saving anything there.
Just sort of an odd gotcha - all sorts of people from train drivers to baristas to shoe manufacturers make us all successful every day but we don’t tend to count those people as employees or insist on a definition of “solo” that involves making your own shoes.
These are outsourcing jobs and it’s better than doing it yourself. And you spend less time with them than your gym instructor or even your grocer or building manager. They will save you a ton of time and money, though.
Nothing wrong to admit one can't know everything. Unless you have secret accounting skills (which isn't trivial to acquire) getting an accountant got me more money back than what I paid him while offsetting the risk of getting the books wrong, from where I sit, it's been a net win
> Try to get as much of the contract as you can paid up front - I generally ask for half or more up front. If a company offers Net 30 ask if you can shorten it to Net 5 or 10 or submit your invoices in advance.
Anyone can suggest some good reading material on how to structure payment tranches? Do people charge a retainer? If so what percentage? when the work starts is it “pay as you go” or after completion? Does Net D apply to work start or completion?
Great writeup Kevin. As a IC, I can relate some of these points with my experiences.
You should charge more to compensate for Medical Insurance, Non billable hours (Gap time), Marketing cost etc.
Setup a Company (LLC or S-Corp) for doing paper work and contract (buy a minimum liability insurance). This will protect individual from litigations or lawsuit.
Payment - Can't stress enough. I try to negotiate Net-15 or Net-30 days payment. So far it worked with all the clients.
This is really impressive! I'm especially impressed by the landing page for his consulting site: https://burke.services
This is so much better than just listing some of the technologies you've worked with. It's really great to talk about the problems you've solved, and have some customer testimonials (especially from big names.)
I've been doing almost the complete opposite for the last ~4 years. I always charge by the hour, and I use a time tracking tool that tracks every minute. I never ask anyone to pay up-front. I've used services like Toptal and Moonlight that handle all of the billing for me. I've never talked to a lawyer or an accountant. I haven't registered a company specifically for my freelancing, but I've started doing everything through my startup's company. (My startup now offers a SaaS product plus consulting services.) I live in Thailand and have a work permit through Iglu [1], so they handle all of my invoicing and taxes. I also don't have insurance. I don't set up separate GitHub accounts for everything, and I don't really see the need for that. But I do usually work for one client at a time, and I find context-switching very difficult.
I think the main reason I haven't taken my consulting work super seriously is because I don't really want this to be my career. I've always treated it like a part-time thing to just pay the bills while I work on my own startups.
No offense to people who take this seriously, but consulting has always felt like a bit of a dead end. You can make a great living, but I get really depressed when I enumerate all of the hours I would need to work. A salaried position is nice because it hides these details. You come to work in the morning, go home in the evening, and then your paycheck is transferred to your bank account. You don't have the option to stop working at any time, so you never really have to think about it.
When you're a freelancer who wants to do this as a career, you suddenly have to convert your retirement goal into a fixed number of hours. Say you want to save and invest $2 million before you stop working, and you earn something like $200 per hour. You're able to save 50% of your income. You have to work at least: ($2000000 / 200) * 2 = 20,000 hours.
That's 2,500 full days of work. Maybe you are able to book 80% of your time, and you only work 5 days a week, so each year you can work: (52 * 5) * 0.8 = 208 days. It will take you 2500 / 208 = ~12 years of almost full-time work before you can safely retire with $70k of investment income. Maybe more like ~9 years to account for investment returns.
I think I'd rather join a few early-stage startups and get some significant stock options. It's much more fun to be part of a team member and have a vested interest. It will still take an average of 10 years before most startups have an exit. But you can leave after a few years and work for a few different startups to diversify (or start your own.)
Having said all of that, I'm really impressed by https://burke.services and would love to hire him to work on my startup in the future.
For what it’s worth I work a lot less than I did as a full time employee - I was always thinking about work on the weekends, I had to wear a pager, I was responsible for fixing things...
I’m still responsible as a consultant but at the end of the work day I go home.
Yeah, but not all startups are created equal. Sometimes you can spot an opportunity that is much more likely to succeed. Maybe the cofounders have already had multiple exits, they’ve raised money from some very prestigious investors, and they already have a very impressive list of customers who are paying to use the product.
That’s not anywhere close to a couple of first-time entrepreneurs working on “Facebook but on a blockchain.” But I think both of those startups are counted when people talk about the high failure rate.
And even better if the cofounders have a wide network, a strong track record, and an impressive product that people are already paying for.
Sure, startups are still extremely risky, including the ones with prestigious cofounders and investors. But they can also pay quite well at the same time, so it’s not like you’re working for free. A senior engineer at a well-funded startup can still earn $150-180k, plus significant stock options.
I personally enjoy the risk and excitement and much prefer to work at early-stage startups than FAANG companies, even I end up earning less. Working on my own products is even more fun.
1. Yes under 20. I started when I was 17, partially spending the time in my Compsi vocational class doing client work I had found on odesk(now upwork).
2. First couple jobs I probably worked below minimum wage. Lots of foreign competition on odesk that is hard to compete with no reputation. By the end I was making 35/hr in an area where you can mortgage a house for $350/mo (why did I move to the bay area again?? :))
3. Yes they get easier to get. Part of my pitch was I get things done right which people liked.
Edit - another fun fact about odesk. My first office job in the bay area was literally across the sidewalk from them. I spent three years getting work through there, moved 3000 miles, and ended up across the street from their office. Neat right?
Is self employment on its own a worthy goal? I think it makes sense if it enable or finances entrepreneurship. Building an enterprise, disrupting existing business models, and adding value at scale is much more interesting problem.
Perhaps they own a house and don't want to lose it in a lawsuit? Also many clients will require their vendors to have insurance. Insurance is a kind of virially marketed product.
> Give back to the tools that make you successful - I give a percentage of my earnings every year to support software tools that help me do my job - iTerm2, Vim, Go, Postgres, Node.js, Python, nginx, various other open source projects.