How to Choose a Web Developer: The Project Owner's Guide Before You Sign

I'm Khaled Ahmed, a freelance Full Stack developer in Cairo. Over 5+ years I've shipped 39+ production projects across eight countries, and a meaningful share of them started as somebody else's rescue job. Here is the verdict up front: projects almost never fail because the wrong framework was chosen. They fail because the wrong person was chosen, and because nothing was written down. This guide gives you the tests, the questions, and the contract terms that expose a developer's real level before you pay anything.

1. The Verdict First: What Actually Decides Whether Your Project Ships

If you read one section, read this one.

A professional developer is identifiable by three things, all of which you can verify before money changes hands:

1. They asked you questions before quoting a price. Anyone who prices before understanding does not know what they are pricing.
2. They have live work on the internet that you can open right now — not screenshots, not a beautifully designed PDF.
3. They will put everything in a contract: scope, timeline, ownership, maintenance, and what happens when a deadline slips.

Everything else in this article is detail hanging off those three. The technology itself — Laravel or Node.js, React or Vue, WordPress or custom — is the least dangerous decision you will make. A clean WordPress build beats a careless build on the newest framework in the market every single time. If you want the technical comparison on its own terms, I wrote WordPress vs Laravel for exactly that.

2. How Do I Know a Developer Is Good Before I Pay? Seven Practical Tests

You can run all seven in an afternoon, with no technical background.

Test 1: The reverse-questions test

Send a short, deliberately incomplete description of your project. Then say nothing and watch what comes back.

A professional replies with questions. Who are the users? Is there an admin panel? How many languages? Do you need online payments, and through which gateway? Is there an existing system with data to migrate? Who manages content after launch? What device do most of your visitors use?

An amateur replies with a price and a timeline within minutes. That is not responsiveness — it is evidence that they will build what is in their head rather than what is in yours, and that the price will change later. It always changes later.

Test 2: Open their work yourself

Ask for live URLs, not images. Then:

• Open them on your phone first, not your laptop. Most of your traffic will be mobile.
• Run each URL through Google's free PageSpeed Insights and read the Mobile score, not Desktop.
• Actually submit a contact form and see if anything happens.
• If it is a bilingual site, check that the Arabic RTL layout is not broken — numbers, dates, menus, and mixed Latin/Arabic strings are where sloppy work shows.

Then ask the one question that separates people: "Which specific parts of this did you build?" Recycled portfolios are common in this market — a developer who built one page on a project will present the whole thing as theirs. A professional answers precisely and tells you where their involvement ended. That's why I publish my work as open, clickable links rather than a deck.

Test 3: Ask to see a code repository

Ask for a GitHub or GitLab profile, or at minimum a screenshot of the commit history on a past project with client details redacted. You do not need to read the code. You need to see:

• Many commits spread over weeks — not a single commit named final.
• Commit messages that mean something, not update fifty times in a row.
• A README and a .env.example in the repository root.

Someone who refuses to show any code on any project, ever, citing client confidentiality across the board, usually is not using version control at all. That alone is disqualifying: a project without version history is a project where no mistake can be undone.

Test 4: Buy a small paid trial

Do not ask for free work — good developers correctly refuse it. Ask for a small paid task instead: one page, one signup form, or a bug fix on your current site, with a fixed small budget and a three-day deadline. This is the cheapest way in existence to test someone before handing over a six-figure project. A trial tells you what no proposal can: do they hit the date, do they explain themselves, do they vanish over the weekend, do they deliver clean work or something that merely happens to run?

Test 5: Ask about a project that went badly

"Tell me about a project that went wrong and what you changed afterwards."

Anyone with five years of work and zero difficult projects either hasn't worked, is lying, or lacks self-criticism. My own answer: I learned the hard way to refuse projects where the actual decision-maker never joins the calls, because review cycles then loop forever and nobody can approve anything.

Test 6: Probe how they think about security

Ask: "How will you protect my customers' data?" A professional answer names concrete things — modern password hashing, enforced HTTPS, protection against SQL injection, XSS and CSRF, role-based permissions, rate limiting on login, automated daily off-server backups, and a plan for keeping dependencies patched. A weak answer is "the site will be secure" or "we'll add SSL." I keep the full list in my website security checklist, and it's a fair thing to hand a candidate and ask them to walk through.

Test 7: Verify they are who they say they are

Ask for ID, a commercial registration, or a tax number, and confirm the name matches the bank account or wallet receiving payment. Insist on at least one video call — text-only relationships are where fraud lives. Search their name and phone number. Impersonation in this market does not require sophistication: a WhatsApp number and a stolen portfolio is the entire toolkit.

3. Agency or Freelancer: What's the Real Difference?

The honest answer is that neither is better in the abstract. One is better for your project size and your tolerance for a specific kind of risk.

My working rule: if the project needs fewer than three full-time people, an experienced freelancer gives you better quality, a lower price, and faster iteration. If it needs a full team with a project manager, a QA engineer, and 24/7 support, hire an agency. I broke down the full cost and risk comparison in freelance developer vs agency.

The risk nobody mentions on either side

With a freelancer, your real exposure is the single point of failure — one person holds all the context. The fix is one contract clause: code is pushed continuously to a Git repository the client owns, and setup documentation is delivered from week one. Then any competent developer can pick it up in days.

With an agency, your real exposure is the gap between the salesperson and the builder. A polished pitch wins the deal, then a fresh graduate writes the code. The fix is a different clause: name the lead developer and their experience in the contract, and reserve the right to object to a substitution.

4. Warning Signs When Hiring a Developer

This list comes from projects that arrived on my desk after failing somewhere else. One sign is not a verdict. Three together mean walk away.

During negotiation

• A price under half the market average. Nobody works at a loss. The gap gets recovered through a pirated template, disappearance after the deposit, or change requests later.
• "Your site will be ready in three days." A real store is not built in three days. Whoever says it is either cloning a template or does not understand what they agreed to.
• Refusal to sign a written contract in favour of a "WhatsApp agreement." This is the single most dangerous sign on the list.
• Time pressure aimed at you: "This price expires today." Serious developers do not sell like a call centre.
• Inability to explain a technical idea in plain language. People who genuinely understand can explain simply. People who bury you in jargon are usually covering a gap.
• No questions about hosting, domain, or email. It means they have not thought about handover at all.

During the build

• No staging URL where you can see progress weekly. Working in the dark until "delivery day" is a reliable path to disaster.
• Repeated disappearances with recurring excuses. Log them. They get worse after the second payment.
• Asking for the next payment before delivering the milestone it is tied to.
• Refusing to give you hosting or repository access "until it's finished." That is hostage-taking, not methodology.
• Every small change breaks something else. A sign of code with no structure, and you will pay for it monthly for years.
• Nulled or pirated plugins and themes. This is not just an ethics question — nulled assets are one of the most common backdoors into hacked sites in this region.

5. Questions to Ask a Developer Before Signing

Print this and keep it in front of you on the call. Next to each question is what the answer tells you.

Pay particular attention to the revisions question. "Unlimited revisions" is not a benefit; it is a time bomb. Either the developer walks in month three, or you start feeling guilty every time you ask for a change. A fixed number is kinder to both sides.

6. What "Professional Website" Actually Means: Acceptance Criteria You Can Write Into a Contract

"Professional" has no contractual meaning. Convert it into numbers you can measure on delivery day. These are the criteria I put in my own contracts:

• Performance: Lighthouse mobile Performance score of at least 85 on key pages, with LCP under 2.5s, CLS under 0.1, and INP under 200ms. (Those are Google's Core Web Vitals thresholds as of writing in 2026; Google has revised these metrics before — INP replaced FID in 2024 — so re-check web.dev before you sign.)
• Responsiveness: No breakage from 360px width upward, tested on real Chrome and real Safari on an actual iPhone, not only an emulator.
• Security: Enforced HTTPS, baseline security headers, bot protection on forms, automated daily backups stored off the server.
• Technical SEO: Unique titles and descriptions, sitemap.xml, robots.txt, structured data, and clean readable URLs. The full list is in my SEO checklist.
• Admin panel: You — not the developer — can edit text, images, prices, and add a new page without code.
• Compliance: If you invoice in Saudi Arabia, invoicing must meet ZATCA e-invoicing requirements; in Egypt, the ETA e-invoicing system. Name it explicitly in scope. It is real additional work, not a detail.

Also require that the repository is legible enough to hand to any developer who comes after:

project/
  README.md          <- how to run it locally, step by step
  .env.example       <- every required variable, no real secrets
  database/          <- migrations + seeders
  docs/deploy.md     <- how a change reaches production
  tests/             <- even a few, on the critical paths

If a project is handed over with no README, no .env.example, and passwords hardcoded into source files, you are looking at amateur work no matter how good the front end looks.

7. What Should It Cost? Honest Ranges, Not a Fake Quote

I cannot give you a price without knowing your project, and anyone who does is guessing at your expense. What I can give you is the ranges I see in the market, so you can recognise a suspiciously cheap bid and an inflated one. Assumptions: custom design, two languages, an admin panel, and deployment to real hosting.

These are market ranges as I observe them in 2026, not quotes, and they move with exchange rates and scope. What drives the number up or down is broken out in website costs in Egypt vs the Gulf and in how much a website costs in 2026.

8. How Much Deposit Should I Pay?

Short answer: never pay 100% upfront, and never ask a professional to work with no deposit at all.

The sane range is 30% to 50%. I personally work at 40% upfront on mid-size projects, for a practical reason: accepting your project means turning down someone else's to reserve the time.

But the percentage matters less than the payment structure. Tie every payment to something you can see:

Those are negotiating bands, not a sum: pick one figure from each row so that the four payments total exactly 100%. Taking the top of every band would come to 115% and the bottom of every band to 85%, so the balancing is yours to do before the contract is signed.

Always hold back at least 10% against complete handover including access and documentation — not merely "the site works." That retained 10% is the cheapest insurance policy you will ever buy.

If the developer is entirely new to you, run at least the first payment through a platform that holds funds in escrow — Mostaql or Upwork, for example. You pay a small commission and in exchange you get a dispute mechanism, which a direct bank transfer does not give you.

9. The Contract: The Minimum You Should Never Waive

Most disputes I have seen were not caused by bad faith. They were caused by one vague sentence. A written contract is not an accusation of dishonesty; it is the document that saves both sides when two memories diverge three months later.

The minimum any web development contract should contain:

1. A detailed scope document attached as an annex: every page, every function, every third-party integration, and explicitly what is out of scope.
2. A timeline with milestone dates, plus your own obligations (content, logo, payment gateway credentials) and the schedule impact when you're late.
3. Explicit IP assignment: code, design, and content belong to the client on full payment, with the developer retaining the right to show the work in a portfolio.
4. Revision rounds and the price of additional rounds.
5. A handover clause listing exactly what gets delivered (see the next section).
6. A bug warranty period, typically 30 to 90 days of free fixes within the agreed scope — with a clear line drawn between a "bug" and a "new request."
7. A termination clause: what happens if either side walks, how amounts owed are calculated, and who receives the work completed so far.
8. Confidentiality and data protection, particularly if the project handles customer data. Saudi Arabia has the Personal Data Protection Law (PDPL); Egypt has the Personal Data Protection Law No. 151 of 2020, whose executive regulations were issued in late 2025. State the developer's obligation to handle data securely and delete it when the engagement ends.

Don't start from a blank page. I published an Arabic web development contract template you can adapt, and covered the ownership question at length in who actually owns your website code.

10. What to Demand at Handover

This is the moment most project owners lose. The site works, so they pay the balance and celebrate — then discover six months later that they own almost nothing.

Here is the handover list I sign with clients. Ask for it verbatim:

1. The domain registered in your name and your email at the registrar, with login credentials. Verify the WHOIS record yourself.
2. Hosting or server account in your name, with full credentials (control panel and SSH where applicable).
3. Complete source code in a Git repository under your account — not a ZIP file sent over WhatsApp.
4. The database: a full backup, the schema, and restore instructions.
5. Every third-party account registered to your email: payment gateway, transactional email, SMS provider, Google Analytics, Google Search Console, app stores.
6. Source design files (Figma or equivalent) with edit access.
7. Operations documentation: how a change is deployed, where settings live, which paid services the project depends on and what they cost monthly.
8. A short training video on the admin panel. Twenty minutes here saves a hundred messages later.
9. Licences for every paid theme, plugin, or font, in your name, with invoices.

A note specific to mobile apps

If your project is an app, the Google Play and Apple Developer accounts must be in your company's name, not the developer's, or you lose the app at the first disagreement. Also note that Google requires new personal developer accounts to run a closed test with a minimum number of testers for a set period before public release — a policy that has changed more than once since 2023, so verify the current wording before you schedule a launch date. I covered it in detail in the Google Play 12-testers requirement.

11. What to Do When It Has Already Gone Wrong

Assume you've paid 50% and the developer has stalled or disappeared. In order:

1. Put everything in writing. One clear message: what was agreed, what was delivered, what is late, and the deadline you are giving. Send it by email, not only WhatsApp.
2. Demand immediate handover of whatever exists — current code in a repository, plus access credentials. Even incomplete work has value once you hold it.
3. Do not pay more "to motivate them to continue." It increases your loss and fixes nothing.
4. Rotate every password the moment the relationship ends, and remove their access from the repository, hosting, and all connected accounts.
5. If you hired through a platform with escrow, open a dispute immediately with your written evidence attached.
6. Do the arithmetic calmly on finishing with a new developer versus pursuing the old one. On most small and mid-size projects, moving forward is cheaper than litigating.

When you look for the replacement, don't repeat the original mistake. Start with a small paid technical audit of the existing code before agreeing to continue it. A serious developer will tell you honestly whether rescuing is cheaper than rebuilding — and sometimes it is not.

12. A Seven-Day Plan Before You Sign

If you are days away from signing, do this in order:

• Day 1: Write one page describing your project: goal, audience, the three most important functions, languages, rough budget, target date.
• Day 2: Send it to at least three candidates, one of whom is more expensive than you expect. You need an upper reference point.
• Day 3: Rank the replies by quality of questions, not by price.
• Day 4: Thirty-minute video call with the top two, using the question table in section 5.
• Day 5: Open their work on your phone, test the speed, and ask for one reference you can actually speak to.
• Day 6: Request a detailed written proposal with a scope document and a payment schedule.
• Day 7: Review the contract, fix the ownership and handover clauses, then sign and pay the deposit through a traceable channel.

Seven days of patience usually saves months of regret. The stalled projects that reach me almost all began with a same-day decision based on the cheapest bid. For the broader hiring process itself, read how to hire a web developer; if your project is specifically on Laravel, start at hire a Laravel developer.

13. Bottom Line

Choosing a developer is a commercial decision, not a technical one. You are not buying code. You are buying a capacity to deliver and to keep delivering. Evidence of that capacity always exists before payment: in the quality of their questions, in live work you can open yourself, and in their willingness to sign a contract that defines ownership and handover.

Anyone who refuses one of those three has told you everything you need to know.

If you are close to signing and want a neutral second opinion on the proposal in front of you — or a fixed-fee quote to compare it against — get in touch. The first consultation is free, I reply within 24 hours, and I'll tell you plainly if your project doesn't need me.