How to Start Freelancing as a Frontend Developer

As soon as I started to learn HTML and CSS, I started freelancing. Thank god I was naive, because if I'd known what I was getting into, I probably wouldn't have tried at all.

It's the hardest thing I've ever done, and that includes actually writing code. From actually finding clients — to understanding what they need — to getting paid. It is either exhilarating or it will make you want to sit in the corner and cry.

This isn't an exhaustive guide. It's meant to be a starting point. I'll be expanding on these topics in future videos, so drop your questions in the comments if there's something you want me to dive deeper into.

How to Find Clients

I know the first thing you're wondering is: How do I find clients?

Well, I'm here to tell you that prospective clients are everywhere. Here's how I met my current client list:

The dog park! Literally, I was just BS'ing with people at the dog park, and when someone asked me what I do for a living, I said freelance web designer, and that's how it started. It went from a conversation about how much a new website costs, to actually being hired to build a custom website. That was eight years ago and I still manage that site.

Another client heard me on a podcast about Etsy, because at one point I was selling graphic design on Etsy. But I was also a freelance web designer, and her business needed a new website. But here's the thing, she heard me on that podcast more than a year after it was originally published, and now she's been my client for nine years.

Another of my clients had a WordPress website that was so badly compromised attackers had login credentials and were using his blog to post vile ads using his domain credibility. At that time I was a WordPress developer and I was able to rebuild the site and restore his SEO ranking in search results.

And lastly, I can't even count the number of clients that I've gotten from running ads on Craigslist.

Yes, Craigslist. And listen — the bar is on the floor on Craigslist. Sometimes I go on Craigslist to look for something, and the things people post are so poorly written I wonder why they even bothered posting at all. So when I include screenshots of my work in the image gallery and write ad copy using complete sentences, those ads get noticed.

Now, when I started freelancing in 2014, sites like UpWork and Fiverr were just starting to get popular. I tried to win jobs on UpWork and was always outbid by developers who could work for much less than I could.

So if you can build a freelancing business that way, congratulations — because I thought it was really hard. What ended up working best for me was placing ads on my local Craigslist, and building relationships in my community. And pretty soon I didn't need to run ads at all because I had enough referrals and repeat business that I stayed really busy.

The point here is this: finding clients requires creativity and a willingness to talk to people, wherever you find yourself.

Understanding Client Needs

Once people show interest in your services, then what? Well, you need to figure out what problem you help them solve.

If they sell a service or product, do they need an e-commerce site, or do they need to drive traffic to a platform like eBay or Etsy? Every business owner has an elevator pitch. Listen to the pitch and try to understand what they're asking for. If they already have a website, listen to what they say about how the current site performs.

Some clients know exactly what they want. Some have no idea. Your job is to lead them through that process. But that all starts with understanding their goals and objectives.

Writing Proposals

Next, you need to write a proposal. When I wrote proposals, I restated what I understood their problem was, and how I thought I could solve that problem.

Keep in mind that a proposal is not the same as a scope of work. Think of the proposal as the pitch and the SOW as the contract. The proposal gets the client on board, and the SOW keeps the project on track.

In my early days as a freelancer I wrote detailed proposals that outlined all of the work I planned to do, and sure enough I never heard from those people again. I recall one in particular who insisted I include as many details as possible, and after the hours I spent doing research and writing that document, they turned around and handed it to their in-house developer who implemented all of my ideas. I got nothing for my time or trouble.

Lesson learned: proposals aren't freebies. They're previews — not blueprints.

A proposal is a document that states you understand what the client needs, it estimates the amount of time it will take to complete the work, and it includes your price. When I was freelancing I had fixed pricing and I required a 50% deposit to hold a place on my calendar. Without that deposit, I wouldn't commit to any start date.

Once a new client accepts your proposal, the first thing I recommend is agreeing on a start date and sending the first invoice. Once the invoice is paid, the project goes on the calendar.

Scope of Work (SOW)

Okay, you have the deposit. Next, you should write a scope of work. This is a document that both parties will rely on for the entirety of the project. This is the detailed blueprint of work that you'll be doing. It's how you both know when something is done, and it's how you'll prevent scope creep.

By the way, scope creep happens on a lot of projects. Early on, you'll make mistakes and you'll have to absorb some of it, but as you gain experience, a detailed scope of work will help you manage it. Always refer back to the scope when clients request changes.

As you take on more projects, you'll get a good sense for how to control scope creep. It took me a long time to get a handle on it. But when I started writing really detailed scopes, that's how I got it under control. Because I could always refer back to that document as the final authority.

So, accepting that scope creep happens — and knowing how to deal with it immediately — you can actually turn it into ongoing business. And really, this is learning to manage expectations.

When a client asks for additional work that hasn't been agreed to, say something like: “Let's save that for phase two.”

And if there's work that a client really wants done as part of the original job, be clear from the beginning about how it changes the timeline and increases the price. If the client doesn't agree to pay you for extra work, and allow the time to complete it, don't agree to it.

A scope of work is a document the client agrees to. And this goes back to you understanding what was being asked of you to begin with. It's okay if there's some back and forth when you're agreeing to the SOW, but by this point you should both be clear on the core expectations of the project.

Timeline of Progress

Next, I want you to create a timeline where you present work in phases to the client. Under no circumstance should you build an entire website and not show it to the client until it's finished. That's how you end up doing five rounds of revisions after launch.

Clients should agree to all work as it's being performed. And you should be meeting the deadlines you provided in the SOW.

In the beginning, set up in-person meetings or Zoom calls to present the work so you can answer questions and explain your progress. Sending off an email with a link to a staging site, or a PDF file with the design attached will not get the results you think it will. Clients need to be told what to look at, and you need to explain your progress and the process.

Imagine a client who's paying to have a website built for the first time, opening a link for a development site filled with Lorem Ipsum text. They won't know what they're looking at or how to respond appropriately if you aren't there presenting the work and telling them where their focus should be.

When you present work in person, you can explain what a staging site is — and while the site is in development — how it won't always look perfect as functionality is being implemented.

Developer QA & Client Review

Ok, you've built the website and the client is happy and excited about the work. Next, you need a plan for QA and review.

Start by checking major browsers (Chrome, Firefox, Safari, Edge) and both Mac and Windows. Test on iOS and Android, too. Do not underestimate the number of issues you'll discover. Because you will find issues. Assume nothing works until you check it.

If you don't have access to enough devices to be thorough, either subscribe to a service like Browser Stack or buy some used devices on eBay. I personally prefer to keep a few devices handy, but do whatever works for you.

Accessibility

Next, make sure the site is accessible. If you're new to frontend development and accessibility, I suggest you start with the WebAIM Million project. This project checks the top one million websites every year and documents the six most common accessibility mistakes.

And spoiler alert — it's the same six every year. If you can understand these six issues and make sure the sites you build never have them, you'll have a very good start when it comes to accessibility.

In general, when you perform QA, check the site from top to bottom. Is the margin and padding consistent? Are the fonts the correct size? Do you use anchor elements for links, and button elements to perform actions? Does each page have a meta title and description?

If the staging site is noindex, nofollow, make sure you remove that meta tag when it's deployed to production.

Client Review

How will your client review their new site before it's launched? Are you going to give them a checklist or just turn them loose and wait for feedback?

Based on how I phrased that question, which do you think it should be? Exactly.

Create a document or spreadsheet with specific items the client is responsible for reviewing. This is important, because without a checklist, you risk endless requests after launch. A clear checklist ensures both sides agree on what's done before going live.

Launch & Final Payment

Ok, this next part can be tricky, but it doesn't have to be. Do you wait to launch the site until after you get the final payment, or can you launch, and then send the final invoice? You need to decide what works for you.

Based on my own personal experience, I launched the site first, and then I sent the final invoice. By the time you get to the launch phase of the project, you should have a very good sense for how engaged your client was in the process.

For me, this was an indicator of whether or not I felt confident about getting that final 50%. There was only one time I took a site down for non-payment, and the client sent me an email saying “Oh, I guess you want to get paid.”

And in hindsight it wasn't a surprise that he was dragging his feet, because he was a pain in the ass to work with, and his non-payment was another indication of his lack of respect. Don't be afraid to pull the plug. You're not a hostage.

Conclusion

I'll leave you with some final thoughts. The best advice I ever received was that it's okay to turn away a bad client, because then you'll have time for a good client.

By the way, it's also okay to take a bad client if you need the work. Sometimes when you need to pay the rent, you take on someone who you know will be difficult to work with. But being difficult doesn't equal someone who won't pay you. So raise your rate accordingly.

Around here, we call that the bullshit tax.

If you found this helpful, you can watch the original video on my YouTube channel and leave a comment with any freelancing topics you'd like me to cover next. I've got plenty of stories and tips to share!

Photo Credit:

Photo by Steward Masweneng on Unsplash