Slashdot Mirror
Freelance Web Developer Best Practices?
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."
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.
putting the 'B' in LGBTQ+
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.
Conformity is the jailer of freedom and enemy of growth. -JFK
I've heard bad things about SQL Ledger so i'd suggest doing a good bit of research into its problems before deciding it is appropriate for your use. This may have changed, but what i'd originaly heard a few years ago was enough to scare me.
You can also take a look at LedgerSMB which is a fork of SQL Ledger when a number of people decided to improve it. http://en.wikipedia.org/wiki/LedgerSMB
Personally I like the looks of TinyERP. http:/www.tinyerp.com/ its may be overly complex for your purposes, but i've been looking to migrate to it from QuickBooks for a while. (Yeah Quickbooks works but I hate it. The only reason I still have a windows vmware image.) Plus many linux distros already have packages for it and recently they added a web client.
There was another package i encountered that looked promising, but can't recall what it is. I'd done most of my research at the time on http://www.sf.net/ (Sourceforge) and http://www.freshmeat.net/ (Freshmeat)
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.
Anyone who loves or hates any language, platform, or manufacturer, doesn't know what they're talking about.
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
Time and materials is essential when you have clients who can't make up their minds. Usually, start these people off with a bidded job, but take any change to the project as an excuse to concert the job to "T&M".
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.
Malama
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. ;^)
It's better to vote for what you want and not get it than to vote for what you don't want and get it.
- E. Debs
There aren't many instances where tables give an advantage, and in the few instances it, the advantage isn't significant
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
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.
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!
Pick one from here.
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.
That cannot be emphasized enough! Once the client sees their original spec in action, it WILL occur to them that it's not exactly what they need even though it is what they asked for. You must have a policy and procedure in place so that you can accommodate that without ending up doing 3 projects for the price of one.
The procedure should include a discussion of how much the change will cost. A little 'economic feedback' is a great way to keep change requests from becoming the death of 1000 cuts.
For little things that really aren't a bother and really will make the client happy, you're always free to waive the charges.
One thing to keep in mind. I've found (oddly enough) that the more cost conscious the client is from the start, the more perfection they seem to expect. The guy who pounds on you endlessly to get you to drop the estimate another $10 will be the one who wants to see the site in every possible shade of red (only to settle on the first proof you offered) and expects an AI based log parser thrown in at the end for free.