Slashdot Log In
Freelance Web Developer Best Practices?
Posted by
kdawson
on Sun Dec 07, 2008 04:54 PM
from the like-a-pro dept.
from the like-a-pro dept.
SirLurksAlot writes "My last employer had to make a series of budget cuts, and I was laid off. I have been on the job hunt since then; however in the meantime I have begun freelancing as a Web developer. This is my first time in this role and so I would like the ask the Slashdot community: are there any best practices for freelance developers? What kind of process should I use when dealing with clients? Should I bill by the hour or provide a fixed quote on a per-project basis? What kind of assurances should I get from the client before I begin work? What is the best way to create accurate time estimates? I'm also wondering if there are any good open source tools for freelancers, such as for time-tracking and invoice creation (aside from simply using a spreadsheet). Any suggestions or insights would be welcome."
Related Stories
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Contracts! (Score:5, Insightful)
First of all be sure you get signed contracts, or you will be stiffed more then you get paid.
Plenty of OSS timekeeping apps out there. Check out SQL-Ledger for a complete solution with accounting.
Re:Contracts! (Score:5, Insightful)
Same note, different angle, make sure what you are getting paid for is something you can do not only ability, but time-wise.
Talented novice freelancers are often oversold freelancers, which leads to unhappy customers.
Parent
Contracts are premature (Score:5, Insightful)
Contracts? From reading the article, contracts are really premature. The person asking the question is too vague about too many things. They should have at least gone into some detail about their skills, experience, and target market. "I want to freelance as a web developer" sounds more like an act of desperation than a person with a plan.
Just some of the basics that are missing:
If, after looking at this list, you see you don't have the resources to pull it off, maybe it's because succeeding in business is more than just "doing a job." Perhaps it's because now is just not the right time for you. Perha
Parent
Re:Contracts are premature (Score:5, Insightful)
Seriously? Freelancing IS being in business. The government treats it as such. So do clients. It's not like they're looking for work mowing lawns or painting porches, something that's easily measured, easily priced, and easily evaluated as to "what has to be done." If you're thinking of just making a couple of grand to "tide you over" till your next "real" job, why not just mow lawns, shovel sidewalks, or paint porches? It's honest work, and there's a lot less hassle involved.
Someone laid off, looking to freelance, doesn't know how long it will be before they get another full-time job, so that freelance work *becomes* their full-time job. It needs to bring in enough money, on a consistent basis, to live on, which, if you're not living in your mothers' basement, means running it like a business.
If you're going to deal with businesses as a supplier, you might as well do so in a professional manner. The way the economy is going, by this time next year it might spell the difference between living comfortably and living in a cardboard box.
Parent
Re:Contracts! (Score:5, Informative)
I have to disagree. I do a fair bit of freelance stuff on the side and I have never (not once) had trouble getting paid. At first I was very cautious but it just has not been an issue. Even on jobs where I'm basically dealing with an email address in another country the check has always cleared.
I terms of contracts don't waste your time. A contract is only worth anything if you can enforce it. Are you really going to spend thousands in legal fees going after a few thousand in wages. Just make sure they pay you as milestones are delivered and don't worry too much.
Parent
Re:Contracts! (Score:5, Informative)
I second this. As someone that had trouble getting paid when I started out, I have to acknowledge it was my own fault for doing work for either friends, or friends of friends that were just starting out. Or sometimes taking a chance on a shady character or bad referral. Unless you want to spend a lot of time and money in court, signed contracts won't help you.
In addition signed contracts will scare off more legitimate customers and cost you more time than they are worth. Just make sure you are dealing with a company that is a viable business, write a good bid/estimate, use common sense and MOST IMPORTANTLY require a fractional payment up front (1/3 for large jobs and 1/2 for small jobs.).
Also, to elaborate on your question about fixed bids versus hourly rates, the answer is both. Most clients are going to want an estimate and you are going to be stuck to something near that number after you pull it out of your ass. So keep track of your hours so you can make better estimates in the future. And make sure both you and your client understand expectations and deliverables so you can increase the dollar amount *WHEN* your client starts moving the goal posts. You'll also want an hourly rate for any down-the-road maintenance or ancillary services you might provide. After a few years in business 80% of my income comes from 4 clients that provide me with a steady stream of work, billed at an hourly rate. Those clients started off as fixed bid projects that grew and grew until I was an important enough part of their business that they had to keep me around. And I don't know about you, but I would rather have a steady stream of work from known clients I trust than be making cold calls or spending money advertising to find new work. Which reminds me, the other 20% of my work comes from referrals from those 4 clients.
First rule of freelancing:
When you find good paying clients, treat them like gold and they will return the favor.
Good Luck!
Parent
Re:Contracts! (Score:5, Insightful)
I agree to a large extent but it depends a lot on the client. I say this as a fulltime independent web developer.
I once spent a month in negotiations with a client over a contract, until finally I walked away. The only thing that would have been acceptable to them was essentially a non-binding resolution governed by the state of Utah, their corporate home, suffice it to say I am not in Utah and it would have made even an effective contract impossible for me to enforce because I don't have the time or money to fly somewhere to fight over payment for one gig. A few months later I heard that they had stiffed the person they eventually found to do the job, and now more than a year later they still haven't made any progress but have lost the benefit of any referrals.
Point is, a contract wouldn't have saved me there, and it certainly burned some goodwill with the client. But it also showed me what kind of people they were, and the struggle ended up steering me away from a bad situation.
In general I agree with everything else said. Keep very detailed accounts of your hours and how you use them. Treat your good clients like gold - and I mean that. Send them Christmas cards, with handwritten notes - nothing sappy or long, but let them know you're a human being and you appreciate their faith in your work. If you love them, they will love you back. Always get money up front (this depends on the client and the project, but it's generally within 25%-40% for me).
I have made a gut call and not even mentioned a contract with a few clients. Just remember that to a stand-up client who intends to pay you money for the work you do, a contract shouldn't be a scary thing. If it is, that means you're presenting it wrong, it's written poorly, or something about them isn't aboveboard. Maybe they're just trying to keep the government out of their accounting, or maybe they want to be able to walk halfway through if they get a change of heart without having to pay anything. Whatever it is, it's important you find out before it hurts you.
Ideally, I have 2-3 major projects going at once and a handful of smaller ones with less demanding timelines, and almost all of my business comes from a fairly small circle (20 people or so) who pass around referrals. I think maybe the biggest thing I haven't seen mentioned is that us independent web developers and designers and coders and whatever are not competitors - even in bad economic times there's plenty of work out there for us, if anything it's the expensive agencies that will lose contracts to flexible independents. Cherish your network of trusted associates, it's through them that you build a reputation and grow your business. And the next time you've been offered some work that doesn't fit into your schedule, pay it forward and refer someone else.
With good clients and bad, the most important thing is getting a feel for them as people. Show respect, get respect. Do a good job, get paid for it. Pretty simple, really.
Parent
Re:Contracts! (Score:5, Insightful)
In addition signed contracts will scare off more legitimate customers and cost you more time than they are worth. Just make sure you are dealing with a company that is a viable business, write a good bid/estimate, use common sense and MOST IMPORTANTLY require a fractional payment up front (1/3 for large jobs and 1/2 for small jobs.).
While I agree with all of the rest of your excellent advice, I differ here. A simple contract, that clearly spells out the deliverable, due dates, etc., helps both sides understand what is being done for what cost. As the work progress, you talk with the client to ensure they are getting what they expect and to keep the project on track. That way, there are no surprises and both sides are happy. I've never had a client balk at signing a contract; in fact most want one and get nervous about starting work without one. Be professional about it and clearly lay out what is to be done when, for what cost, and what support you get from the client and I suspect you'll have no trouble. Once you have a solid relationship you can work on spec but until then a contract helps both sides.
Parent
Get a lawyer (Score:5, Informative)
Write up a standard contract. Make sure it defines what you will and won't do. Make sure that if anything is requested beyond what is listed the contract must be renegotiated including pricing. Making sure you are indemnified and held blameless. CYA.
Learn CSS (Score:4, Insightful)
For the love of god, do NOT make your websites using any of these:
- tables (for layout, I mean)
- Flash
- Java
Also, learn to code for Opera/Safari/Firefox first, then add conditional CSS for IE6 and IE7.
Take time to learn the real-life differences between JPEG and PNG. You shouldn't have a photo in PNG anymore than a logo should be in JPEG.
And last, know the limits of bandwidth and clients. Not everyone uses a high-speed cable connection on a Quad-core computer.
posted anon because of the freakin' Adobe Flash fanboys.
Re:Learn CSS (Score:5, Insightful)
For the love of god, do NOT make your websites using any of these:
- tables (for layout, I mean)
1) using tables for actual tables of course is perfectly ok (as you implied by saying 'for layout'
2) I would suggest "avoid" using tables for layout as much as possible, but don't discount them.
When faced with a situation where a table will just work in every browser you intend to support with minimal table html markup, and doing it with CSS requires divs nested in divs nested in divs nested in divs with all sorts of css hacks, and then STILL needs a javascript to run after the page renders to fix the widths and heights etc...
Yet its trivial to do with a table, without any javascript or browser hacks.
I just use a table.
Pure CSS is gold. But in my opinion browser hacks and javascript for layout are WORSE than tables. If you need them to avoid tables and make your "pure CSS" work, the cure is worse than the disease. (and really its not "pure CSS" anymore if you are using hacks and javascript)
As for flash and java. I again agree to a point. For most sites you absolutely don't want to make them essential for your site to operate, but there is nothing wrong with using either appropriately. And depending on what the site is, it might be appropriate to make them essential. homestarrunner.com without flash would be pretty pointless.
Parent
Re:Learn CSS (Score:5, Informative)
Usually tables are a hindrance for me. I think in terms of divs now. And its always a pleasure to code. I didn't get that when I used tables, really.
Contrast tables with radical layout changes that can be made with small CSS bits. CSS was a pain before IE6, and IE6 still has issues, but for the most part CSS is an absolute joy to use now.
Cached CSS means your HTML files are all about content. It means less bandwidth use, and cleaner code.
Theres loads of reasons I like CSS, and not many for liking tables. My $0.02
Parent
Re:Learn CSS (Score:5, Informative)
Pick one from here [blog.html.it].
Parent
Re:Learn CSS (Score:5, Insightful)
Parent
Re:Learn jQuery - Good grief... (Score:5, Insightful)
What a load of rubbish - have you ever seen just how slow Ruby sites run with any sort of significant load? Python too. PHP isn't the silver bullet or anything, but saying Ruby/python is "better" is just playing to the fanboy crowd.
Yes, I have used all 3 in commercial projects - have you?
And as for the idiots saying "don't use a table, you can make divs behave exactly like table cells, except not in IE6" - where to start... If you're having to code up 20k of CSS and AT LEAST the same amount of markup (probably a lot more) to emulate something that already works, and works realiably, then you're an idiot. The visitors don't care, your client won't care, Google doesn't care (really! go check it out) and you won't earn any more out of it. Saying "ah, but I can tweak it easier" is more junk - how many sites do you actually "tweak" after it matches the visuals? Virtually none. A redesign usually requires different content and completely different layout.
Don't even get me started on making the site work across mobile and email shots (yeah, you're going to be using tables, or lots of images and nothing else)
Tables have their place in the real world. Stop being elitist about it.
Parent
Just some answers (Score:4, Insightful)
1. Maximize what you get from the client. Do hourly or fixed-quote, whichever is most appropriate. If you have the luxury of choosing only high-paying clients, well, nice to meetcha, Santa. How's the skiing in Hell?
2. Half up front. No exceptions.
3. Years of experience.
Always bill for time & materials (Score:5, Informative)
Quoting a fixed price for projects is like putting a "kick me" sign on your back. You'll attract cheapskate clients who will chisel you.
Use a standard contract that indemnifies you and covers your ass as much as possible. Always create a statement of work for each engagement and create a new revision that gets signed off for each material change.
Re:Always quote a fixed price (Score:5, Informative)
T&M is the best situation for the vendor to be in. It is the worst situation for the client to be in. A bid job puts pressure on the vendor. The threat of T&M forces the client to lock down their decisions.
This goes for just about any contract job. not just IT or webdev.
Parent
Good estimates (Score:5, Funny)
First, take your best estimate, then multiply it by two, and then increase the units to the next largest. So, if you estimate something will take 3 hours, tell the client it'll take 6 days.
Mint money with maintenance (Score:5, Insightful)
I carefull define what constitutes a "minor" update--basically, anything that doesn't involve a complete site redesign or a lot of graphics work is covered.
Here's the beauty of it: about half my customers go for maintenance and in the 4 years I've been doing websites on the side, I've gotten 12 customers that have maintenance contracts. I haven't done one update under maintenance. I just sit there, quietly collecting $25/month for doing absolutely nothing. And, even if I do have to do something, so long as it's not alot of graphics work, it only takes me a half hour or so anyway.
Also, as others have said, get a deposit before you start work on a site. I do sites on a flat-rate basis, and require 50% up front. Otherwise, you can spend a lot of time working on a site for someone and never get paid.
Also, remember that you will make as much money on hosting in general as you will on design--get a reseller account with a good hosting provider (I use hostgator, but if I had to do it again I'd probably get a dedicated server because hostgator's rails support sucks.) I suggest using paypal subscriptions to make sure you automatically get paid for hosting. They're cheap and easy to setup, and it all happens automatically.
What I'm doing (Score:5, Informative)
I figured out an hourly rate based on my skills and the prevailing rates. When someone wants me to do something, I get a clear statement of what the work entails. I give an hourly estimate in the form of a range (e.g., 20-25 hours), and tell the client that the top of the range is a cap--after that, I turn off the clock and finish the job, and count the 'lost' hours as an expensive education in estimating (clients quite like that there's a ceiling on their costs and that I'm apparently willing to take a hit for doing things badly).
Then, when I'm estimating, I make sure that I understand the requirements clearly enough that I (almost certainly) won't ever hit that cap. I'm generous in my estimated hours, and if possible, come in at or below that floor of my estimate, which also impresses clients. I'm very upfront about the time taken being a range to handle unexpected difficulties.
For larger jobs that I quote, I break it up into estimable pieces, and call them milestones.
For jobs under five hundred dollars, I do the work and bill. For jobs over five hundred, I get half up front and half on delivery. For large jobs with milestones, the half up front, half on delivery is for each milestone. Milestones are structured with a clear deliverable so that the client feels like, if they stop at that point, they've got a recognizable thing for which they paid.
So far it's worked pretty well for me. The most important part has been long discussions beforehand so that a clear statement of requirements is agreed to before work starts. Then, if the client says they want something different, I've got clear grounds for either revising my estimate or calling it 'out of scope' work with a separate estimate/bill.
My experiances (Score:5, Informative)
I started freelance web development more than 10 years ago. I built my company on my freelance work. So I can speak with some authority here.
Here's my advice in bite-size nuggets:
- Only bill time and materials. Do not ever agree to do fixed fee work or you will loose your shirt.
- Incorporate. It's actually easy and gives you more protections.
- When tax time comes around have a CPA do your taxes.
- Find a basic, easy to read, even handed/fair contracting agreement that you should always try to use. Have it reviewed by a lawyer. Include these points: mutual indemnification, your *hourly* rate, terms of ownership that gives you ownership over work produced until its paid for in full. Include a clause that allows your clients to cancel at any time without warning but they still have to pay for hours worked. (More on why later.) Any contracts provided by your clients have reviewed by a lawyer.
- You *will* eventually (probably sooner rather than later) be stiffed by a client in part or in whole. Have a lawyer you can call to write them a letter. You'll at least get some payment if you have a lawyer write a letter for you. Be sure to know how far you want to push this. The point of a lawyer is not to sue, but to get partial payment.
- You can set your hourly rate more or less randomly. Look to see what other independent contractors are charging (as best you can) and set your rate proportional to your experiance and confidence. Raise your rates annually.
- There are numerous ways to handle proposals. Here's what I do and what I recommend: First, spend time talking with your leads to learn what it is that they need. Write this down in a proposal format that includes the following: 1) A short summary (1 to 2 pages at most) of what the client needs. 2) How you propose to solve their problems. This pretty much says that you'll provide what's listed in section #1. 3) A list of technologies and techniques you're likely to use including languages, platforms, frameworks, database, techniques such as Test Driven Development and Continuous Integration, Source Code Control systems, etc. Provide a short blurb about each item listed and why it's good. And 4) provide a guesstimate of how long you think it will take. More on this in the next bullet point.
- To estimate projects follow this process: 1) break the project down into major steps you'll need to follow to complete the project. This would normally be something like building infrastructure, security, each major section of the application, etc, etc, etc. This is an art and is learned through experiance. Add 33% more for meetings and project management. Add 33% more for trouble shooting and debugging. Add 33% more for post deployment support. Make it very clear to your client that this is *just a guess* based on experiance. As a part of your project management strategy hold at least weekly meetings with your client to show them what you've accomplished, tell them what you're working on, and update them on anything that has taken longer or changed in scope on the project and how that impacts your estimate. Your contact should allow them to cancel at any time. The combination of your initial guess and your weekly updates, combined with the knowledge they can pull the plug at any time gives your client confidence in your project and comfort to pay hourly.
- Invoice bi-weekly and give a discount for payment in the first week. We give 3% discount for early payment in our standard contract. We get good cash flow and our clients save money.
- To find leads for projects I recommend that you network. There are many professional networking organizations out there as well as your local chambers of commerce. Also, attend conferences in your technical expertise. Submit topics to those conferences and try to talk at them. Write for technical journals. Most of these are very easy to get into. In terms of sales, don't try to sell. Instead listen to the problems your leads have and tell
Suggestions from another web developer freelancer (Score:5, Informative)
Guru.com [guru.com] is the best freelancing site I've seen so far. They seem to genuinely respect both sides of the equation, the clients and the freelancers. Compare that to, say, Elance, which seems to treat us like interchangeable cogs. And the built-in escrow is also very nice.
Brush up on your English. A well-written bid makes you stand out among the rest, especially when the rest come from east Europe, for example. This isn't to say that all businesses there are bad, but some most definitely lack decent writing skills, and if your bid is easier to read, it makes you look more professional, and thus makes the client more likely to choose you.
Bill by the hour on all but the smallest projects until you are actually running a business where it's more than just yourself and you have an idea of how much things will end up costing in the long run. Legitimate companies won't take this as a bad thing if you provide an estimate at the same time.
Build payment times into your contract. If at all possible, get all your pay up front in escrow, but if that's not possible, make sure you state something like Net 30 days as your payment terms in the initial contract. If not, you could get shafted really easily when a client takes three months to pay you.
Encourage repeat business. Get into a discussion with your clients about their business, and suggest areas where you could help them achieve their aims. A versatile web developer can do many things for a business.
Place what you'll do into the contract. I don't think you need a lawyer like some of the sibling posts here as long as you're specific. Scope creep can really, really suck if you let it happen.
Oh, and if you happen to need any help with PHP development, give me a shout. ;^)
NEVER bill hourly! (Score:5, Interesting)
You will find clients who wont agree to a fixed-fee (1/3 up front) contract, and those are the clients that you don't want anyway. Your goal should be to work for clients who know what they want, and understand that changes beyond the initial contract will cost them more in money than it will cost you in time.
You will only lose money, when you attempt to do favors for clients who change the scope of work continuously, without regard for your time or contract. Run from these clients, or suffer greatly as you learn why.
Clients should not pay you for the time it takes for you to discover what they want. You should have the ability to provide DETAILED project plans and scopes of work BEFORE your client knows what it will all cost. If a client ever has to ask you: "So, what do we get for that amount?" You failed.
Clients should also not have to pay for you to learn ANYTHING, a new technology, a new software platform, etc. You are supposed to be the pro. If they are paying you to learn, you suck, and will eventually get caught. Learn on your own time.
Provide a standard Boilerplate contract, with an attached Schedule A, defining the specifics of your project. Give your clients a 7-day out-clause, with an understanding that after that time, the upfront payment is YOURS, regardless of any cancellation.
The bottom line is, to be perceived as a professional, you must present yourself that way. If you cant afford to walk away from business, you are not a pro, but a hack.
You would be amazed at what clients will agree to if they perceive that you are confident, professional, and most importantly, not willing to be shat on for their business.
When you bill by the hour, you and the client are at odds from moment one. They want it fast, and believe that you do not, less you reduce your billings. When you charge a flat rate, you are in sync with the client, because now you BOTH want the work done as fast and as well as possible.
No project gets completed without changes or adjustments. You don't want those adjustments costing you, so learn to plan for them, and bid them right into your fee. Dont be a job-shopper with a client looking over your shoulder, calling your cell phone endlessly requesting updated timetables. Your client should know BEFORE THEY SIGN, exactly when (barring changes) the project will be completed.
With a well developed reputation, you will find yourself able to charge for early completion, with the caveat that you will also except penalties for projects that are late. Planning is everything, or you WILL lose your shirt.
If you bill by the hour, every project you do will have a winner and a loser. If you lose, the client is happy, but you left money on the table. If you win, the client is pissed and you wont get more work.
Dont charge by the hour; be good enough to know what your work is worth, and CHARGE for it. If they wont pay, fuck them. Someone will, because if you have your marketing shit together, you wont have to pound the pavement for work.
Good Advice (Score:5, Interesting)
Please excuse me for replying to my own post.
I want to thank everyone for all of your excellent advice. It's obvious there are some very experienced folks here, and it sounds like the way most of you have learned how to freelance is through the School of Hard Knocks. I'm sure I'll be putting some time in there myself, but hopefully not too much ;-)
It sounds like there are a lot of good arguments for and against billing by the hour and fixed-rate quotes, and that may just be something I'll have to try on a case-by-case basis until I find my groove. I can see value in both methods depending on how big or small the job is. I also see a lot of posts about setting up a some form of standard contract and from a CYA perspective that makes total sense to me. All in all I have a lot to consider (this is a good thing), and hopefully someone else who may be in the same boat that I am will benefit from this discussion as well.
This is my first AskSlashdot submission, and after reading through the responses it makes me realize again just how many intelligent and helpful people hang out on this site :-D
Thanks everyone!