Going Solo, Successfully
kev.inburke.com
kev.inburke.com
> 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.
Read contract yourself then get back to company and request to either remove all one-sided clauses or make them equally two-sided.
Also - add clause stating that unless you paid in full and on time - all IP belongs to you.
Most contracts try to pull the blanket one way.
Once done, then call your lawyer with resulted paper.
Much less work for your lawyer to do.
Few iterations back and forth - yes, but it's clearly fair.
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]
In the USA it's almost expected that you should request changes and trust levels may go down if you don't.
In many parts of Europe the client's response is often that they are well within their rights to "protect" themselves through one-sided clauses.
In Africa you just get the funny look.
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 a clause, test it with varying inputs, watch the output and so on.
I've actually had fun working with my lawyer debugging/mine-sweeping contracts. We tech people use very similar techniques.
Seriously, go for it, you'll see :)
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.
That's absolutely true. The thought process is similar but we & they are trained differently, I really like your analogy.
I did not know this had to be explicit. So even if unpaid or partially paid, your work can still legal belong to the commissioning party?
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.
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.
Opened up a good conversation, and we all signed something we were happy with.
This is bad advice.
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.
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.
The thread rpeden references is a really sound way to implementing this plan.
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.
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!
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
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:
https://news.ycombinator.com/item?id=4247615
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.
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".
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.
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".
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.
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.
Specifying what a week or day is, is up to you. In regards to time as well as money.
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.
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.
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.
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. 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?
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.
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.
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.
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.
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.
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 is a seasoned HNer who has done this in a fairly public way.
Please take his [no doubt interesting] recommendations about how to do consulting -- with a grain of salt.
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.
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.
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.
Service > product > weekly rates > daily rates > hourly rates.
The further you are to the left the more money you'll make but you have to start somewhere.
Maybe the correlation between hourly billing and bad projects is not causal.
It will be the same as charging per half day, but it can help you and your client to accept that charging daily will be the next step.
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.
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.
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.
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.
Hourly is a hedge against exploitative clients.
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.
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.
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.
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.
If you really want a time-based fee charge per day, that's a good compromise.
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.
Their great for personal accounts.
So simple, yet so many people fail to do so. They believe that since they are incorporated they are protected.
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)
“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.
* critical thinking * actually listening
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.
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.
That's business ownership for you. The one thing you're almost certainly NOT getting (at least at the start) is more coding time.
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!"
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.
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.
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.
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.
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.
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.
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"
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.
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.
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.
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.
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.
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.
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.
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.
9-5 for a developer pays 100k. Freelance gets paid 250k+. This is real.
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.
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.
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.
Oh man. This alone is reason enough for me to be a freelancer.
Now the only person who makes promises is me.
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.
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.
(I agree with your reply!)
Your list of implementations is outdated and best belongs in a git repo.
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.
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!
""" 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 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 need to spend a lot more time with the same developer.
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 ;)
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.
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.
> What kind of meetups?
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
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.
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.
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.
I blogged about this as well recently, might have one or two interesting points for you: https://blog.classycode.com/going-freelance-as-a-software-en...
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.
Is this more-or-less your first job straight out of school?
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.
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.
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.
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.
How do you deal with recruiters and LinkedIn recruiters - have you found a way around these?
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 :)
All of my contact info is on my site elarbee.io
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 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.
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?
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.
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.
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.
The statistics are quite different if you just look at YC companies: https://www.quora.com/What-percentage-of-YC-startups-eventua...
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.
I’m still responsible as a consultant but at the end of the work day I go home.
So, you never take vacation or get sick? Plus, 80% of days billed seems pretty optimistic, isn't it?
Not sure I'd write an article but open to questions!
Was 2nd client easier to get. How about the 50th?
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?