Back to Blogs
I have been freelancing as a web developer for years now, most of it through Fiverr, and the project count has gone past 1,000. Some were small fixes that took an hour. Some were full websites with an admin panel, payments and a lot of back and forth. Along the way I made plenty of mistakes, and most of what I do today comes from fixing those mistakes so they don't happen twice.
This post is not a guide to getting rich on Fiverr. It's the handful of lessons that actually changed how I work, written down for other developers starting out and for clients who want to know what a good freelance project looks like from the other side.
Most problems start before the order is placed
When I look back at the projects that went badly, very few of them went wrong because of code. They went wrong in the first conversation, when the buyer and I each walked away with a different picture of the job.
Ask questions until the job is boring
Early on I was happy to start as soon as someone said "I need a website like this one." Now I ask until there is nothing left to guess. Which pages? Who writes the text? Does the contact form need to send to one inbox or two? Should the owner be able to edit prices? Is there an existing domain and hosting, and who has the login? If the answers feel boring and obvious, that's a good sign. Surprises in the middle of a project are what cost time.
Write the scope down in plain words
Before I start, I send a short list of what is included and what is not. Five pages, one contact form, mobile layout, basic SEO setup, two rounds of changes. If something comes up later that is not on the list, we can both look at it and agree whether it's a small extra or a new task. Without that list, every request becomes an argument about what was "obviously" included.
Communication matters as much as the code
Buyers on a marketplace can't see me working. All they see is the chat. If the chat goes quiet for two days, they assume nothing is happening, even if I spent those two days on their project.
Reply fast, even when the answer is "I'll check"
I try to reply within a few hours. Not every reply needs a solution. "Got it, I'll look at this tonight and get back to you" is enough to keep someone calm. Fast, honest replies have done more for my reviews than any design skill.
Show progress, not just the final result
I share a preview link early, even when the site is half done. A buyer who sees the layout on day two can tell me the colours feel wrong while that's still a five minute change. A buyer who only sees it on the last day finds the same problem when it means redoing several pages.
Explain things without jargon
Most of my clients are business owners, not developers. When something needs their decision, I explain it in a sentence they can act on. "Your emails go to spam because the site sends them without proper authentication. I can fix it by sending through your domain's mailbox." That works much better than a paragraph about SPF records.
Pricing and time
Small jobs are not always small
"Just fix this one bug" can mean ten minutes or two days. I learned to look at the site before quoting, ask for access when possible, and give a price only after I know what I am dealing with. If I can't see the problem yet, I say so and quote for an investigation first.
Pad the deadline, then beat it
Things always take longer than the happy path suggests. Hosting is slow to respond, content arrives late, a plugin breaks after an update. I now set delivery dates with room for that, and if I finish early, the buyer gets a nice surprise instead of an apology.
Underpricing hurts both sides
When I charged too little, I rushed. Rushed work meant more bugs, more revisions and less patience on both sides. A fair price lets me test properly and do the small things nobody asked for but everybody notices, like a working WhatsApp link or a proper 404 page.
Technical habits that saved me
Back up before touching anything
Every time I get access to a live site, the first thing I do is take a full backup of the files and the database. It takes a few minutes, and the few times something went wrong it saved the whole project. I don't skip it, even for a "tiny" change.
Work on a copy, not the live site
Where I can, I build and test changes on a staging copy first. The owner keeps a working site while I work, and the switch happens only when we're both happy with the new version.
Test like a visitor
A page loading is not the same as a page working. Before I deliver, I fill in every form with real details, tap every button on a real phone, check that emails arrive in the inbox and not in spam, and read the text on each page. Most of the issues buyers would have found later get caught here.
Keep the tools simple
For most small business sites, I use tools that any decent developer can pick up later: PHP and MySQL, clean HTML and CSS, or WordPress when it fits. A site that only I can maintain is a problem for the owner, and owners notice that.
Reviews, revisions and difficult projects
Revisions are part of the job
I used to feel annoyed by change requests. Now I treat the first round of changes as expected, because nobody knows exactly what they want until they see it. What helps is agreeing on the number of revision rounds up front and grouping changes into one list rather than ten separate messages.
Not every project is a good fit
Some requests are outside what I do well, or the buyer wants something in a timeline that isn't realistic. Saying no politely, or pointing them to a better option, has saved me from projects that would have ended in a bad review and a refund. A cancelled chat costs nothing. A cancelled order costs a lot more.
Stay calm when things go wrong
Sometimes a buyer is unhappy, and sometimes they are right. When that happens I try to answer the actual problem, say what I'll do and by when, and then do it. Getting defensive in the chat never helped a single project.
What I would tell a new freelance developer
- Spend more time on the first conversation than feels necessary.
- Put the scope in writing, even if it's five lines.
- Reply quickly and share progress early.
- Back up first, work on a copy, and test everything like a real visitor.
- Charge enough to do the job properly.
- Turn down work that doesn't fit, politely and early.
None of this is complicated, and none of it is about being the best coder on the platform. Most buyers want someone who understands what they need, keeps them informed and delivers something that works. If you can do that consistently, the reviews and repeat orders follow.
If you have a website project and want to talk it through, you can send me a message and I'll tell you honestly whether I'm the right person for it.
