I charge by the hour and will never change. It forces the customer to focus on getting the requirements right instead of hand waving it like "oh yeah, that's just what I want" and then come back later "I didn't want that, what I meant was" repeat ad infinitum. You see they are paying for my time, not results. If they choose to waste it... doesn't matter to me, it's all billable just the same. I will do my best to steer them in the right direction to save time and money, but you'd be amazed how often they need to learn the lesson the hard way.
I also don't compete, I'm not on any "freelancing" websites, I don't apply or bid for work. My clients always come to me, I get an email, a phone call asking if I'm available. So this race to the bottom nonsense is utter crap. I'm a consultant NOT a freelancer.
I've been doing this since 2011, that's the last time I had an employer. This year I'm on track to bill out between $360k and $400k. If that's "amateur" so bet it. Considering I have no debt, my house is paid for, my luxury SUV I paid cash for, my actual monthly bills are around $2,500 a month. I really couldn't care less what someone who writes an article like this thinks of me. The writer is advocating for the client, they aren't giving me advice that helps me. I also have no interest in scaling, on bringing on employees. I'm making bank, I left CA in 2013, currently live in Wyoming with a 40 minute drive to Park City UT and a 60 minute drive to Salt Lake City.
To anyone reading this article and thinking they are offering you helpful advice, consider their motive. What are they trying to sell you? Are they trying to change the current consulting landscape to benefit themselves as a business owner?
More power to you, but I stopped charging by the hour a long time ago. I charge minimum by the day, and offer a discount if you buy a week. I still bill for my time, but I avoid haggling over how many hours something took, and it also saves me the trouble of tracking my hours.
You book me for a day, you get me for the whole (at least) eight hour day, however you want to spend that time. You book me for the week, you get me for at least eight hours each day for a week.
I also do by the project billing, where I estimate how much work something will be, and pay on milestones. That requires a lot of up front work defining the deliverables in a way that avoids scope creep, but I also build in an overhead for scope creep so that I can "comp" them some deliverables that weren't covered, and everyone is happy.
But the most important part is that the price is always agreed upon up front.
The biggest issue with hourly billing is that neither of us knows how much the contract is worth until afterwards.
How do you deal with clients that perceive and expect to have you available and working more than eight hours a day? What do you do about when your not immediately answering during lunch etc. What do you do about days where you detect l weren't fully engaged by the client for a full eight hours?
Don't set that expectation. Don't work with clients that expect you to track hours when you bill days. The threshold for productivity and exclusivity I've had has been "if I billed you for a day, I'm not going to bill work for anybody else in that day"; that's as far as I go. In 15 years of doing this kind of work ('05-'20) I never had a problem --- but we did bail on RFPs where clients made it clear they'd be looking over our shoulders to make sure we were busy. That happened only a couple times, and, in retrospect, based on conversations with the people who ultimately won those bids, we were always glad to have had the early warning on those clients.
I've never had to fix bid for work, always had hourly gigs in the wings. I hold the philosophy that sw dev is a product development, iterative exercise, not a construction metaphor that is predictable.
Yeah, I expect you would be able to do the same if you billed hourly. If a client insisted I bill daily, I'd probably have no issue with it either. It's just so rare to bill daily in my circles that I've never considered it, I'm often rebilled by my client to their end customers for specific features so they need hourly tallies to pass on.
When you bill hourly you are literally demanding that your clients account for your time on an hour-by-hour basis. So, no, it's not the same.
If you're subcontracting in order to make ends meet, then you don't have any control over your project structure; you're a subcontractor. My advice is to plot a course to not subcontracting anymore as soon as you can. I doubt that the driver developer who kicked this thread off is subcontracting.
I've been in full control of the architecture, team makeup, feature design, most of the technology choice, and often the feature priority. I put my foot down on clients that dictate how a feature is to be built and give them the 'why' talk. I've had enough control over all the projects I've ever worked on these last fifteen years I've worked hourly.
I get your ideas about subcontracting, but I've always been treated higher than an employee and typically like a partner. The trick to this is to charge a ridiculously high rate. That instantly establishes the dynamic and relationship I want.
But you don't have a direct relationship with the actual buyers of your work, so you don't control your project structure, and the middleman business reselling your work presumably needs to be taking a cut. It's no wonder they treat you well, right?
Well for the case right now, I'm building a multi tenant system. Some tenants want features that no others want and they pay for my hours on those. I still have enough control in these cases.
I come up with better lower costing solutions when the stakeholders express WHY the feature is needed, what problem it solves. Then we and I can creatively explore HOW to solve the problem. There's usually several ways to solve anything, many that vary by orders of magnitude in terms of cost or architectural complexity.
If I am dictated always on the HOW, handed fully solutioned work to implement like a monkey I rebel and have a long talk about how this won't work. I never have had to quit over this stance but I would if it wasn't reconciled.
So when I say control, that's really what I specifically mean by that word. The ability to negotiate and explore the HOW with the why being firmly in mind.
Not really, if you are a consultant or external business you account for your own hours - you set a budget and then hand in a timesheet either weekly or monthly, then send an invoice at the end of each month.
> How do you deal with clients that perceive and expect to have you available and working more than eight hours a day?
The contracts specifies which days I will be there/available, and the times (usually 9am to 4:30pm in their time zone). Sometimes if the work is interesting I'll give them extra hours on me.
> What do you do about when your not immediately answering during lunch etc.
I work through lunch. I always answer. I take care of my personal needs before and after the contract time. I build in 30 extra minutes to account for bathroom breaks and heating up food to eat.
> What do you do about days where you detect l weren't fully engaged by the client for a full eight hours?
That's a them problem. If they don't have enough work to fill my time, then that's on them. If they have enough work, then I do it. It's just my work ethic.
"The biggest issue with hourly billing is that neither of us knows how much the contract is worth until afterwards."
You still don't with daily billing.
I know with daily billing because they can only book me for a set of days in advance. It's not ongoing. We agree ahead of time on the specific days I will be there/available.
I would guess we do different types of work. Most of my engagements are at least a year long. I've been billing at my current company for four years this December.
Here's the challenge I ran into, so I'm curious how you handle it...
If you bill by the hour, first they fight you over the hourly rate. Then they want to argue over how many hours it will take to do the work. Then they want to argue over you billing them for all the project management and planning hours you are spending with them, they only want you to bill them for "the work." Then when they get the bill they want to argue over the hours you bill them.
And before anyone says "find better clients" I found this in everything from Fortune 500 to mom and pop. And Fortune 500 is net-180 regardless of what's in the contract.
I was spending so much time in this kind of BS that I went to a monthly retainer model. You get access to me, but you are doing so in a way that we can both set aside haggling over hours. For the smart clients it was a great deal and it saved me a whole lot of accounting overhead.
Have you considered a monthly retainer with an hour cap?
This prevents you from being treated like a salaried employee, maintains your work life balance, and ensures the client is still providing solid requirements and thinking through their ideas.
We have found a lot of great success with this model, and our clients respect it. It ensure we can have multiple clients, without one taking up all of our time, and taking it from others.
If we spend under X hours, that's fine. But there's simply a cap. It essentially means that each client gives enough work for us to work for those total number of hours, and we still have MRR regardless. We can help our clients maximize usable time, and it makes our project management valuable to the client as well.
To combat long Net Terms, you can kickoff a client with a project, which begins upon receipt of payment, and is continued with the retainer. This initial project should be able to support you until your retainer payments start (180 days in length) but your retainer should start ASAP.
It also allows the client to see your value, and you get to feel the client out.
At this point in life, I've moved on to a new field altogether, but some of the ideas you are sharing above are exactly the types of models I experimented with.
A number of years ago, the term "F*ck you, pay me" was going around in popular vernacular. That jives with my own experiences - ask for deposits up front, make payment net-15, tack on a giant fee in the event of slow / failure to pay, and make sure your contracts are written so that the client pays legal bills in the event you have to sue. Create contract disincentives to encourage good behavior. Keep your rates high and don't give anyone a deal. Be willing to say no both to prospective clients as well as individual projects - even with good clients.
I've been a contractor for 14 years now and have faced little of what you describe, but I've also attempted to insulate myself from it as much as possible. You learn pretty quickly which clients not to take, and haggling over rate is the first red flag. My rate is my rate, it's not negotiable.
Other red flags are "we have a project starting in a week" type offers. Mom & Pop's are right out as they are the worst companies to deal with. Startups tend to be great since they have tons of money to throw around and don't care how it's spent as long as work gets done. And if it's not at least couple months worth of work it's not worth my time.
Once you have a network many of these issues go away. If someone is coming to you because they know you or you know someone on the team, they are much less likely to dick you around. It's also easier if you promote yourself as a consultant as much as a contractor because then all the "planning" hours are part of your offering (and I never use the term "freelancer" cuz I don't work for free).
The most powerful thing you can tell a client is "no". There will always be other clients, there's no reason to sell yourself short.
In fifteen years of contracting, 20+ clients , I've never had issues or questions about my hours. All software project based work on projects that span months to at most two years.
Up front, the hourly rate is agreed to, the expectation that I typically bill forty hours a week is set, we agree that overtime is only undertaken with written permission. I tell them I don't bill for lunch or breaks and that if they can't provide me with work to do, I still bill but that I inform them persistently when undertasked.
I only estimate work by giving complexity numbers. They all ask well how long does that take??? I say over the last x months, my average complexity points accepted in production is y points per two week period. So expect this five pointer to be done in a week plus or minus two days.
Do you need a better estimate? Then it will cost you two unproductive days for me to fully spec out the work and I'll need three hours of your time for this feature to give you an estimate that has a tighter variance.
This is the way it's done folks. I know what I make, I can easily have a life, wife, family. Companies make sure they have me work on most important things first and they end my project when they feel it does enough of what they need it to do.
I'm visible, I show real progress frequently and they get value out of released features early on and continuously throughout the engagement.
Sometimes I lower my rate for equity, people I enjoy working with, working on tech or a business domain that interests me. I'll of course raise it for the opposite.
In the fifteen years I've had three weeks in 2008 where I couldn't find work. I've billed between 95-155/hr CAD. Mostly enterprise custom applications. Billing systems, engineering process systems, banking apps, trading apps. Typically lead dev roles. Working in a Canadian city or remotely for USA companies. C#, ruby, scala, python. Not a great programmer, I'd get laughed out of the room on a leet code exercise but I've repeatedly delivered projects and systems where the previous teams have failed. There's only been a few of the 20+ projects that haven't been rescues.
I have a similar arrangement but I look at it much differently than you.
The retainer allows a client the freedom to contact me over what they think is nothing, because it is nothing, but 9/10 times that nothing will lead me to discover some issue that did need my attention, and I can give it that attention when it's still a nothing and not a barn-on-fire problem in their business. It also means I can log a trivial amount of hours doing the monthly maintenance that most clients gripe and piss and moan about you charging for: they already paid me. If a retainer hasn't been used up by the end of the month (and it usually hasn't) that's when I go do housekeeping for them.
Client gets a consistent-ish expense in their books, I get paid, everyone's happy.
> If you bill by the hour, first they fight you over the hourly rate. Then they want to argue over how many hours it will take to do the work. Then they want to argue over you billing them for all the project management and planning hours you are spending with them, they only want you to bill them for "the work." Then when they get the bill they want to argue over the hours you bill them.
I mean this is just the game, dude. I personally just do not have these arguments, I'm not open to these discussions. This is the price of my time, this is how much time it took, this is the bill. If people don't pay then I don't perform services and anything I have access to goes down until I will, but I've only had to do that once so far, and they got the point very quickly.
If you don't want to do this then yeah freelancing/contracting isn't going to be your bag. I don't judge you for it but like, that's just how it goes when you're in business for yourself.
Also worth noting: I absolutely charge for time spent haggling. Any time I'm doing thinking work for you, that's time I will be compensated for. I outline this very clearly from the off, and if people drag it out over hours, then they pay for those hours. Simple as. I'll never inflate my hours or make something take longer than it does, but also, I demand compensation for what's spent on their whatever.
"Amateur" isn't the word I would have used, and I think the author sabotaged his point by using it. What I would say is, you're leaving a lot of money on the table and donating a lot of cortisol to entities that don't need the money or the cortisol donations, because they're not spending their own money, and the high order bit of their success criteria is "I was able to plug money into this interface and make a business thing happen within the planned time period, without adding any headcount".
The other place I disagree strongly with the author is about the utility of flat-rate projects. I've had good luck with flat rate, but it was never the project structure we'd have used by default. Rather: for any project we did, we'd have quoted a full project, broken out into billable weeks, with a final sticker price and a paragraph below the pricing table with "additional work needed will be billed at our pro rata day rate".
I think the attitude that says "all the risk should be borne by the client, not the struggling independent consultant" is bad business (for high-end tech consulting, you should start seeing your practice as being in part in the risk mitigation business!), but that doesn't mean you need to take on extra risk just for the hell of it.
That said, there are clients who are so valuable, because they're going to be repeat-business house accounts or because their reputation is so strong that they'll bring in word of mouth business automatically, that you should definitely consider just doing flat rate projects for (if that's what they want) and just eat the overages.
> It forces the customer to focus on getting the requirements right
This is an issue that the article does not address, and it should. Part of the business risk that the article is talking about is the risk of ill-specified requirements from the client. But that means that any flat-rate pricing has to price in the extra time and effort required to make sure the requirements are well specified (and that's true even if a fair amount of that time and effort happens before a contract is signed--you still need to recoup those costs somehow). Either that or you simply have to not take on clients who can't specify their requirements well enough up front.
> This year I'm on track to bill out between $360k and $400k
> To anyone reading this [post] and thinking they are offering you helpful advice, consider their motive
Honestly I'd be happy to sign up to your newsletter and be upsold into a private $20/mo high-end consulting community forum if I were to learn how to earn those kind of numbers and I was disappointed you didn't.
Consider a company that needs a programming job done. It’s maybe a one-off, perhaps a 3 month to 3 year project. The company is not in tech and has no programmers.
Now, in this scenario they could hire a programmer at say, 100-200k, for the sake of argument. But this person might want to stay on for years, want benefits, and would need a manager. The company has no management experience in programming, so they know they’ll either do a shoddy job managing or have to hire a manager. This thing is already spiralling!
So now a consultant comes along. This person is an expert and has a track record. They are self-starting and self-managing. They can be brought on to get the job done and then they go away.
You can see that hiring such a consultant is not only far easier, faster, and likely to result in high quality, but very likely cheaper.
Which makes it crazy to me that anybody thinks about delivering work metered in hours, as if they were a furniture mover. A contract developer is selling a (quite valuable) enterprise product. You don't need an MBA to know not to do cost-based pricing.
I started "programming" in 1982 on a VIC-20, I taught myself C++ in 1991 and programmed as a hobby until I switched majors in University. Then I moved from Job to Job once I stopped learning/progressing. Along the way I made many contacts at a diverse group of companies.
I started at a medical device company reverse engineering MRI/CAT scan data for a 3D device used in brain surgery. Then I worked for a company that specialized in Bug Tracking and Project Management. Then a company that engineered optical archival storage discs with a 100 year life span. Then I managed a team developing a video keno/poker gaming machine that was available to the Nevada/Montana market. Then I managed a team in reverse engineering cell phones for forensic analysis. Then a medical company that made a continuous glucose monitoring system for critical care environments. After 1 year working on their firmware, I was brought back as a consultant to rescue the Software department as a Director of Software Engineering over product and manufacturing.
Through all these jobs I was well liked and since then have been contacted by people I used to work with for consulting work. And now I'm getting consulting work from other consulting job referrals.
I currently charge $180 an hour plus expenses, but come January 1st will be raising it to $200 an hour because of the inflation and the fact it's not stopping. In terms of stating new increased prices; through the years I've informed clients to have them tell me it's too much. Then 30 days, 9 months come back and just sign a new contract at the new rate. You have to be willing to walk away, you have to have money in the bank so you don't "need" their work, but would be happy to if they pay your going rate. Just be professional, explain that you could be making more doing work for another client and it's "just business".
I specialize in device drivers Windows and Linux, firmware, embedded RTOS and even desktop applications, mostly Windows but also can do some Qt on linux. My favorite language is C++ but frequently use C as firmware and linux device drivers are written in C. I also have quite a bit of experience managing, hiring, extracting and documenting software reguirments, architecting and implementing as necessary.
As for getting new clients, I tend to pick up a client for 3-6 months of work and still do work for them 6+ years later. In the beginning they get most of my time, later I end up sitting in on weekly meetings, reviewing their code/design, mentoring their junior level software engineers, and helping them to hire more as needed. I end up standing in as their CTO/director/senior manager as they usually don't have the funds to hire a full time one.
Given what you're working on and how close it comes to intersecting with the consulting work I've done ('05-'20) and the likely client overlap, and given the top-line dollars you said upthread you're bringing in, I'm going to go out on a limb here, way, way out, and say: you could double that effective bill rate, denominate it in days or weeks, and significantly increase the amount of money you make while working significantly fewer days every year.
I might be wrong about this, of course! But I'm not being casual about saying it.
You've had some really interesting engagements, and it makes sense to see where you are specializing at those rates.
I'm about 10yrs behind you, taught myself everything. I've been consulting for 15 years but I just don't understand how one would find these clients. I'm not sure if I'm the issue, or where I live (South Africa), or the niche I've ended up in (financial markets regulations) - hence the desire for the newsletter!
> Honestly I'd be happy to sign up to your newsletter and be upsold into a private $20/mo high-end consulting community forum if I were to learn how to earn those kind of numbers
Based on communities I am aware of that basically do this…:
1. $20 a month might get you a community that is working to get to $100k. The biggest hurdle will be simply taking action, with the second hurdle of having that action be reasonable.
2. A $50-$100 a month community might get you into the solid $100k-$500k range. I think this is your target. Biggest hurdles will be structuring work and addressing low self-esteem issues (e.g., imposter syndrome). Lesser issues will be finding reliable sub-contractors and/or communities thereof.
3. $500-$700 a month gets you into a community of folks running businesses with $1 million ARR and higher (usually as CEO rather than sole proprietor). Biggest issues will be things like hiring (especially key CXX-type slots), info on lesser known/documented processes (typically easier once it has been done once), and info on broader issues (e.g., outsourcing to $COUNTRY, to-the-minute status of manufacturing in $COUNTRY, etc.).
The numbers can go higher.
All of the above will also have an element of sanity check (“is hiring really this tough right now?”) and commiseration (“omg, my sales guy has to have his emotional support emu next to him in every zoom call!”).
I see that your niche is in C/C++ world (with some Obj-C), low-level stuff.
Mind if I ask how's the market and what kind of clients (companies?) that you worked with? If you don't feel comfortable sharing the list, would you be able to share some hints?
Out of curiosity because my background in college is more towards System programming but life puts me as a full-stack and backend/cloud engineering. Gettin a bit tired with too many backend tech (too many different storage solutions, backend languages, etc)
Most of my clients tend to be Medical Device startups, but I did have a really long relationship with a major food manufacturer. While it makes sense for them to hire full time software engineers for some of the work, they always have a hard time finding device driver experts. Also they tend to attract less experienced engineers, so having me on board helps to manage and mentor their team. And I'm generally the one laying out the architecture and breaking the project into smaller parts so their engineers can implement it.
If you want to break into consulting, you have to figure out which field you want to be in. I'd avoid anything that has a boot-camp available for it, that's a race to the bottom. Then you need to get at least 10 years experience working in the field, preferably at a variety of companies, and make friends and business contacts at each place.
I have 10+ years working experience mostly in Cloud (think Java/GoLang/Python, AWS, Kafka, DB backed system, with 4+ years in front-end JS).
Less experience in device-driver/OS development, system programming. I'm definitely interested to explore Linux/FreeBSD/Kernel or Device Driver type of work for fun. Would be great if I can make a living.
Would also love C++ experience, but prefer not writing AppServer bizlogic type if possible, I'd rather do it in another platform.
You interpret a free opinion article that addresses a general topic as directed at you personally, take offense, then ad hominem question the author’s motives. He’s doing a little self-promotion, as you do and we all do online, but he’s not trying to “change the current consulting landscape” to benefit himself. Whom do you think reads his articles? None of my customers will.
It should go without saying to non-amateurs that exceptions happen, no general advice fits every situation, and your mileage may vary.
Then you boast about your own success. You don’t add anything to the conversation, offer no meaningful critique.
Good for you with the high earnings and luxury SUV. For most freelancers (or consultant if you prefer, clients don’t care how you style yourself), especially the amateurs just starting out, the article addresses a very real set of problems. Those less experienced freelancers do face a race to the bottom as commodities. The article might help them think about how they position themselves and structure their projects so they aren’t struggling on freelancer marketplaces.
If readers take nothing else away from the article they might think about adding business value versus selling their time, and having some skin in the game (assuming some risk) as a way to build better relationships with clients and improve their technical and business skills.
> It forces the customer to focus on getting the requirements right instead of hand waving it like "oh yeah, that's just what I want" and then come back later "I didn't want that, what I meant was" repeat ad infinitum.
This is amateur because you are leaving an insane amount of money in “change orders” on the table.
That is fine if you don’t want to do it, but it is sub optimal for maximizing your revenue stream.
Incline Village is the closest you can be to the Bay Area and still live in Nevada. It's where a lot of tech folks go after they exit or if they get a remote gig because then they don't have to pay income tax, but are only a 3-4 hour drive to SF if they have to go in.
It also has great schools.
So you end up with a lot of moneyed California ex-pats there.
> Incline Village is the closest you can be to the Bay Area and still live in Nevada.
Factually, no, its not: Stateline, NV on the south shore of Lake Tahoe is 15 road miles closer than Incline Village on the north shore. About similar drive time, though.
Professional business people are familiar with different business models, and when to apply them.
For instance, hourly billing makes a lot of sense if the scope is vague - the client carries the scope risk.
Fixed price is amazing when the client has a specific, measurable problem that they don’t know how to fix (but you do). You can solve it cheaply, get paid waaay more than hourly and have a happy client.
Being a professional means having multiple tools in your toolbox and knowing how and when to use them. Drafting contracts is all about deciding how the risk will be shared - you need the right risk-sharing model for each situation.
On the flat rate model: I like to tell the story that the highest hourly rate I've ever earned to date was as a college student when I took on a fixed rate project to fix some department's "we have a web form that is critical to our work and backed by this perl cgi script that used to work but doesn't do anything anymore" problem.
Turned out someone had uploaded the perl script to a Linux server using dreamweaver on a Mac, and the line endings were wrong. So I ran dos2unix on it and added a blurb to some documentation on what not to do and how to fix it again if necessary.
Made $1000 for less than 15 minutes of work!
But of course I also could have spent two weeks bashing my head against an awful perl script, never figured it out, and made nothing. It's a risk/reward trade-off.
Game development adds another dimension. A musician I know helps small indie artists with music as a side business. His contract states a fixed number of hours producing the music and effects is free, until earning some 100k revenue / month, when it starts costing 0.1% of revenue royalties / month. He has fun with it, it's usually free, but if someone makes the new Minecraft with his music, he will get his share.
Sure you can. At 100k / month revenue, you have 100 currency / month or 1200 / year available for another artist, which may or may not include the risk of messing up the "feel of the SFX and music". Even at 10x that, that's a paltry sum, especially if identity is tied to it.
> Fixed price is amazing when the client has a specific, measurable problem that they don’t know how to fix (but you do). You can solve it cheaply, get paid waaay more than hourly and have a happy client.
What about fixed price makes the client happy in this situation? It's definitely not the fact that the contractor billed "waaay more than hourly".
The upside of fixed price is that it's more predictable and it aligns incentives. With hourly, the hidden incentive is to take as long as you can get away with because every additional hour you take is an additional hour you can bill.
With fixed price, the contractor has an incentive to finish earlier.
That's the part that I find many contractors miss: They treat fixed price as an opportunity to extract more money from the customer. As someone who has been on both sides of this (I've been a contractor and I've also hired a lot of contractors) I lose trust quickly when I spot contractors inflating fixed price bids because they think I won't be able to recognize what they're doing.
Is it "inflating the bid" or "charging a premium for fixed cost".
You are welcome to haggle on price or not hire them. As a freelancer or bussiness owner, not every prospective bussiness deal goes through. That is not a failure of their model, just the realities of commerce.
What you mean to say here is that time & materials project structure makes sense when there's a lot of scope risk. Hourly billing never makes sense in our field, unless your bill rate is so high that all of your projects are denominated in small numbers of hours.
> when the client has a specific, measurable problem that they don’t know how to fix (but you do)
Then the client tells you that wasn't their problem in the first place.
In the 10 years of contracting I've never done fixed rate for the reason the client never knows what they exactly want. It's not like installing a tiled floor or drop ceiling.
Being a professional means a lot of things, but fixed rate contracting is amateur hour truly. Every software dev learns this eventually.
Which is why you have clear boxes on that fixed-rate, and stepping over those bounds means you're back into T&M billable. The legalese on these contracts needs to be quite tight, but it's a one-time expense to set that up, and it's best done properly (and updated as new edge cases show up).
Yeah I'm honestly amazed at how many software people don't get that the optimal strategy is cheap fixed price and incredibly high margin change requests.
That being said you need a good spec to do this, and that definitely isn't normally the case in software.
There is so much work out there that is cut & dried. It's not what you'd call software engineering stuff - more the bread & butter of consultants. But you really need to know the domain space to ensure you have those cutoffs (some of which might sound very limiting). About 3-4 times after you've deployed a specific solution for a specific vertical, you should be able to productize it (on 2nd and 3rd times through you're essentially spending extra effort to determine and test those boundaries for future implementations).
Often the goal of a cheap fixed price is to show how limiting that is so they know why you can't productize a fully customized solution.
You would be amazed to know how many problems have been solved in software, but the client has no idea what the solution is or how to implement it if they did.
One thing I've noticed more now that I read HN more than other places...
Software people sure like to talk/write a lot of about their business. Like, a lot.
I'm a mechanical/aerospace engineer, and I've done some short term consulting for startups (but now mostly retired).
There is verrry little online in the form of blog posts like this mulling over how people work in that type of engineering (especially in the higher-end of the field, like what happens in automotive and military/commercial aerospace- it's all very closed-doors). Especially less in the methods/metas of the field and the business surrounding it.
But software people? HN is flooded everyday with long form exposition just like this blog post. And it's honestly been pretty eye opening reading how much people pontificate in this area. Like, goddamn. I'm starting to think people talk about their ways of work more hours of the day than they actually.... you know... work.
Corollary: Take a generalist observation about any type of creative work, stick "developer" somewhere in there, and act as if developers are unique and/or the observation is new.
Example: Not long ago I kept seeing some variation of articles about how meetings are bad for developers. Specifically developers.
Guess what? This is true for pretty much any creative type work like writing, design, or any type of work that involves deep thinking. But it was treated like a revelation because it was about developers and made no case for all the other workers in the same boat.
This piece? I could've written this 20 years ago as a freelance writer. Generally I refused to stick an hourly rate when dealing with clients for lots of reasons, not least of which that when I know a topic and it's in my wheelhouse I write very fast. (And if I struggle with a topic, it isn't on the client to pay for extra time...)
My dad could've written it 45 years ago as a sign painter and pinstriper. He charged by the job / value of the work delivered, not by how long it took to do. (Insert Picasso anecdote about "but that only took you 30 seconds," "yes, but it took me a lifetime to learn...")
At the time his craft was highly valued, hard to learn, and the difference between a good sign painter or pinstriper and a bad one was enormous. If there'd been a Hacker News for his field, maybe we'd have seen the same thing. Then came vinyl signs...
In this particular case the author is using a controversial headline to drum up attention for his business, which he plugs about 2/3rds of a way through the article. I think web developers in particular are more familiar with SEO and web-based sales and are more likely to write about software in an attempt to funnel eyeballs towards their software business ventures.
I think it has more to do with software engineers being more likely to have spent a significant amount of time with the internet, (some form of) internet culture, and then sharing on the internet. Outside of software engineers, there are so many people who run businesses whose internet exposure ends at writing emails. These people might be just as willing to talk about what they do, but it's going to happen in-person, not on a blog post.
I do a combination of fixed price and time and material work.
Sometimes fixed price is a good model, sometimes time and material is a good model.
Fixed price works when you know the scope, and are confident that there won’t be roadblocks and rabbit holes. If a project takes longer than you think, you are eating the difference.
There’s nothing wrong with charging per hour if you know the value of your hours. Charging by hours gives you a level of certainty regardless of scope change.
IMO the smart consultant/contractor will use both models, then pick the right one for the project and client.
To give a specific example with respect to writing.
Want an article, blog post, or somewhat longer customer-facing material. So long as I know something about the topic and know where to go to get more information (maybe from you!) I'm happy to quote a fixed rate (+/- word count requirements). I have a very well-calibrated sense for how long this sort of thing takes and I'll put in some language about review cycles, etc.
If you're a law firm that needs an expert witness report, I'll almost certainly charge an hourly rate (which is what the law firm likely expects anyway).
Well, I found this article insightful, even if I've no plans of going freelancer (though of course... "life, uh, finds a way", so who knows).
I think my most immediate objection is one that is raised in the comments from TFA: customers don't know what they want. For a flat rate to apply, you have to work to an initial set of requirements set in stone, and we know these requirements are almost always wrong (except for very specific cases), so either your customers will try to do feature creep or they'll accept the initial specs and be disappointed, and probably blame this on you.
It's not always like this. I've used contractors to take on extra work that we were familiar with, but didn't have time for. We knew exactly what we want because we'd done it multiple times before and had already written a clear spec.
The eye-opening thing was that this actually scared a lot of fixed-bid contractors away. As soon as they realized that we knew the task and had the option of doing it internally (on a longer timeframe) they became less interested in working with us.
When I started playing dumb and pretending like we didn't have the experience in-house, I got some wiiild bids for how long it would take. Some of the contract shops who had clearly done this before tried to pretend that we were doing something new and novel that would require a lot of R&D.
It was a very disappointing experience. Once of the worst contract shops was even the recommended support partner from one of our vendors.
Yeah fixed bid for most sw projects just seems dishonest and not a satisfying way to work with people. And yes, I could easily make a business out of overcharging for cookie cutter type work. Speaking in generalities, there's always exceptions.
>Well do a short proposal to quote you a big proposal
Did that for a pretty large client project once. Basically brainstormed/did some research to pick out some technology areas they might be interested in and why. Then did a bigger project to dive deeper into areas, conduct interviews, etc. that resonated with them.
It works well. And if they don't want to use us as the programmers, no problem, we deliver a document at the end of the first with recommend designs etc they can tak else where. T
As a freelancer I always told my customers how many hours I plan to work for them, including a rough overview of how much time we use at which phase of the project and what is expected of them.
Interesting. Wouldn't that require a firm understanding of the project scope and a steady hand at rejecting any attempts at feature creep or redefining the scope (with the politeness required for not losing them as customers)?
In other words, wouldn't this scoping and pre-planning go against the latest findings of lowercase agile?
That depends entirely on the type of projects you are known for (read: are willing to take). Some software projects agreeably will be next to impossible to estimate, others not so much.
That being said I always bill per day of work, rarely ever a fixed sum (in fact only for good friends that are poor artists). So if the scope changes and there are more days, they know my rate and it will be their decision if they want to pay for that. Also they will have the insecurity of me not having time because I work on other things — risks that I clearly communicate before they agree to have me.
I expect a certain amount of changes and feiction that is included in my original estimate, so this "extension" period is rarely ever needed and when I am faster the customer has to pay less than they expected which typically makes them happy.
It doesn't always work that flawlessly, but it was never catastrophic and my customers value the up-front clarity.
If someone's a pro, they'd charge a flat rate to tell the customers what they need, or for a given outcome. Like a flat rate to spec out an MVP. Or to get to $X in revenue.
I hear what he is saying, but he stops half way where he says 'take responsibility for outcomes'. You see. In business this is translated into fixed price projects.
But in contrast to the name there is nothing fixed price about it. As a provider of such project deliveries, unless you truly are an 'amateur', you still are acounting cost plus if the project goes into overruns. The way you do this through 'change requests'.
You see, you can't nail down a contract taking into account every possible interpretation of details on a bespoke software project. So the customer will always need to clarify and adapt. This will be translated by your sales team into additional costs until a margin is met.
The only way out is using of the shelf product, and even then you will probably have an 'integration project'.
I think the lesson here is bespoke software is probably a bad idea for a lot of companies and you're better off buying off the shelf shit. I think this is particularly hard for a fortune 500 company though, especially for something like a website. You're too big for a Wix site but employing a team of developers is going to cost you an arm and a leg and it's really not in your wheelhouse. We'll probably see more software outsourced going forward.
If you are happy about where you are in life and are making close to half a million dollars a year, like some on this thread, feel free to ignore his advice.
If you are stuck in the race to the bottom and wonder why, for example, the company's management doesn't pay attention to anything you say, then read his blog.
I have to scroll pages and pages to discover the answer: take risk and sell fixed price because that’s what customers want and differentiate you from the rest of the freelancers.
The whole article feels like asking GPT to add filler for the first 3 pages.
I think the opening sections were necessary to define terms and clarify why an extremely well established system (hourly billing) might not be a good thing. It’s a nuanced argument and requires some verbiage. Maybe it could have been cut down a bit but I think it was important to include.
Standard SEO playbook - 1,000 words frontloaded with keyword-laded filler.
It's particularly banal when it comes to recipes. "What is a cheeseburger receipe? Why would you want to cook a cheeseburger? What's the best approach to planning the best cheeseburger recipe? What cheeseburger equipment is required for the best cheeseburger? Oh, and here's the best cheeseburger recipe you were searching for."
I found this article helpful. Most comments on here seem to suggest that hourly is best done when clients don't know what they want, and I think that actually misses the point of the article, in my understanding.
Working with a few customers as a freelancer, I agree, a lot of time they can't express what they actually want. They know it when they see it, but they can't express it correctly so you end up building a product, and having a thousand change requests - basically the customer uses you as a prototyping machine until you build what they want.
Obviously this can't work with fixed pricing, BUT this is where the point of the article comes in. If the only thing you can offer to your customer is writing code based on a requirement - you're racing to the bottom because thousands can write code based on a requirement.
BUT, if you focus on outcome - I will build you what you want, AND I'll help you figure out what that is!! That service will include asking the right questions, helping the client figure out what they want, and you can put all of that in your fixed price offer. At this point you aren't just writing code for them, you are their business partner, you want them to succeed, and you will use your experience to offer advice. If you become good at this, you are much more than just a programmer, or what the article calls "technician".
So, thanks for the article, I found it interesting and have some food for thought.
This article is amateur hour. And by that I mean "amateur" in the sense of "lacks the business experience to see past their own narrow experiences".
I work for a consultancy that works for some of the biggest investment funds in the world. We do some flat rate and we do some hourly. Sometimes hourly is exactly what the customer wants and is aligned with our interests. Sometimes it's not. I have also freelanced successfully with the same experience, and as a customer there are things I absolutely want hourly.
For example, discovery should always be hourly, or you screw it up by making discovery that leads to a no-go conclusion unlikely, even if no-go is the Right Thing. One of the best things I ever learned for consulting was how to do this - clients who have paid you a reasonable fee to discover that they are not ready to go ahead will be talking about your honestly and credibility to anyone who will listen. Managing when things should be hourly or not is a huge part of what builds credibility. Blanket statements about how one should never be trying to do hourly work reveal nothing but business ignorance.
Interesting read. My freelance work has never been by the hour, and for reasons that align with those mentioned in the article.
Clients don't care about hours I spend, my hours bring no value to them. They desire a certain result, and they know how much that result is worth to them.
For my freelance tasks, I've put forth a rather steep one-time price for the solution of the specific problem at hand. The condition: The price is paid when the problem is solved, if not, the service was not delivered, they don't pay.
This works out beautifully for the client, they run no risk (except the delay in waiting for me to fail so they can try someone else), and they know exactly what they pay.
It works out nice for me, since I have a reasonable idea whether I can solve the problem or not.
Hourly rates for those tasks have been close to $1000, including failed tasks where I spent some days not solving the problem.
In the end, it's also very fair to both parties.. It's reasonable to expect the agreed-upon result when paying someone to do something.
It's also unreasonable to expect to get paid for not doing what was agreed upon.
A concrete example I can talk about was a client whose database had started "acting up a lot" and they had no idea what was wrong, they were very friendly and told me they had contacted another company too who had quoted an hourly price around $200 but were unwilling to estimate how much time they would need, since they didn't know what the problem was. So I said, "I'll try and fix it, if I succeed it'll be $4000", that's a fair amount of money, sure, but it was pretty good value to them to get their inventory database back up. It turned out to be an unhandled edge-case that only showed up years after when they introduced a new kind of item into the database. I had to learn a little bit of VBA(!) to fix it, but in the end, it took about 2 hours, and you might argue that price is too much for those two hours, but they didn't pay me to spend 2 hours, they paid me to get their database working again.
It depends. I do plenty of billable hours augmenting software teams. I'm delivering user stories every week. There's simply too much communication overhead in preparing weekly estimates for the same client.
I don't share the perspective on hourly making someone a commodity. Fixed outcomes can also be commodities. Clients can and do shop around estimates for the best price. The race to the bottom exists whether you're billing by hour or by outcome. You avoid the race to the bottom by what you sell, not how you bill. Wordpress themes are mostly a race to the bottom, regardless of how you're billing.
It's incredibly important to have a clearly defined scope prior to entertaining fixed pricing. If expectations are not established with the client, they will make assumptions and they won't be in your favor.
If expectations are not established with the client, they will make assumptions and they won't be in your favor.
I think you can shorten this statement even more.
Clients will make assumptions and they won't be in your favor.
The goal is to limit those as much as possible, but they'll still happen. "Fixed price" is largely not fixed anyways, as you should always account for change requests and other budget altering mechanisms. I don't think I've ever seen a non-trivial project not have some level of change once work has started.
>The goal is to limit those as much as possible, but they'll still happen. "Fixed price" is largely not fixed anyways, as you should always account for change requests and other budget altering mechanisms. I don't think I've ever seen a non-trivial project not have some level of change once work has started.
These need to be handled as separate change orders. Following the model, price the scope changes appropriately based on clearly defined requirements. This part takes some finesse. Many clients may not realize how they can achieve their goals in the most cost-effective manner.
Also have pre-established policy for revisions. Like 2 minor revisions included in the cost but then have further revisions priced by how complex they are.
It's best to shy away from explicitly including things like "2 minor revisions". Who determines if the change is minor or not? The client will always assume minimal effort is required. If the change is in fact minor, then just implement it.
If the change is significant, then provide a price for its implementation.
Specifying that minor revisions are included in the agreement provides too much ambiguity.
Then your interacting with your client in a rigid contractual way instead of a collaborative creative nature. Not nearly as fun and you spend a lot of time being very careful with your written words and your sign offs.
Some clients are absolute pains with flat costs. They argue over scope, then argue over the definition of done, then they argue over features that were not in scope and refuse to pay you until you do them (for free.)
For these "special" clients, I found the best model to be a pre-paid declining balance retainer. Nothing gives more focus to clients than a slowly ticking meter. Further, i'd set the rate to be something that is worth even bothering with such clients.
To each their own I suppose. In my personal opinion, hourly billing is economically aligned to better product-stakeholder fit. Without economic cost, stakeholders seem to tend toward over requesting / flip flopping resulting in a worse product. I've experienced this in larger B2B projects where those customers who paid monthly where incentivized to filter out the things they don't need and focus on the high value functionality.
I've been a consultant for 15+ years and have often come to this conclusion that hourly billing is not ideal for various reasons. I haven't found a great alternative, and the problem is I'd want a great alternative I could enthusiastically sell to my clients. "Always do fixed price" doesn't seem feasible when scope is not fixed, fixing it would necessitate time-consuming research and waterfall style project management, and clients often don't know scope until they have tangibles in hand. (ie "this looks great, but can you do this "little" thing we invision in scope, but you invision out-of-scope-but-not-worth-arguing-about"")
I feel like a retainer of sorts may make sense, but that seems a hard sell for some projects. "Make us this 5 page app that does XYZ". "Ok, pay me X/mo forever". Both consultant and client would need an exit that I'm not clear on. Also, to be honest about it, the consultant should limit their clients to some reasonable number so that they can serve them in reasonable time.
>> I'm genuinely curious: what is the difference between hourly and daily/weekly rates?
Clients start haggling on a hour by hour basis sometimes. Some want to review tasks and how long each took and whether the hours add up. Sometimes, it takes so long to figure out the conclusion of the haggling, that you've already lost 2 or 3 hours of non-billable time on the haggling itself.
The longer the unit of time, the less pressure there is for either side to micromanage the work, or to avoid time-saving optimizations, or to invoice random conversations that could lead to new business, or to cram multiple clients into a single day when that's not what you want to be doing.
I've written a lot about this on Hacker News over the years; like, a lot a lot. Here's a starting point:
I don't think anybody in our field should ever be billing hourly. Day/week/month/quarter vs. flat rate? We can go back and forth on. Just don't do hourly.
This comment is I think too subtle to lead off with, but it's the essence of where I'm coming from on this:
(I have had some moderate success with this approach, which makes this a rare case in which my confidence in arguing something here has at least some colorable basis in reality.)
This makes sense but I've never been taken to task for hours and many of my clients charge me out to their end clients for hours I submit.
The other advantage is that hourly tracking gives me data to predict better what new features of similar complexity will cost. Certainly not an amateur capability.
You're free to do your own internal projections about the number of hours your features will take. Simply round them up to the nearest whole number of days, and present that to your customer.
Hourly estimating takes too much time and it never gives useful numbers even with various padding schemes when estimating innovative sw development. Cookie cutter web sites or repetitive work that you've done for multiple clients is easy to fix bid but I don't do that sort of work.
I just say this has a complexity of 1,3,5,8 or 'too big to say'. Each feature is a 1-15 minute conversation to get this number. Then they ask well how much time is that? I then answer "We have three months of velocity data, x points per developer per week accepted into production over the last ten weeks so those five new points for that feature will take one developer 4.1 days to complete with a variance of plus or minus 1.8 days. If you need better precision, we can take a day or two to really break down the work and get the uncertainty to at best a ten percent variance.
Didn't feel like a debate, just trying to increase understanding on both sides. If you follow what I'm saying, I don't ever try to estimate hours anymore, I just use past data on complexity and then translate that to hours if ever required. There's very little time and stress, and effort for estimating. It's incredibly accurate over several features too and it is easy for stakeholders to decide cost vs value of each feature.
This doesn't account that software is (relatively) easy to change, vs say building a house (to use a cliche). The client will want to see it as it progresses, and then change based on what they have learned is possible. This is the agile way.
How would one account for a fixed cost then? Do you say ok it's a fixed cost, and you get 6months base on our estimate (but if the 6months has finished the contract ends, and isn't that just a time based project). Or do you tell the client no changes after the initial requirements (which doesn't sound flexible and you end up building something the client doesn't want)?
I tried this. A very large company reached out and asked for a custom version of diffdiff.net. They asked what my hourly rate was, and (thinking along the lines of this article) I offered to do it for a flat rate instead.
They ghosted me!
In retrospect, a "very large company" didn't reach out, a relatively junior person at the company did. I should have worked within their constraints. (Or just not taken the job, which, I guess, is effectively what I did).
If the scope is fixed, you're selling a product. That product might be a one off, and it might be purely a service product, but it's still a thing to be sold at a price.
Generally consultants are not selling a product. They are hired to bring knowledge and experience to a team, to be there when needed, and to offer flexibility for which it would be time and cost prohibitive to develop an internal employee.
When you bill by the hour, what you’re really saying is “I have no idea if what I’m doing will have any value, and I honestly don’t care — all that matters is that I am not exposed to risk for even a single minute of my time working for you. I get paid for every minute.”
Yes, that's the point. As a software freelancer you have no responsibility to take on risk for a client company that you have no ownership in. You'd be a fool to do otherwise.
Every hourly billable contract I've signed has included a detailed scope. Contracts that very clearly delineate responsibilities and compensation. Both parties are agreeing to the value the freelancer is providing. You'd be a fool to hire a freelancer without understanding the value they provide. And as a freelancer you'd be a fool to sign a contract without clearly defined responsibilities.
The author seems to believe the method of compensation determines the value provided. But these things are orthogonal. I've worked with multi-million dollar agencies that bill by the hour. They provided a lot of value, they knew precisely the outcomes they were responsible for, and delivered those outcomes.
Blog posts like this come along every so often, usually when a freelancer discovers that there are circumstances where they can make more money on a fixed cost contract. For instance "This project will take me 40 hours. If I charge $100/hr I'll gross $4000 total. Or I could quote a fixed cost of $5000 total, and net an additional $1000".
The downside is estimating software is hard, mostly because the end product is almost always a moving target. Generally speaking, clients have a good idea of what they want. But "what they want" almost always changes as a project progresses.
The upside for the freelancer is that if the scope can be nailed down, and a client is predictable, a fixed cost model allows the freelancer to capture any additional value/profit from their productivity.
Which is why savvy businesses are fine with paying hourly rates. They want to fully capture the value of the freelancer's productivity.
In my experience, from a freelance point of view, it tends to be a wash. There are many fixed cost projects where you will come out ahead. But there are always projects with tons of scope creep, and cost increases are almost always more difficult to negotiate on fixed cost contracts. But YMMV, and there's no single correct answer.
Most legal firms do something in between, you pay a retainer or a minimum package, and then they bill you hourly
They get the money upfront, before they do any work
So, from the get go they know the minimum they are going to make, and they never get stiffed (also because most people don’t want to get into legal issues with a lawyer)
Is this the equivalent of pointing out people eating alone at restaurants because he thinks it’s weird? Contracting can be good and the downward pressure stuff is false because of trust issues and networking effects.
This is nonsense. If you bill fixed, then you're doing it wrong if you estimate so lean that you put yourself at risk. And it's a disservice to the client if you are really conservative and they pay a lot more than T&M would have been. And if you are spot on with your fixed estimate, then that's the same outcome as T&M lol.
If you are an honest person and do business the right way, T&M is the way to go. If you want a higher effective hourly, then you would pad fixed. That doesn't make you professional though; it makes you dishonest if you purposely inflate.
If the company needs it to be fixed to compare apples to apples or their finance dept requires it, then submit your fixed scopes and run your business. It's professional to be flexible. And to not fight client processes and procedures.
You will not win a lot of great business if you have only 1 way to run your projects. Some larger companies will take a vendor that costs way more but offers better terms like net 45 or net 90.
I'm a professional. I run a business with employees that's grown every year. We do both, but it's better T&M. All time is logged with descriptions of what was done. We bill based on seniority.
We still do time estimates on items that are T&M so my team is accountable, thinks about their approach and time, and so the client can have an idea of what they are committing to. They don't care if it goes over, it just can't get out of control. And they need this information to triage and approve requests.
T&M with time estimates is a professional way to go. Some of your estimates will be off, some will be under. Just make sure clients understand that and traffic your wins and losses. And if you find out your 24 hr task is going to take 60 hours, notify the client as soon as you discover that to avoid surprises.
I'm experimenting with a more traditional contingency budget which is explicit in the estimate. In that manner, a fixed bid would be done but the client would be aware that there could be unknowns that result in tapping the contingency budget. And if it's not tapped - they don't pay it. So rather than try to bake the unknowns into the fixed which the client would pay regardless, I can have the contingency reserved if needed but be more palatable against a competing bid that wraps it into their fixed.
So say, 100k fixed bid, separate 20% contingency for unknowns for my bid. Versus another company's 120k fixed bid, no contingency. Both possible 120k spend. One may not use contingency and thus be 20k cheaper. The other - 120k is paid no matter what.
Anyone do that on their larger projects? How is that received?
Heh, it seems like this article could easy be called "hourly billing considered harmful" and I would basically have the same critiques of it as most "<popular tech> consider harmful" posts.
I won't pretend I have years of experience in the freelancing world... I am fairly new to it myself. But I do know as engineer who also has done some stints in product, sales, and business side, that, just like in software, there is no one "right way" and that one of the most consistent challenges business face is choosing the best of many reasonable options, especially when one of those choices is viewed as a "best practice" but the team lacks the direct experience to answer the question of "best practice for who and when?"
I fully agree with the author that there are some real market forces that can make hourly work not the ideal for many situations... but I also think it massively over simplifies the different types of work that are done as "freelancing".
Whole new products, new features in existing products, taking over projects, rescuing projects, consulting with less experienced teams, embedding in teams, integrations of external tools, is probably only 25% of the type of engagements a single consultant may come across and probably only 1% of the type of engagements that exist. Combine that with the huge range of attitudes of companies and very quickly we are in a space where no single solution exists.
It seems like the author's true point is in the conclusion, that you should focus on driving value and results for your customer and you should structure work to align with that, which is absolutely true. The general take of "hey engineer guy who isn't as business savvy, that value might not be best delivered via hourly billing!" is not bad advice. If you do hourly billing because it is the most straight forward, you should probably think about it... but you also shouldn't move to project based billing because of some people calling it a best practice either.
My advice to any engineer looking to freelance (but really to almost anyone everywhere in this industry) is to not take the easy way out when facing decisions outside your domain. I think so often work seen outside of code is seen as "lesser value", and because of that, shortcuts are made by just taking the easiest or "best practice" answer to a problem and running with it, and not gaining any understanding of the problem space. No one can be an expert in everything, but when you can't make this decision someone else's job, like when a business doesn't have some expertise (which in freelance is always the case) then you can't afford to not put in the time to learn enough to at least be informed. If you then do decide to do the easiest / best-practice thing, at least you know why you choose that option and can later evaluate how it is working for you.
In summary, there is no simple answer, be thoughtful and keep trying new things. What works for one gig may not work for another.
I also don't compete, I'm not on any "freelancing" websites, I don't apply or bid for work. My clients always come to me, I get an email, a phone call asking if I'm available. So this race to the bottom nonsense is utter crap. I'm a consultant NOT a freelancer.
I've been doing this since 2011, that's the last time I had an employer. This year I'm on track to bill out between $360k and $400k. If that's "amateur" so bet it. Considering I have no debt, my house is paid for, my luxury SUV I paid cash for, my actual monthly bills are around $2,500 a month. I really couldn't care less what someone who writes an article like this thinks of me. The writer is advocating for the client, they aren't giving me advice that helps me. I also have no interest in scaling, on bringing on employees. I'm making bank, I left CA in 2013, currently live in Wyoming with a 40 minute drive to Park City UT and a 60 minute drive to Salt Lake City.
To anyone reading this article and thinking they are offering you helpful advice, consider their motive. What are they trying to sell you? Are they trying to change the current consulting landscape to benefit themselves as a business owner?