You are paid to know things and to find out how to learn things you do not know. You have to stay in constant training and re-learning. You are an expert in your field. Something you learned two or three years ago? You have to forget that and learn some other thing.

You have to own hardware and software. You have to buy health insurance. You have to save for a rainy day. You have to save for retirement. You want to go out to eat like normal people. You want to buy a house. You have to do billing. Not every client will pay. You have to hire an accountant. You have to pay taxes. You need to file papers with the county and form an LLC.

Are you going to work 8 hours a day 5 days a week? No, you will probably "work" 12 hours a day 7 days a week. Someone calls with work? Are you available? You have to get paid for being available.

Still think $40 an hour?

A few things I have learned (solo since about 1996 but spent the recession years 2007-2011 in a corporate job):

You are not a freelancer. Banish the word from your vocabulary. You are X. X being whatever it is you do/are. You are a company. You are a professional. That's just the work part. You are also a salesperson, a bookkeeper, a marketer, etc.

You will need some steady clients. Clients that call enough during the year(s) to provide some stability. You can't hustle for every single job. Relationships matter. How much stability you need, I can't say, but, ideally, you already have a jump-off client or two already.

You will have to do the numbers on your rate, but, I promise you, it is more than you think and more than you may be comfortable asking for, initially. Remember, your rate covers your availability, your expertise, your equipment, insurance, retirement, etc. If your salary is $75,000 that is not close to how much it really cost to put you in an office, with a computer, health insurance, matching 401k, etc. A company that hires the solo you is also paying for the flexibility to release you back to the wild at the end of a project without having had to hire you or fire you.

Value your time, your skills and yourself. You are a professional.

http://jacquesmattheij.com/the-army-of-the-new-independents

Best of luck!

As a freelancer , after making 1/4 of what I can make as Full-time developer I am going back to the full-time Job.

If they complain that you're very expensive - that's also reasonable; if they wouldn't be complaining then that would be serious evidence that you're not charging as much as you can/should.

The pricing logic is simple - customers don't buy = too much; customers don't complain = too little; customers buy but complain about price = price is just right. This is the same across industries, no matter if you're selling IT services, potatoes, cars or haircuts.

I agree in charging as much as you want if you can solve a problem noone else can. In ~2002 a company had serious database issues with reporting queries running for over 24 hours. So they hired 2 people who charged 600 pounds each an hour. They both worked on the problem for 2 days and brought down the execution time to 3 minutes. In that case yeah, I think they can charge as much as they want.

Don't get me wrong, I'm a developer as well and I know the difference between a 40/h and a 80/h developer. But I believe an hourly rate must depend on how long you'll be working on that project, what you'll be doing as well and how critical it is.

The other thing to keep in mind is that software developers, especially mobile and web, are making easy money. Naturally this is attracting a lot more people to the field, which by simple supply/demand economics will cause average compensation to decline. Clients will compare your hourly rate to these "averages" and question why you are so expensive. If you bid projects based on an understanding of the value the client perceives in the project, the client will feel more comfortable with what they are paying and also be unable to directly compare it to anything other than competitive bids for that specific project.

(2) you are lucky because (1) you were born in the right place (2) at the right time (3) have good marketable skills

One day about a decade ago I fell through the cracks in all the systems in spite of having paid for healthcare my whole life long and never using it up to that point, my gall bladder gave out and I paid for the operation out of pocket. No big issue for me. But I do realize that what was 'no big issue for me' would have been a huge issue for lots of people around me.

As for the insurance system: I prefer the system the way it was here before, where all healthcare is simply paid out of taxes rather than through commercial compulsory insurance. Though the tax based system has some inefficiencies it is definitely preferable because there are less opportunities for companies to enrich themselves at the expense of the service level in public healthcare. The differences between then and now are remarkable, people go without treatment for months to push the deductible to the next year and then end up with far worse issues than they had before.

On the whole, about 10 steps back.

Anyway, I hope you live a long, happy and healthy life.

Here's a more thorough explanation.

https://alecstapp.wordpress.com/2013/06/13/should-bill-gates...

Never in my life has it been worth it, and I'm outraged to know it is sometimes required by law (you can be fined, by a cop, if you car isn't insured for example).

If you don't want to pay car insurance, in some states in the U.S. you have the option of putting up a bond as proof that you can pay for the damages if you hit someone else's car. The GP is giving a big double birdie to his responsibilities. He says he does freelance work precisely to tell the world to fuck off. So I seriously doubt he is pro-actively arranging to protect other people from his lack of responsibility. He is exactly the kind of person the insurance industry and laws requiring car insurance exist to protect you from.

Last, I gave up my car several years ago and gave up my driver's license nearly three years ago. If you find car insurance so objectionable, you absolutely can opt out. No one is going to force you to own a car at gunpoint or drive. If you are so committed to saying "fuck you" to insurance, you are more than welcome to do as I do and arrange your life such that you can mostly walk everywhere (or bike or take public transit). And if you aren't willing to do that, then I have zero sympathy for your complaints in this regard. Car insurance is completely optional because no one is required to own a car.

And rightly so. Or are you able to pay out-of-pocket for any car or truck with cargo that gets totaled because you cause an accident? What about damage to individuals causing them to spend a life bedridden or in a wheelchair?

Or are you 100% sure that you will never ever cause an accident?

I'm pretty sure that of all the people that will have car accidents today in France quite a few of them got up in the morning thinking exactly like you and the majority of those (assuming they survived) will have a change of heart by 12 O'clock tonight.

Just another example of the short-sighted mentality of the supporters of more laws and enforcement.

I'm still +12, so I have a bit more "karma" to burn before I create another account. Thanks for the fun guys.

... and as a reflection, take your tongue-in-cheek-"I hope you stay healthy"-shit and shove it. Everyone dies you ignoramus.

Under-pricing my work cost me a lot during my freelancing days, so I'll comment on that directly here.

The best advice I got was from my uncle who worked in the tech industry in the 80's, which is to take your normal hourly rate and multiply it by 3. Or, take what you would be making full time, pro-rate it, and do the same.

This might sound high, but the easiest way to think about it is as follows:

- The first 1x is for your normal salary, as if you had a full time job. You are producing a product, or your time costs money, and this is the price.

- The second 2x is for "backoffice" or "cost of doing business" expenses. This is everything from accountants to lawyers, gasoline for trips, software licenses, hardware costs, office rent, etc. This stuff adds up and you should remember to account for it.

- The third 3x is for profit. You're running a business, you're shouldering risk, and should profit from that risk. Also more practically, there will be boom times and bust times, and you need to weather the bust times with float.

All of the above is to say: If you are negotiating a price, especially if you are not used to negotiating prices, think of the highest price you can say with a straight face. It's often more right than you think.

As a final note, having been in a position of hiring freelancers in the past, don't forget that the value you put on money it often completely different than the client who hires you. For you, that money is your dinner. For a company, your cost is nothing if it gets them another advantage, such as a key BD contract or a stronger foothold in a 20m market. I believe the negotiating term is "trading things of unequal value".

In practice it's simple - if you're paid to build a thing for someone, that someone owns the thing. It's known as a "work for hire". That's what your customer will expect, anyway. I mean, would you pay someone to build a thing for you and think didn't own the copyright on the thing?

how can I make it so the contract would hold up in a court, if, for example, they refused me payment?

You know what's better than a contract? Getting paid in advance. Whether it's 10%, 30%, 50% or 100%. You should work your ass off for your customers. But if they haven't paid you, they aren't really a customer, are they?

If you didn't get any upfront payment, ask for something once you have any deliverable to show. Show proof of work and a reasonable client should be willing to send money your way. Worried about getting paid? Establish that they will pay as soon as possible.

Also, a contract that holds up in court and results in a judgement in your favor is no guarantee of payment. A judgement means you can send a debt to collections. But the collections agency will extract a hefty fee and it may take months or years to collect.

It seems like you're focusing on what can go wrong. Ignore that stuff. Focus on building trust and rapport with your clients.

How should I value my time?

Is my time worth $20 an hour? $40? Less? More?

Abandon the concept of time. Think instead of services. What services are you providing? What are these services worth to your customer? Approach this from their point of view, find out what they're willing to pay, not the minimum you're willing to charge.

Start out high. Charge a rate that seems too high. If the customer says "no" find out why. It may not be the price, but some other concern. If the price is too high tell them you're open to negotiate, ask for them for a counter-offer.

I don't think that this is true, at least in the US; the default is not work-for-hire, the default is that creators own works. While it is possible that I'm mistaken, I'd imagine that it is jus the case that you're generally working in situations where it isn't an issue (for instance, you don't want to reuse the code, the folks you're working with don't specifically care, or something).

Otherwise, I agree with you.

This is generally not true in US copyright law. In US copyright law, a "work made for hire" is either made by an employee in the scope of employment, or is one of certain classes of commissioned for one of several specific purposes enumerated in the law where there is a written agreement signed by both parties specifically designating it as a work made for hire. If it is not done by an employee in the scope of employment, then if it is not also commissioned for one of the purposes explicitly described in the law or, even if it is, if there is not a written agreement designating it as a work made for hire, then its not a work made for hire.

Note that the purposes enumerated in the law include commissions:

* as a contribution to a collective work

* as a part of a motion picture or other audiovisual work

* as a translation

* as a supplementary work

* as a compilation

* as an instructional text

* as a test

* as answer material for a test

* as an atlas

...and that's it. Most specially commissioned software won't fit into one of those categories, so even with an explicit written agreement purporting to designate a work as one made for hire, it still won't actually be a work made for hire for copyright purposes, and the copyright will rest with the creator. see 17 USC Secs. 101, 201.

> That's what your customer will expect, anyway.

If your customers expect that, they will generally be wrong.

> I mean, would you pay someone to build a thing for you and think didn't own the copyright on the thing?

To the extent that someone commissioning a work that is not in the categories that can be a work for hire in US law wants to own the copyright of a work created in the US, they should seek to recieve a signed transfer of copyright, otherwise they will be disappointed. see 17 USC Sec. 204.

The reason this works well is because it benefits everyone. It benefits you because you know what you are going to make, you don't have to worry about the client saying "oh can we make this one change it will just be an extra hour right?".

They benefit because they know the cost upfront and don't have to worry about overruns, and they know exactly what they are getting from the detailed spec that is required to make this work.

(1) read the spec for a job that you're going to do on an hourly rate basis

(2) make a very detailed layout of how long you think you will spend implementing each part of the spec

(3) total it all up, write down the number and multiply by two, then multiply by your hourly rate

(4) write down the resulting number as what you could have quoted your customer with a huge safety margin of 50%.

(5) next, proceed to do the job as you planned, hourly rate

(6) keep track of your time (you need to do that anyway, but do it in a bit more detail, what part of the spec took how long)

(7) add that all up, multiply by your hourly rate, compare with the number you got in step (4).

If you end up 20% below or further than the number you got in step (4) you are more or less ready to try (small!) fixed price jobs.

Keep in mind that it only takes one big fixed price job to sink your reputation or to totally eat up the profits of many otherwise successful jobs. It took me a really long time to get good at this.

Do you mean sink your reputation because you underbid and then can't afford to finish the project, or something to that effect?

And that can get very ugly, especially if you cause bad things to happen to your customer.

In all other cases, your position is that you're a specialist hired by the hour, at a (significant!) premium to allow for the fact that you can be dismissed without cause at moment's notice, and any estimates are best guesses, given the information available at the time.

Also, keep a private file of any and all diversions from the basis on which you gave any estimate. They are bound to exist (pretty much from day one) and except for the very most trivial projects, your estimate WILL be wrong.

Optimism comes easy to our trade. Learn to embrace pessimism, plan for the worst, expect the worst and then pray that your plans weren't too optimistic. "This time it's different"? When pigs fly.

Good luck!

This is the case for most employees also. At least it's always been my experience. Only if you have a contract with a guaranteed term and specific early-termination conditions can you assume that you won't go in to work tomorrow and get fired.

I mostly agree, but just want to point out that cost overruns aren't a function of charging an hourly rate. Overruns are the result of poor estimates of the time/resources required, or a soft or changing spec. Having a good initial spec is a must. But if the spec changes, and results in extra work, the per-job price should also change.

Per-job pricing really shines in areas of high competence. When productivity is high, instead of charging based on the rate of production (dollars per hour), charge based on the business value of the final product. Assume widget X is worth $1000 to the customer. From their perspective it doesn't really matter if it takes 1 hour (high productivity) or 100 hours (low productivity) to complete - the received value is the same. A high performer who charges for just the hour is leaving money on the table.

The reason this works well is because it benefits everyone. It benefits you because you know what you are going to make, you don't have to worry about the client saying "oh can we make this one change it will just be an extra hour right?".

Even for per-job pricing don't be afraid to ask for further compensation if the scope expands. Otherwise you're leaving money on the table. If the original spec is for X and it expands to X + Y, don't do Y for free. Few businesses will give away a non-trivial Y just because a customer purchased an X. Freelancers should be no different.

Repeat business doesn't require some arbitrarily long length of time to pass in order to qualify as "repeat business". If a client comes back on the same project with new ideas and features, that's an expansion of scope, and an instance of repeat business.

Copyright - Maybe a lawyer can speak to this issue, but my understanding is that you own the copyright to any work you produce until you indicate otherwise. In the context of freelancing, that means that you should have a clause in your contracts that gives your client the copyright to the work once you're paid in full. No explicit transfer needs to be made and nothing needs to be filed (unlike trademarks and patents).

Value of time - You should value your time according to the value you can produce and what you will be happy with. This is tricky, and others have written a lot about this (and have said it better than I could) so search Google for "hn increase freelance rates" and you'll get enough material to keep you busy for a while. Just one warning to add: Don't undervalue yourself! It'll kill your motivation and put you in a vicious cycle of unproductivity. Chances are the lessons you learn here will be learned the hard way (speaking from experience).

Contract - Rather than thinking of this as a legally binding document, you should think of it as an outline of the process you're about to enter into with your client. Use it beforehand to make sure you're on the same page about your relationship, rather than afterwards to try to protect your ass. How/how much/when will you be paid? What are you expect to deliver, and when? How are you going to handle disagreements or unforeseen problems with your client? How much availability should the client expect of you, and vice versa (just as important!). The answer to all of these questions should minimize the risks to both parties and set you up for success. (https://news.ycombinator.com/item?id=8976924 is on the front page as I write this and should get you started).

I could write about this for days, but I'll stop there for now :). If you have any other questions though I'd be glad to answer as well as I can.

There are also non-development skills that you will need. You will need to gather requirements, possibly even produce wireframes. You'll need to be organised around tasks and deadlines. I suggest using a task-tracking tool that both you and the client have access to. Your clients may need design. If you're not capable of doing this yourself, you'll need to find them someone who is, or at a minimum give them a set of options of pre-built themes from a paid theme site, which you're skilled enough to adapt to their requirements.

Also don't forget that you'll be deploying their site to the hosting, which you may need to purchase and/or set up. I would also recommend a staging environment (even if it's on the same server as live) for testing and previewing changes and new features to the client before they are pushed to live.

Development sometimes ends up being less than half of the time you spend on the project. When you're a freelancer, there is no one else to do those tasks but you! It's all valuable experience though, even if you take a corporate dev job later in life, it will give you insight into the business decisions that get made around your "strictly development" tasks.

Really, however you and the folks you work with want to structure your work is how it is. There are things that are worse for you and things that are better for you, but it's a question of what you and your clients what more than anything.

As to the stability of contracts, they are only as good as the person signing them; generally if someone has given you money as a deposit, then there isn't a question about if the signature is binding, but rather what different parts of the contract might mean... the meaning of "functions in most browsers" or "has an easy to use method for adding XYZ" is really where you should be sweating.

That's typically the issue: usually the people I work with want things to be working well and done correctly, on a predictable schedule. Delaying delivery until payment is made is one strategy. A better strategy is to work with people and businesses you can trust... if you have a contract and there is no question about the quality of the work, generally enforcing a contract isn't something that requires lawyers.

The facts about negotiation apply to your rate: if your client will pay you $500/hr, then that is what your time is worth. Instead of worrying about what it is worth, worry about what you have to make in order to do the things you need to do (or, if you prefer, what your rate needs to be so you don't have to go get a job).

Generally, clients (end users, not, for instance, agencies) don't like hourly pricing for the same reason that I like it: it transfers the liability for additional changes or unforeseen troubles with the agreement.

So you might find that you're better off with fixed pricing, which involves knowing what your hourly rate needs to be and how many hours you expect will take to do the work, plus the cost of acquiring the client, plus a hedge for unforeseen work that will need to be done without issuing a change order. Multiply that time three, and then you'll probably not get too screwed by a contract :D

If you are concerned with the complexity, start out using a platform like oDesk which will take care of much of the payment and legal risk. Be sure to bill hourly not fixed amount.

I've written and signed many contracts, but ultimately for casual contracting it's most important to just find people you trust to work for/with.

Adding to this, try not to reinvent the wheel. If you're trying to code something which is already there and open-sourced, go for it; include it in the project and work on it.

Ask for 1/2 of the fixed amount / working hours upfront. This will ensure that your client is actually interested and won't easily dump the project.

Smaller companies may have less savvy owners/managers who don't have an understanding of what you're doing, leading to scope creep (why can you "just" change this?) and miscommunication in time, quality (etc) expectations.

Set expectations clearly, especially ones that seem painful to bring up (especially time, budget constraints).

It actually may be more accurate to look at total comp: $50k a year + $12k in health benefits + $3k in equip + $4k in vacation + $1k in retirement benefits ~= $70/hr.

https://news.ycombinator.com/item?id=7850335

A per-day rate equivalent to $100..200 per hour is the cheap side of things. Don't cut yourself too short. Businesses have deeper pockets than most individuals.

Contract: The most important points in the contract are naming stepstones, milestones, budget, payment at each milestone, payment terms. An agreement is only good, as long as you agree. It often becomes toilet paper if disputed, especially as lawsuits might be more expensive then the value of the contract, and as contracts are difficult to enforce over international borders for a freelancer. So there is no need to pay a lawyer to create a legal bullet proof contract, as you can not enforce it anyway. Better write one that a human understand. Thats not more complicated then selling your car. One of my "tricks" is to offer 2% discount, if payment is within 7 days after invoice. Any customer who can count money, and has no big cashflow problem will pay instant. Drop those who are late payers. They are often problem customers in other terms also.

Time vs money, 1st: The curse of any coder are infinite ideas vs. limited lifetime to execute them. Applying the law of diminishing returns on this, and new ideas receive a negative value. The same sooner or later shadows over the value of money, as people start to throw more money at you to solve their problems, then you ever need.

Time vs money, 2nd: I advise against selling time for money at all. Time for money does not scale, as you have only a limited lifetime, but there is unlimited money around. Selling time for money is typical for employed workers, but a professional should sell solutions for money.

Picking customers: Often customers pick you. You are lucky, you got your first client. Do a good job, and he will tell others. At first you will likely take any job that comes. But take care, that there are problem customers, who will leach your time, never pay the full amount, and claim they want more work for the money you agreed. Drop them, to concentrate on good customers.

Pick the good customers and convince them to sign a maintenance contract. I'm old and saturated now, have a semi passive income from maintenance contracts, and I'm dropping more then 80% of potential customers, often just because of a gut feeling during the first talks, before signing any paper. Signing a NDA is often the end of the talk, as ideas have a negative value for me.

Build a portfolio of skills where you are better then the average, as you already know the tools or the topic. You can offer fixed prices once you have this tools, skills, and knowledge. Fixed prices to solve problem will make much more money then selling time for money, as the value of the problem is much higher then the value of a contractor. There are basically two types of problems: Problems where you reduce the running cost of something, and problems where you increase sales. Estimate how much a solution is worth within a year, and ask for a good fraction of this for the prototype, and a smaller fraction for the maintenance contract.

Create a nice pile of things that have a good value for the customer, and either are easy to automate (like hosting), or likely don't eat to many hours. You'll lose the ability to invoice your customer for the 10 minutes mail or phone help, but you would need more then 10 minutes for book keeping and invoicing of those small things. So better sum them up, if you want to keep contact to a good customer. As funny as it sounds. The annual maintenance invoice was often the starting point for a custom asking me to solve a total different problem.