A year ago, doe-eyed and excited, I pranced into the business registration office in Ljubljana. It was time to stop messing about and become a proper freelancer.
Five minutes past 1pm on a Thursday. Closed.
You can only open a business in person Mondays and Wednesdays before noon or after 1pm but before 5pm. On Tuesdays and Thursdays before 1pm and on Fridays and days before a national holiday until 1pm. I am not making this up.
O.o
Initial holy-fuck-this-is-the-real-world-now setbacks aside, on 24th of September 2012 my sole proprietorship was officially registered and I became a business. I had an accountant, a business address, a business bank account. I even had my first client.
Since then my rate has grown by 100%, my availability has dropped to essentially zero, and last week I hired my first intern. Life is good :)
Well, I say I already had my first client back then, but it took them another three weeks to sign the deal. Lesson 1.
A week is nothing
When you're just starting out as a one-man business you're a rocket. You're essentially twiddling your thumbs so turnaround times are zero. Everything can be done immediately, you can start a new client yesterday, and you can get anything done in a week or two.
Of course you feel everyone who doesn't work at the same pace is lazy. What do you mean it takes a week just to get back to me on the contract? What do you mean you need a few days to assemble the stuff I need to get work done?
After a few short months, you understand. You're busy. You have plenty of work. Oh a new client has a cool project? You might have time in a month or two.
If anything takes more than an hour, it will have to wait for tomorrow. Then you will need to think about it. Then you might have to check with somebody. Then a week has passed.
Congratulations, you're just as slow as everyone who seemed super lazy two months ago.
Only accept exciting projects
The more work you have, the easier it becomes to focus only on projects that pique your interests. Maybe it's a product you want to use yourself, maybe the project opens interesting opportunities, maybe the tech side tickles your inner nerd.
Whatever the heuristic, it's important to only work on projects that are fun.
Explaining this to your friends and family will make you look like a spoiled brat, but it is of vital importance for the health of your business. When work is fun, it doesn't feel like work.
This will generally make you a happier person, which leads to better work. When work is a slog, quality suffers.
And remember, you're building a brand now. What sort of projects do you want to be associated with?
The more you charge, the more you work
Another side-effect of focusing on exciting projects is you can charge more with a clear conscience. You're getting so much done and you're so very productive, why not charge more?
Yes, I know. It doesn't work like that. As long as your lines-of-code or features-implemented productivity isn't horrifying, your clients don't care. But it does help with that nagging engineer conscience that keeps whispering in your ear "Dude, you're not really this productive. You can't justify this price."
But here's the funny thing, the higher my rate has become, the more and the better work I get.
When I was starting out my rate was too low and clients treated me as an extension of themselves. They were making all the decisions, I was just the bloke that coded it up. Even though I did everything I'll explain in the last section, they still treated me as one of those just a coders.
Essentially, they didn't trust my judgement.
But the more I raised my rates, the more they did trust me. The more they leaned on me for advice, the more they talked to me as an expert rather than a goon.
I think early on I even lost potential clients because I wasn't charging enough and failed to send a "I am an expert. Promise!" signal.
Hourly sucks
Part of becoming treated like an expert was moving away from an hourly rate.
The problem with hourly rates is it sets up the wrong incentives both for yourself and the client. It puts you in the territory of somebody who swoops in, pokes around for a bit, then goes back on the shelf until internal engineers need your help again.
On your end it sets the incentive for padding hours. That you should work unreasonable hours, that you should fit in just one more hour here or there. Just that one more hour before I go to bed, it's like, worth a lot of money.
Then you have to charge two more hours the next day because you fucked up when you were half asleep.
Don't be that guy.
When the smallest unit of time is a day, clients won't call you up when there's something small to do. You will get to implement whole features, work on real refactoring. You'll be a valued member of the team. Internal engineers will know who you are.
Incentives are better aligned. A day is a day. You have a lot more room to do quality work and clients don't feel paranoid you'll be padding hours because you can't just sneak a whole day in there without justification.
You can also go for coffee with a friend without worrying how much it affects your bottom line. Life is better.
Only one client at a time
Part of the reason a day rate works so well is that you can't work on more than one client per day.
Context switching between projects is hard. Especially when they use completely different technologies, have a whole different team attached, a different set of problems, different market, different everything.
Imagine how stressful changing jobs is.
Now imagine doing that more than once a day. Work a few hours for client A, then a few hours for client B. A few hours for client C, god forbid.
If you want to pull it off with any semblance of quality work, you're going to need at least an hour or two to switch your brain too. Time you could spend having fun.
Switching every few days is easier. I used to do two or three days for one client, then another two for another.
But even this got exhausting and I noticed the quality of my work deteriorating. Nowadays I try to block off at least one whole week for a client and I no longer try to have more than one client at a time.
There's no need to hedge bets. If you do good work, your clients will treat you well and there will never be a problem.
With my next contract I am officially switching to a weekly rate.
Coding is the least important part of the job
The most surprising thing I've learned over the past year is that coding is the least important part of my job. Clients don't really care about my code past any trouble I create for their internal engineering team.
They care much more for my experience in the web startup space, ability to help them specify what they want built and so on. I summarised it well in a HackerNews comment recently:
[blockquote] Usually clients have a hard time explaining exactly what they want and our visions might differ. When I turn in results, they are often different than what the client first imagined they'd be, but through iteration and conversation I can help the client clarify what they want or realise something else 90% of the time.
Time is another big problem. When you want something done in X time, I will do my best to catch that time. Sometimes this means discussing with the client until the feature list is cut down to a deliverable size. Other times it means sacrificing future flexibility of the code. I always try to get the best balance between "speed - quality - price" for what the client needs, but it's easy to miss.
Almost always, clients have an unreasonable expectation of what is possible.
I'd say at least 70% of my job is helping the client decide what they even want me to build for them.
In fact, posting that comment created a solid lead. I had to pass the project on to a friend because of lack of time, but clients obviously care about things other than coding.
Continue reading about Lessons learned in a year of freelancing
Semantically similar articles hand-picked by GPT-4
- Lessons learned after a month of freelancing full time
- How to royally cock up as a freelancer
- What I learned while 6x-ing my income in 4 years
- Indie startup more profitable than Uber 😛
- I went through YC as an intern, here's what I learned
Learned something new?
Read more Software Engineering Lessons from Production
I write articles with real insight into the career and skills of a modern software engineer. "Raw and honest from the heart!" as one reader described them. Fueled by lessons learned over 20 years of building production code for side-projects, small businesses, and hyper growth startups. Both successful and not.
Subscribe below 👇
Software Engineering Lessons from Production
Join Swizec's Newsletter and get insightful emails 💌 on mindsets, tactics, and technical skills for your career. Real lessons from building production software. No bullshit.
"Man, love your simple writing! Yours is the only newsletter I open and only blog that I give a fuck to read & scroll till the end. And wow always take away lessons with me. Inspiring! And very relatable. 👌"
Have a burning question that you think I can answer? Hit me up on twitter and I'll do my best.
Who am I and who do I help? I'm Swizec Teller and I turn coders into engineers with "Raw and honest from the heart!" writing. No bullshit. Real insights into the career and skills of a modern software engineer.
Want to become a true senior engineer? Take ownership, have autonomy, and be a force multiplier on your team. The Senior Engineer Mindset ebook can help 👉 swizec.com/senior-mindset. These are the shifts in mindset that unlocked my career.
Curious about Serverless and the modern backend? Check out Serverless Handbook, for frontend engineers 👉 ServerlessHandbook.dev
Want to Stop copy pasting D3 examples and create data visualizations of your own? Learn how to build scalable dataviz React components your whole team can understand with React for Data Visualization
Want to get my best emails on JavaScript, React, Serverless, Fullstack Web, or Indie Hacking? Check out swizec.com/collections
Did someone amazing share this letter with you? Wonderful! You can sign up for my weekly letters for software engineers on their path to greatness, here: swizec.com/blog
Want to brush up on your modern JavaScript syntax? Check out my interactive cheatsheet: es6cheatsheet.com
By the way, just in case no one has told you it yet today: I love and appreciate you for who you are ❤️