Engineering

How to Choose a Web Development Company in Egypt

By Clasify Team · 2026-09-05 · 8 min read

Search for web development companies in Egypt and the first page is almost entirely directories — Clutch, DesignRush, TechBehemoths, The Manifest — each listing hundreds of firms sorted by review count. Those lists do one job well: they confirm a company exists and has clients who agreed to be contacted. What they cannot tell you is whether a particular team can build the thing you need, because nobody asked them what you need.

This is about the other half of that problem: the questions to ask a shortlist, what a good answer sounds like, and which answers should end the conversation. We are a small engineering team in Giza. We take client builds, and we also run a product of our own — which is where most of what follows was learned the expensive way, on our own money rather than a client's.

Name which of three jobs this actually is

"Web development company" covers three different trades, and confusing them is the most common reason a project goes wrong before anyone writes a line of code.

A marketing website: a handful of pages, a contact form, a CMS the marketing team can edit. Design and copy are the hard parts. The engineering is not.
A content or commerce site: many pages, a catalogue, search, a checkout. The hard parts are structure, performance and the payment path.
A web application: accounts, roles, permissions, workflow, reports, integrations. The hard parts are the data model and the rules the server has to enforce. Design still matters, but it is not what decides whether the thing survives its second year.

Most agencies list all three as service lines. Ask which one they do most, and ask to see it. A portfolio of fifteen beautiful marketing sites is a strong signal for the first job and a weak one for the third — and that runs both ways, so this is a matching exercise, not a ranking.

If your project has user roles, approvals, or a number that finance is going to rely on, you are buying software. Shop for it the way you would shop for software.

Ask what happens the day after launch

Almost every proposal describes the build. The build is the easy half. Ask these four instead, and listen for whether the answers sound rehearsed or lived:

How do you deploy a change, and how do you undo one?
What happens when the database schema has to change after real customers have data in it?
Who is alerted when the site is down at 3am, and what do they do?
Are backups restored and checked, or only configured?

That last one is the most revealing, because "configured" is the usual answer and it is the wrong one. A backup nobody has ever restored is a hypothesis, not a backup. Ours ran dead for the better part of a month — the schedule was still there, the job had simply stopped working, and nothing complained. We found it because someone went looking, not because anything told us. We now restore a backup and check it rather than trusting a green tick, and a supplier who has never had that happen to them is usually a supplier who has not looked.

Ask who owns the code, the servers and the domain

The answer you want is boring: the repository is in your account from the first commit, the infrastructure runs in accounts billed to you, and the domain and DNS are registered to your company.

This matters more in Egypt than the equivalent conversation elsewhere, because cloud bills arrive in dollars and Egyptian budgets do not. It is genuinely convenient when an agency puts the hosting on its own card. It also means the day you want to leave, your site, your database and your domain are all sitting inside somebody else's account, and the conversation about leaving becomes a negotiation instead of a handover.

Ask the exit question outright: if we stopped working with you next month, what exactly would we receive, and how long would it take? A team that has thought about it will answer in specifics — repository, infrastructure, credentials, runbook, a walkthrough. A team that has not will tell you that clients never leave.

Ask how the site is going to be indexed

A large share of modern sites are single-page applications that ship an empty HTML shell and then draw the page with JavaScript. Search engines can often cope with that, and often do not. Either way you have made your ranking depend on someone else's rendering budget for no benefit you can point to.

Four questions cover it:

Does the server send HTML with the words already in it, or an empty shell?
Does every page get its own title, description and canonical URL?
Is there a generated sitemap, and does it list every real page?
What does a URL that does not exist return — a 404, or a 200 with an empty page?

That last one catches a defect almost nobody looks for. An application that answers 200 for a dead URL is telling search engines that thousands of nonexistent pages are real, and it quietly poisons the whole site. We found the same class of problem on our own site: the blog index was serving a document with no words and no links in it at all, which is not something any design review would ever surface, because in a browser it looked perfect.

You can test the first one yourself in ten seconds. Open a page they built, view the page source, and search it for a sentence you can see on screen. If the sentence is not in the source, the crawler did not get it on the first pass either.

Ask what "Arabic support" means to them

Almost every company in this market will say yes to Arabic. The question is what they mean by it. Real bilingual support is:

Layout, navigation and icons mirrored for right-to-left, not a stylesheet flip that leaves half the interface backwards.
All six Arabic plural forms, rather than a singular and a plural borrowed from English.
Dates, numbers and currency formatted per locale.
A separate URL per language with reciprocal hreflang, so each version can rank on its own.
Arabic that was written, not translated. The difference is invisible in a specification and obvious to your customers.

"We will add Arabic later" is the answer to watch for. Retrofitting right-to-left into a finished product is one of the most expensive changes there is — we did it to our own product once, which is exactly why it now goes in before the first screen.

Ask to see something running, not a deck

Screenshots prove someone had a design. Ask for a URL. Then spend fifteen minutes on it yourself, without them in the room: run it through PageSpeed Insights, open it on your phone, tab through a form with the keyboard, and if they claimed Arabic, switch the language and see what breaks.

This is the single highest-value hour in the whole selection process, and it costs nothing.

Judge the estimate by what it excludes

A quote with no exclusions list is not a quote, it is a hope. What you want to see in writing:

What is in version one, and what is deliberately left for later.
What is assumed to come from you: content, logos, access to third-party accounts, a merchant account for payments.
What is explicitly not included — data migration from the old system is the classic omission, and it is often the largest single task.
What support after launch costs, and what it covers.

Be careful with a fixed price on a vague brief. It looks like protection and it is the arrangement most likely to end badly for both sides: every clarification becomes a negotiation, and the cheapest way for the supplier to stay whole is to build the thinnest thing the wording allows.

What it costs, honestly

There is no useful rate card for this work and anyone who publishes one is quoting a different project than yours. The price is driven by five things: which of the three jobs it is, how many roles and rules the system has to enforce, how many external systems it talks to, whether it ships in two languages, and whether anybody is responsible for operating it after launch.

The practical move is to get three written scopes and compare the scopes rather than the totals. The lowest number is nearly always the smallest scope, and the difference usually turns up as change requests later.

Red flags worth walking away from

Cannot show you a live URL for anything they built.
Wants the domain or hosting in their own account "for convenience".
Treats performance and technical SEO as a paid add-on after launch rather than part of building the page.
Gives a fixed price on a one-paragraph brief without asking a single question.
No mention of tests, backups or rollback anywhere in the proposal.
Prices Arabic as translation.

What the directories of Egyptian web development companies are good for

Use Clutch, DesignRush or TechBehemoths for what they are good at: assembling a shortlist, checking a company is real, seeing roughly how big it is and how long it has existed. Then do the work above on three or four names, and ask each of them for a reference you can actually phone — ideally about a project that went badly, because how a team behaves when something breaks tells you more than a case study ever will.

Choosing well is mostly a matter of asking questions whose answers cannot be prepared in advance. Every one above qualifies.

If it is useful to see what these answers look like from a team that has to live with them, this is how we run a web build, how we work with Egyptian clients, and the product we built and still operate ourselves.

All articles