Skip to content

20 Rules for Freelance Web Developers

I am frequently asked for tips about how to work with clients, close deals, and successfully execute contracts. It’s no secret that landing and executing web development contracts can be tricky and frustrating, especially if you encounter a challenging client. This article will serve to outline some strategies that I’ve found to be effective and indispensable.

  1. Make sure that your portfolio looks amazing. If you’re brand new and don’t have clients yet: Make sample client sites. Generate an imaginary business name and build a site using stock images and make your own copy text. Put a disclaimer at the bottom that says that this is a sample site for web design purposes only and a link back to your CV or email. Set all contact information on the sample site to direct to your inbox or phone. When clients flip through your portfolio they may not even notice that this is a ‘sample site’ and even if they do it doesn’t matter because it still shows you can produce quality work.
  2. Your portfolio is your salesman. Don’t be salesy. Not only is your portfolio critical to landing good clients, it should be the only sales pitch you ever need. The clients that you want to land will want to buy what you’re selling more than you want to sell it to them. Think about that for a moment. You should never have to try hard or be ‘salesy’ because that leads to landing challenging clients. Try this: “Hello, I’m an experienced web developer, this is my portfolio. Please review it. If you’re interested, let’s schedule a meeting to discuss the project and get started.” — That’s it. That’s your whole sales pitch.
  3. Some clients are challenging. Typically the most challenging clients are the indecisive ones. They don’t know what they want, or aren’t sure if they can afford the work. Avoid these clients. 80/20 rule: spend 80{5e24fea1332bc560952b53c9e8c06b9b33a29e675faab0aa0da8ffddcd9b108f} of your time finding the 20{5e24fea1332bc560952b53c9e8c06b9b33a29e675faab0aa0da8ffddcd9b108f} of clients that know what they want, and can afford it. You can tell when you’re talking to the indecisive clients because you will feel like you’re having to work hard to sell your services. Don’t do that. If they say things like ‘I’m not sure what I want to do’ or ‘I have to look at my budget’ just politely tell them to figure it out and get back to you. If you’re talking to a client that knows what they want: it will be obvious. They will have done some research, and may mention certain themes or styles or even say that they have similar sites in mind or provide a wireframe. — These are the clients that you want to land. If you want to weed out the indecisive ones early just start your conversation with: “Do you know what you want the project to be like?”
  4. Prepare thoughtfully. Before sitting down with the client to discuss the project remind them to gather notes, content, and three examples of sites they like. I also ask clients to show me three sites that they don’t like to get a feel for what they’re really looking for. Discuss the pros and cons of different platforms and frameworks ahead of time so you have an idea of which pre-made themes or frameworks you can start from for the project. Prepare a list of bookmarks for demos of the themes so that you can demo them and narrow it down during the meeting. If you’re planning to make a fully customized theme (and I recommend against this, if possible) hire a designer to create the theme, or have the client prepare a wireframe, and outline, or a PDF prior to the meeting.
  5. Have a GREAT legal agreement document. I painstakingly spent an entire day crafting mine from several other agreements, using advice from other developers, and using my own experience. This agreement attempts to handle every possible scenario, but also is configurable based on your needs. It sets reasonable expectations for the project, outlines responsibilities of both the client and the developer, and paves the way for a mutually respectful relationship. Go through it with the client word for word and explain everything, it’s worth the time. (and it’s OK to bill for the consultation)
    Download My Agreement — Disclaimer: I am not a lawyer. Use this agreement at your own risk.
  6. Don’t support old browsers, unless you have to. My agreement explicitly excludes support for old browsers unless written into the deliverables. The reasoning for this should be pretty obvious.
  7. Give the client a deadline to hand over content. This is crucial. Set your project with a projected completion date that makes sense based on this deadline of getting the content from the client. If the client misses this deadline, the projected completion date gets pushed out.
  8. Outline the basic deliverables of the project. Example: The site will have 5 pages: landing page, about, contact, services, and FAQ. It will contain a content management system for the client to make changes, and it will be built on WordPress and installed to the client’s hosting account.
  9. Make them aware that they will continue to need a developer to make certain changes. Even if you’ve included a content management system that allows them to make changes, it’s likely that at some point they will need you again to change some code around or add a feature.
  10. Check in frequently. I recommend checking in with the client weekly to show them progress so that changes can be made before you get too far ahead of the desires of the client. If you get too far apart on a project, that’s when things can go sideways, so avoid it by keeping them informed and thoughtfully integrating their ideas and content.
  11. Don’t allow micromanaging. A weekly check in should be sufficient, this qualifies as a 15–60 minute call the client can give feedback. A great idea to encourage feedback is to say: tell me three things you like about the project, and tell me three things you don’t like and why. This helps to soften any ego blow from the criticism, because you’re getting some positive reinforcement first, but also helps you to really get useful feedback. Rinse and Repeat this technique. It works well for getting feedback on their existing site if you’re getting started on a project, as well. Hearing specific details is always much more helpful than ‘I don’t like this or that’. You need to know why.
  12. Use design principles, and know your C.R.A.P. Contrast, repetition, alignment, proximity. These are the most important things to consider in design. A good design is the design you don’t notice, it allows the content to be easily digestible and just works how it should. Consider color-psychology before picking a palette and consult the material design palette and for color choices and saturation levels. Material design guidelines exist for font weights, shadows, borders, and anything you can think of. Use them.
  13. Bill hourly, and give a ballpark estimate range. I know it may seem tempting to quote a flat rate amount for the whole project, and other people seem to make out well sometimes by doing so, but I strongly urge you not to do that. Here’s why: it doesn’t benefit anyone. You might think that you will make out better with a flat rate if you can get the project done quickly. However…you’re opening yourself up to the endless cycle of revisions. The client can keep coming back with changes again and again and they may never be satisfied. The client may feel that you’ve padded the estimate to include the revisions. (and it’s probably true because you have to expect there will be revisions and plan for them) Avoid that altogether. Give an estimate range in hours for how long you think the project will reasonably take, and set an hourly rate. This benefits both parties because if the project is done in less time the client saves money, and if the project goes longer than expected the developer makes more money. Either way, you both get a fair deal. This encourages the client to be reasonable about making changes in the middle of the process because: they have to pay for redoing things that have already been done. Billing hourly with a ballpark range also encourages ongoing work at the end of the project because there’s no cap on the dollar amount for the project at the beginning. This also means less pressure during the build process because you know you’re getting paid fairly either way.
  14. Collect a retainer. If you hire a contractor to build you a house, you’re obviously going to pay something up front to get started on the work, right? Web Development shouldn’t be any different. Generally for smaller projects I set the retainer to be about half of the projected total. For larger projects I will set it between half and one third of the projected total. In my agreement there’s a space to insert terms for how payments will come due when the retainer is exceeded. This part is up to you, but generally I check in with the client and bill weekly, and give ten day terms. With these terms you never go a full two weeks without being paid, and the client gets frequent check-ins on the progress and has a good idea of what they are being billed for every week. Setting the balance due ‘upon completion’ is usually a bad idea because projects can be never-ending, and that’s supposed to be a good thing, not a long awaited payday.
  15. Have a good exit clause. Either party can exit the contract at any time, and payments will be due for all services rendered up to that point. That means that if the client decides to exit in the middle of the project they don’t get a refund, but they do get to keep the unfinished project as it sits. It also means that you may exit in the middle of the project if you need to. This benefits both parties. If the client doesn’t like how things are going, or something comes up, they can exit. If the developer doesn’t like how things are going, or something comes up, they can exit. Having this clause helps to alleviate unreasonable client requests, because the developer can exit. It also helps to alleviate clients that may flake out in the middle because they’ve already paid a retainer and are still responsible for whatever work has been done, they may as well finish the project.
  16. Have good intentions. Don’t sign into a project that isn’t a good fit. If the project is beyond your abilities, or doesn’t seem like something you can manage: reach out for help before signing on and make a plan. You might consider recommending a more qualified agent to do the work. Don’t get in too far over your head. A little over your head is OK, in fact it’s great. It’s important in the beginning to challenge yourself a bit, and it’s good to stretch your skills and personally grow. There’s a difference between something that’s a stretch, and something that’s just beyond your abilities. Know the difference and respect it.
  17. Write maintainable code. This goes without saying. You will probably be the one that ends up maintaining the site in the long run. Do yourself a favor and keep the campground cleaner than you found it. The next guy will thank you too.
  18. Have fun! Positive energy makes the best output. Work in a relaxed environment where you can focus and take frequent breaks.
  19. Google everything! If you’re not sure about something, google it. Someone else has probably already created a solution for the problem you’re experiencing.
  20. Stack Overflow.