← Back to blog
·10 min read·Urkel

How to choose a web developer without getting burned

HiringBuyer's guideWeb development
ContentsMenu

A business owner and web developer reviewing a website layout on a tablet during a discovery meeting

Almost every business owner I know has a story.

They hired someone to build a website. The developer took the deposit. Then everything got slow. Replies took days. The site that arrived looked nothing like what was promised. Buttons were broken. Sometimes the developer just disappeared with the money and the half built project sitting on someone else's server.

The story is so common that most owners now treat hiring a developer the way you would treat picking a stranger out of a crowd and handing them your wallet. Hopeful but expecting the worst.

It does not need to be this way. There are excellent developers. There are also terrible ones. The difference between them is not their pricing, their location, or how nice their portfolio site looks. The difference is a short list of things you can check in about an hour, before you ever send money.

Here is the list.

Generated whiteboard image showing the one hour developer hiring filter: proof, questions, proposal, references, ownership, and support

Why this matters more than people realize

Hiring a bad developer does not just cost you the money you paid them. It costs you all the time the project should have taken plus the time you actually spent dealing with the mess. It costs you the sales you would have made if your real site had launched on time. And it costs you the trust you have in the whole idea of paying for software, which can stop you from ever trying again.

I have met owners who got burned once in 2021 and have not hired a developer since. Their business is still running on a Wix template they hate, because the idea of trusting another stranger feels worse than living with a bad site.

I do not blame them. But the lesson should not be "never hire developers". It should be "learn how to tell good ones from bad ones in advance". This post is that.

The four kinds of developer you will meet

When you put out a brief, the people who respond will mostly fall into one of four buckets. Each behaves differently and you need to know which is which.

The student or freelancer who just started. They charge very little. They are learning on your project. Sometimes they ship something fine. Often they get lost halfway and either ghost or deliver something you cannot really use. Use them only for things where it is okay if it fails. A real business website is not that.

The cheap agency or sweatshop. They quote a low number and over promise. The person you talk to in sales is not the person who builds. The actual builders are juniors trying to ship 20 projects a month. You get a templated site that looks like every other site they made, plus headaches every time you ask for a change.

The lone expert. Real developer, real skills, often working alone or with one or two collaborators. Charges middle to high. Ships well, communicates clearly, handles complex needs. Risk is that if they get busy or sick, your project stops. They usually have a network they can pull from to soften this.

The small studio. A team of three to ten. Specialists working together. Charges middle to high. The structure means they can ship faster than a lone person while still caring about your project the way a big agency never will. This is where Keldra sits, so I am biased, but this is the bucket I would recommend for most real businesses.

The pricing across the four is not strictly higher as you go down the list. A bad agency can charge more than a good studio. A confident freelancer can charge more than a junior agency. Price alone tells you nothing. The signals below are what tell you.

Red flags that tell you to walk away

Some of these are obvious. Some are not.

They quote without asking what you actually need. A real developer needs at least 20 minutes of conversation before they can quote anything. If someone gives you a fixed price the moment you message them, they are either guessing or planning to upcharge later.

Their portfolio is mostly screenshots, not links. Anyone can put a photo of work on a site. The test is whether the actual sites still exist and still work. Click the links. If half are dead, that is what is going to happen to your site too.

They say yes to everything. A real developer pushes back. They say "do you really need this", "I would do this differently", "this part is going to be expensive". Someone who agrees with everything is either lying or going to deliver something that does what you asked for instead of what you actually needed.

They cannot explain anything in plain English. Some technical jargon is fine. But if every answer is a wall of acronyms that leaves you more confused than before, that is the experience you will have for the entire project. Now imagine asking for a refund and getting that same wall of jargon back.

They do not have a written process. Good developers have a clear way of working. There is a discovery phase. There are check ins. There are deliverables. If someone cannot describe how the project will run from start to finish, they have not run enough projects.

They will not start with a paid discovery. Good developers want to scope your project before quoting. Cheap discovery (one paid hour, or sometimes free) protects both sides. Someone who skips discovery and jumps straight to "send me 50 percent deposit and I will start" is taking on no risk while making you take on all of it.

The price is way lower than everyone else. When five developers quote you 4 million naira and one quotes you 800k, the one is not a steal. They are either inexperienced, planning to disappear, or going to deliver 800k worth of work and then surprise you with change requests until you reach 4 million anyway.

Green flags that tell you to stay

The good signs are quieter but they matter more.

They ask hard questions about your business. What do you actually sell. Who buys. How do they find you now. What happens after they click. A good developer cares about whether the site will work, not just whether it will look nice.

They have a clear contract. Real businesses have real paperwork. Scope, deliverables, payment schedule, what happens if things change, what happens if either side walks away. If someone sends you a one paragraph proposal and asks for a deposit, they are not running a business yet.

They link to live work and let you click around. Bonus points if they tell you which sites they built solo and which were collaborations. Honest developers are specific about their role.

They have references they will let you talk to. A 10 minute call with a past client tells you more than any portfolio. A good developer is happy to set this up. A bad one stalls or makes excuses.

They give you a timeline that includes time for things going sideways. Real software projects always have surprises. A developer who quotes you "two weeks, guaranteed" is either lying or about to ship something half done. The honest answer sounds more like "four weeks, with one week of buffer because some part of this always takes longer than expected".

They are clear about what they do not do. Specialists are stronger than generalists. A developer who says "I do not do ecommerce, you should hire someone else for that" is more trustworthy than one who claims they can do everything.

Questions to ask before you sign anything

Print this list. Bring it to the call.

  1. Walk me through three projects similar to mine. What did you actually build, what was someone else's part, and what was the hardest part?
  2. Who exactly will be working on my project? Will it be you, or will you hand it to someone else?
  3. How will we communicate, how often, and through what tools?
  4. What happens if I need a change after the project starts?
  5. What is the payment schedule and what triggers each payment?
  6. What do you do if the project goes over the agreed timeline? Who pays for that?
  7. Who owns the code and the design files when we are done?
  8. What happens after launch? Is there a support period? What does it cost?
  9. Can I talk to two past clients?
  10. If I wanted to walk away one month in, what is the exit?

A good developer answers all of these without flinching. A bad one dodges half of them. Watch how they answer, not just what they say.

What a real proposal looks like

Generated whiteboard image showing what a real web development proposal includes: summary, deliverables, timeline, price, payment, and what is not included

A real proposal has six things. If yours is missing any of these, you are about to make a mistake.

A summary of what you said you needed. Confirms you are both on the same page.

A list of deliverables. Specific. Not "a website" but "five pages with the following content and functionality".

A timeline with milestones. Week one we do this. Week two we do that. Launch in week N.

A price with a breakdown. Not just one number. You should see roughly where the money goes.

A payment schedule. Usually 30 to 50 percent upfront, milestones along the way, balance on launch.

What is not included. This is the most important one. Things like hosting, third party tools, content writing, photography. If these are not called out, expect surprise bills.

If your proposal is one paragraph and one number, ask for the real version. If the developer cannot produce one, you have your answer.

The fastest way to filter before any of this

You can save yourself most of the work above by doing two things at the start.

First, look at the developer's own website. Is it fast? Does it explain what they do clearly? Do they have real client logos and case studies, or just stock photos and buzzwords? If a developer's own site is a mess, the site they build for you will also be a mess.

Second, look at how they reply to your first message. Is the reply clear? Did they ask follow up questions? Did they offer to set up a call instead of jumping to a quote? The way they handle the first message is exactly how they will handle every email after you pay them.

Most bad developers fail at one of these two tests. You can save yourself a lot of pain just by filtering on them.

How we do it at Keldra (so you know what good looks like)

We charge for discovery. Usually it is a paid 90 minute conversation where we look at what you have, what you need, and whether the project is even right for us. Sometimes that conversation ends with us telling you that you do not need a custom site, you need to fix three things on your current one, and we send you on your way.

When we do take a project, the proposal answers all six things above. The contract is in writing. Payments are tied to milestones. You get the code and design files when we are done. We tell you what we do not do (we mostly do not take large enterprise builds that need a dedicated team of 15).

You can book a 20 minute call and we will do the discovery part for free. If we are not a fit, we will tell you who is. We would rather send you to someone good than take a project that does not suit us.

The one sentence summary

Pick a developer the way you would pick a doctor. Ask hard questions, check references, walk away from anyone who gets defensive, and pay more for someone who is clear and honest than for someone who is cheap and vague.

If you do that, you will not get burned. You might still hit a few bumps because real projects always do. But you will not lose the months or the money that the worst stories cost.

Want us to build something for you? Contact the team.