Hacker News Reader

Comment by danso | Hacker News Reader

I've never been a freelance developer so I don't know what my rate would be...but I would really like to get some insight on what $200+/hr web-development is like. I mean, what are the expectations versus a $50-developer?

For example, I could probably build in 10 hours a customized, nice-looking Twitter bootstrap Rails site with Stripe integration and deploy it onto EC2 and set up Capistrano to integrate with whatever existing Github flow they have...but then when it comes to building the admin...um...developing the admin from a technical standpoint is non-trivial, but developing it in such a way that it is hassle free from the client...How exactly does the developer do that, without extensive consultation time with the client? And what if their in-house developer (let's pretend they have one who is competent) doesn't have a workflow like I imagine a good workflow should be?

In other words, I'm having a hard time imagining what a rockstar developer could singlehandedly create that would be spectacular and would be something that that mortals can use and maintain on their own...but obviously that's why I'm not a $200+/hr freelance developer.

View on HN

Your problem is that you're thinking in terms of 'what do I have to type'. Most programmers can just type out the software to do something if somebody else tells them what that 'something' should be. That's not hard, and the path to learning it is straight-forward and well-defined. The value in a consultant is not in 'programming'. It's in translating whatever problem somebody has into a solution. Nobody cares about a 'Twitter bootstrap Rails Stripe EC2' whatever. If you find yourself even saying those words to the person who'll be signing your cheques (as opposed to the tech staff you might be working with, but those you'll only talk to when you got the job), it's game over - you're now a $50/hour commodity.

"How exactly does the developer do that, without extensive consultation time with the client?"

Well yes you answer your question yourself - top 10% rates are for those who can make the customer happy with the result without having to drag exact specifications, kicking and screaming, from somebody who doesn't want to deal with all those details.

(also, here is the first hint: somebody who thinks about '200$/hour' has the wrong mentality. I do projects where my rate is that, but I never ever (ever) put it that way. Sell services based on benefits or value for the customer, not on how many hours you're going to spend. Nobody cares whether you've spend 6 weeks working 100 hours a week, or if you send 5 emails with the right words to a few people and wrote 100 lines of software on a lazy sunday afternoon. Effort: irrelevant, make customer happy: only thing that matters.)

Why are we trying to turn programmers into product managers? At my job, it is exactly the job of product managers to distill what management wants and turn it into little implementable chunks for development.

"This box thing appears here. It should have X Y Z info from the object" which was born from "Let our customers know about the new object".

Aren't you going to see a lot of the same requirements from projects as a consultant? If so, then you're just implementing something you've already done before, +/- some unique features. So if you're something like a 10x consultant or a $200/hr consultant, are you doing that because you're dealing with new problems constantly? I'm a little less impressed if someone can command that rate and has done 20-30-50+ projects in the past that are mostly the same thing. That's just paying for experience.

Experience is highly valuable in itself as well as being relatively scarce

More to the point of the post, it sounds like 10x is a marketing rebrand for experienced developers (genuine experience, not 1 year repeated 10 times). Especially if 10x is more about the soft skills. I have no idea what level of technical talent a 10x dev might need.

lots of experience and the ability to learn a new language and be productive in 2-3 days and have skills in hot tech I have seen data science gigs at 1000$/day and that's in the uk where rates seem to be lower

1000$ ~= 640 pound ~= 800 euro - that's what a 'regular' consulting firm (i.e. not big four who will charge double that, but medium sized regional players) charged for a fresh out of school grad, in the UK. It's only slightly more than what a secretary in a law firm costs (although to be fair, they don't get billed out by the day). It's roughly what the most simple engineering studies are billed at ('calculate required dimensions for this steel beam with uniform load' - i.e. the sort of work they let (supervised) interns do, structural engineering 101).

Really, everybody reading this (yes also those in the UK!), if you are an experienced or senior software engineer and you're billing yourself out at these rates ($1000 a day), you're leaving money on the table. If the mentioned work is what I consider 'data science' (i.e., advanced applied statistics requiring fair amounts of high-end, performant software engineering), then $1000/day is really low if it's for anything more than what somebody can do as a weekend gig next to their day job.

Agree although I would say that big 4 consulting firms charge much lower _average_ day rates than many small-mid agencies. It's a particularly effective ploy for winning gov and big infrastructure contracts. They make money by scaling to 100's of bodies on projects, mostly offshore (and even then their overall margins are wafer thin due to huge operational inefficiencies and shoddy program management).

"Why are we trying to turn programmers into product managers?"

Nobody is doing that AFAICT, it's just why being a consultant is different from having a job.

"Aren't you going to see a lot of the same requirements from projects as a consultant? <snip> That's just paying for experience."

Well sure. It's the experience and the domain knowledge that makes that somebody can do something at a higher speed than someone else, and that somebody knows what a customer is looking for without them having to spell it all out. I'm nobody special, and I'm certainly not claiming that I'm a '10x consultant' in the sense that I'm 10x better than the average or whatever. I was just reflecting on the underlying mis-assumptions in the GP's question.

Also, it's not because somebody bills 200/hour that they make 2004050 per year. Jobs are not like doing consulting. I'm doing OK, but (after discounting for everything) I'm making roughly what a senior employee would. Some do better, again I'm not claiming I'm anything special (and I guess I shouldn't have made this about me by mentioning an example from my own work) but some of the 'calculations' I've seen in this thread are nonsense. It's like people saying 'Mohammed Ali made x million per second in his fights'. Uh, sure.

The most difficult part of most software projects is the interface between people who have the problem and programmers. Most programmers don't have the ability to handle this part themselves. This is why we have product managers/business analysts. If you can perform both roles, it's amazing how much faster/better the project goes.

Product manager is an imperfect solution to a problem your customer doesn't care about any more than he cares about the name of the obscure sorting algorithm you used to scale his system 1000x.

$200/hr is like a buffer, or insurance if you will. When you're working with a client, most of whom are non-technical, you have to invest A LOT of time explaining things or re-doing things because it doesn't work the way they imagined it in their head.

You don't want to charge $50/hr then end up doing 2-3 hours extra work because the client uses IE7 and that was never part of the spec, but now you have to make it work with IE7. If you decide to charge them for the 2-3 hours of extra work, they are going to think you're nickel and dimeing them. But if you charge them $200/hr upfront, you now have a buffer, so you just take it care, and it will be like you're a wizard.

If it turns out the task was super easy, and the client is happy with the first revision, then you always have the option of reducing their bill. That is always better than increasing it.

If you work three hours and get $200 for your time, you are not making $200/hr.

Partly, my rate as a freelance developer is to cover four things that generally would be paid by an employer, but which I (personally) don't consider directly billable when free lancing:

1. Times I'm not working, the effort of finding clients, etc. A standard job ensures that I have work next week (at least, in general) and comes with much longer lead-ins to periods that I'm not working for them, so I don't have to charge (as much of) a regular employer to cover that situation.

2. Training and research. Keeping my skills up-to-date is something I've insisted from employers and just silently charge for when free lancing. Things like covering books or other training materials, sending me to conferences, etc. (In essence, you're paying my 20% time and reading materials during the hours I bill for rather than during the hours I'm 20%-ing or reading.)

3. Most employers will provide some kind of benefits, which I have to cover personally and which cost more as a freelancer. This causes not only my hourly rate to sound higher, but the employer to actually have to pay more, because generally companies get discounts on group insurance. (I'm rolling the differences in dealing with taxes in here.)

4. This one varies by person, but I don't charge for certain kinds of short communications, directly. My rule is generally that synchronous communications always cost money, and asynchronous communications with <15 min of my time invested don't. I find it's easier to just charge more on the core work hours than try to bill for the 30 ~2min emails you sent me over the course of the project.

Together, these make the free-lancing price sound higher, but actually comes out pretty close to what the cost-to-employer is, which is normally higher than the pay rate of the employee, once benefits, training, etc are factored in.

It's not about the technology. It never has been.

You're number one mission whenever you get a contract is to understand the business and figure out how you can get them making more money.

That's the secret; you should always be framing your services as an investment. Demonstrate how you're going to raise their revenues (and do it!) so that it when it comes time for contract renewal, your worth is easily demonstrable (you paid X in exchange for Y millions).

Demonstrate how you're going to raise their revenues (and do it!) so that it when it comes time for contract renewal, your worth is easily demonstrable (you paid X in exchange for Y millions).

This is a nice theory, much promoted on HN by a few high profile posters a while back.

Unfortunately, it doesn't necessarily scale well beyond a team size of 1. This may or may not be a problem, depending on the kind of work you want to do.

It's also worth noting that if you're going to play that game, you need to be much more of an all-rounder than just someone with technical skills. This will suit some people very well, but it's not for everyone.

In short, demonstrating a direct return on investment is a safe and reliable way to convince clients of your worth if you have the option, but it isn't the only way.

If your team doesn't add business value greater than the sum of its parts, it's simply not effective as a team

Would that not vary based on the goals of the business (and how they define value) and/or project?

Yes and I'm assuming the business is paying for this team - so effectiveness would be measured by whatever the business goals are at that moment. Constant steering and alignment w business is therefore crucial.

There are many ways of adding value. Some are obvious and immediately observable. Some are subtle and/or only observable over time.

There are also many ways that any organisation with more than one person contributing could collectively achieve good results, while any given individual personally made anything from a disproportionately positive to a negative contribution.

As I said, demonstrating your personal worth through a direct measurement of your contribution is not necessarily easy with team sizes greater than 1.

Many ways to add value, but no one ever argues with the bottom.

If we're discussing $200+/hr consultants, you're going to do yourself a disservice if you don't find some way of objectively measuring your contribution.

No one ever argues with increases to the bottom line, so start there.

Right, but to give one obvious example, you just ruled out a whole industry of trainers who charge a high day rate for giving courses in specialised fields. You only know what bringing those people in was worth after your newly trained team gets better results.

Even then, unless the training is in some convenient sales/marketing field where the resulting conversions are easy to quantify, you may not be able to put a dollar amount on the long term value of the knowledge and insights your people gained from the training for a long time.

As an extreme example, consider the possibility of a one-day training course for software developers taught by a world class expert for $10K. Maybe one of your developers learned a new defensive programming technique five hours into that day, and that technique later prevented a bug that would have cost your business $1M to rectify. Obviously that training had a very high return on investment, but how is the trainer supposed to demonstrate that to his next client?

Sales collateral of very highly-paid trainers should have evidence of value and a great way to do that is exactly those kind of real examples, which a highly experienced and effective trainer will have picked up over the years. Reputation is secondary evidence of value of course, though considerably weaker. Strong evidence of value is how people can be persuaded that it's a sweet deal to pay huge amounts to consultants in any field where those consultants come with a long list of similar organisations they helped.

For the rest of the training market it would come down to a client requirement for the service, general qualification to do the job, and typical market price - existing budgets and product pricing kicks in at this point rather than ROI on specific individuals or teams. We see this in the dev contract market as well and that's what the article is about - commodity resource vs stars.

tl;dr if you can't demonstrate exceptional value, you will trend towards commodity.

I disagree because with larger companies, a stakeholder's goal doesn't necessarily align with the general principle of 'making the company more money'.

Those are the jobs you want to avoid like the plague

"It's not about the technology. It never has been." exactly, best answer here.

"Demonstrate how you're going to raise their revenues (and do it!)"

Outside of really small organizations where you can have direct control of all parties, guaranteeing increased revenues (and/or profits) is pretty damn hard.

Guaranteeing lower costs, faster operations, increased efficiencies, etc., is easier to achieve, because it's largely within your scope (speaking from a software perspective).

You may not have control over any of the factors you mentioned. Some places are just paralyzed with fear and plagued with red tape.

But keep looking for the revenue lift opportunities. Even if you're kept from doing the "right thing", continue to be vocal about your position. If it has validity, eventually it's going to play out and at least you will have a "told you so" when your contract comes up for renewal.

I don't disagree, but "I told you so" doesn't always fly with most people.

Sure. Nothing is guaranteed. All you can do is be insistent on echoing the best advice possible going forward to lift revenues and attempt to remove the roadblocks towards your objectives.

Sometimes you win. Sometimes you lose. Sometimes you say "I told you so" and they say "fuck off" and you part ways.

but I would really like to get some insight on what $200+/hr web-development is like. I mean, what are the expectations versus a $50-developer?

I've done a number of projects for $200 per hour. To me, the biggest differences are:

1) Business knowledge. I work full time at an investment bank but I also do side work. I spent 350 hours per test studying for the three CFA (Chartered Financial Analyst) tests. They have nothing to do with technology obviously - they are widely considered the hardest tests in finance. The years I took the tests, I took them with multiple business people from my firm where I ended up passing and the business people ended up failing. Business knowledge is the single largest thing that will gain you respect (and a higher rate) from a company.

2) Full stack knowledge. When a client's website is down, he doesn't want to hear, "OK then. I've checked all my code and it is just fine. This is a database problem. I'll forward this to the DBAs." They want you to fix the problem no matter where it lies.

You're obviously new and sincerely inquiring, but I'll tell you - writing what you wrote here shows just how new you are. Anyone can build an app with a lot of moving parts "in 10 hours". Ya know what that's called? A prototype. It doesn't have proper error handling in it, it doesn't have proper logging, it doesn't have proper monitoring, it doesn't have proper business logic, it doesn't have proper features, etc. The 10 hour prototype you built is probably 10% of the actual project. A $200 per hour software engineer with business knowledge and full stack skills knows that.

I've seen a few $200/hr freelance guys work, and here is what I observered - they resell the same solution over and over. They have canned solutions for most existing problems.

You need a full blown add-hoc reporting system customized to your system, in two weeks? No problem! The system already exists, it's just a matter of integrating it. And then they go looking for another company that needs a reporting system. The good ones will have more than one trick up their sleeve, but it will be basically the same thing over and over. That's how it gets done so fast. It's easy to integrate OAuth2 into somebody's site when you've done it a hundred times before.

> I could probably build in 10 hours a customized, nice-looking Twitter bootstrap Rails site with Stripe integration and deploy it onto EC2 and set up Capistrano to integrate with whatever existing Github flow they have

In my 15+ year career I've not met a single person who could do this. Not even close.

I'm not doubting your abilities as a developer, just pointing out the typical oversimplification of scope and underestimation of effort that happens in software development. This is why software projects are always 'late' and 'over-budget'

The youngest piece of that site is Twitter bootstrap hails from 2010, so we're really only talking about the last 4 years of your 15+ year career.

The specific technologies that danso mentions are crucial for two reasons.

First, danso probably already has lots of experience with those pieces. Second, those aren't the buzzwords of the month, they're specific technologies that developers choose to use because they're force-multipliers.

Go back 10 years and I'd share your disbelief at the 10-hour time frame for the given task. It would take me at least 10 hours just to figure out where I can host the site! Twitter Bootstrap makes nice-looking design so easy to build, compared to 10 years ago where I'd easily burn hours trying to get the CSS to look right and it'd still end up looking like a programmer made it.

Rails could have several models generated in the same time it takes me to setup PHP to connect to the database.

Stripe's main claim to fame is that Paypal's API sucks. Go skim the Rails guide for Stripe: https://stripe.com/docs/checkout/guides/rails (Paypal's documentation has improved lately though.)

10 hours is not a lot, but leveraging current technologies makes a large portion of this task totally feasible.

OTOH, there's this quote about the underestimation of time required, popularized in 1985 which still rings true today:

"The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time." —Tom Cargill, Bell Labs

As others mentioned, this is a buffer number, it's less about technology, etc. There's already some good answers here, but another aspect of this level of price should be respect. It's easier to command a bit of respect from clients at this rate (whether it's hourly, or daily or weekly).

But the respect should flow both ways here too. Treat your client and project professionally - answer calls, answer emails, show up to meetings when you say you will, etc. It's amazing how many people don't do those sorts of things. Really. I'm forever amazed at how low the professionalism bar is in our industry.

Having a higher bill rate allows you a bit of negotiating room if you need it - easier to come down from $150/hour to, say, $125/hour if need be. It's easier to comp a meeting to someone, or not always invoice for travel time. I've got colleagues billing $40/hr, and asking "should I bill for travel time to the meeting? How about the drive back home?" The idea of getting on a plane and flying to a client meeting, and getting a hotel, on their own dime, is outside their experience. If you're charing $150/hr, it's not unreasonable thing to do, ime. Even if you get reimbursed later, you've got cushion to float that for a few weeks - you're not living check to check.

IMO, the $200/hr dev is far more adept at servicing the non-technical aspects of the project - professionalism, people skills, project management, setting expectations, etc - or they hire people who are (agents, like in this article).

I don't think the $200/hr developers are building greenfield apps with simple models, but building quite complex logic or dealing with extending the functionality or fixing very large and brittle apps. At least, that's where I'd spend my $200/hr.

It gets easier to envision if you think less of "apps" and more like "systems which will exist within an existing business which already has many, many millions of dollars flowing through it." If the new/improved system significantly increases how many millions flow through the business, then that is the only thing that needs to be said, right? After that it's just administrivia what sort of charging model gets worked out.

If you're an insurance company and you need a computer system to support adding a new line of business to your products available, there are very specialized programmers who can help you do that. (Or you can hire Accenture and, for a 150% premium, you won't need to know that any programmers were harmed in the making of your system.)

There are virtually infinite examples of this.

Two reasons:

1. The average developer is bad. Really bad. You can easily work 4 times as fast and produce code that's much shorter and more maintainable.

2. The $200/hr developer gets paid according to the value he provides. It's not hard to provide that value if you work on the right stuff, even for an average developer. Remember that Apple has $460000 in profits per employee per year (and that includes all employees), which already translates into $200+/hr. When you provide a service that costs $200 but makes the company $1000, they'll happily accept that. If you frame it without that reference $1000 then you just sound like a very expensive code monkey.

An excellent question - and one that depends heavily on quality of management and perceived value.

Perceived value is the most common - no-one gets promoted on their past performance only on their expected performance. And so the difference between 50/hr and 200/hr is

Please note that 200/hr is not 10x 50/hr. Either we are comparing top coders to minimum wage coders - of which I suspect there are few if any (in each "locale" not globally) or we are actually capping top coders - this is very likely the explanation - to get to 500/hr or 5000/day or ~1million/year you need to be looking at equity level compensation. And that's a different issue.

Anyway where was I ? Yeah perceived value - this can always go up - but at a certain point you are no longer discussing per hour rates but project total rates and soon after the value becomes equity (I guess at around 1% o total perceived value)

And the time to have that conversation between hourly rate, project and equity? That depends on the cluefulness of management

I will suggest that climbing that compensation ladder from hourly rate to weekly rate to project rate to equity is a focus on understandin business problems, and how tech can solve them, understanding team and coordination problems and selling the business solution.

You're thinking about it incorrectly. Here's what the $200/hr developer does:

Identifies business challenges and offers a custom-tailored solution that will generate more money than it costs. Then that said developer will effectively pitch their prospective customer from that angle.

A business, if convinced you're correct and capable, will be happy to pay $500,000 to a developer who will develop software that will make them or save them $1,000,000 in the next year.

I'd read a few articles Brennan Dunn has written:

http://doubleyourfreelancing.com/get-started/

A lot of it is tied into what business value that solution will bring the business. i.e. They have an issue/fix that would make them an extra $200k per year, they would pay $50k for it regardless of whether it takes you two days or two months.

Thanks for this. Looks like gold.

Take a look at 'Double Your Freelancing Rate': http://doubleyourfreelancing.com/get-started/

TL;DR: don't focus on the technology you are using, focus on the business problem you are solving.

Reply on news.ycombinator.com