How to Choose a Software Company in Egypt: 7 Things to Settle Before You Sign (2026)

Choosing a web development company in Egypt does not end when you like somebody's portfolio. The harder part comes next: opening the final proposal and the draft contract and deciding to sign. Most trouble we hear from clients who came to us to rescue a stalled project did not start with a bad company. It started with clauses nobody read.

This guide is the companion to our complete guide to choosing the best software company in Egypt, which covers building a shortlist. Here we take the next stage: seven things you settle before signing — scope, code ownership, account ownership, handover, comparing proposals, timeline realism, and payment milestones.

We wrote it at Jad Digital from projects we delivered and projects we rebuilt after somebody else. The goal: walk into the signing meeting knowing what to look for, and which sentence to insist on.

A good contract begins not with legal boilerplate but with the statement of work. That annex is the project on paper, and anything not in it is not agreed, whatever was said in meetings.

What it must contain:

A detailed scope annex is the difference between a calm conversation in week six and a chain of angry messages.

• Every page or screen listed by name, the number of languages, and who supplies the content.
• Integrations named: a payment gateway such as Fawry or Paymob, a courier, an accounting system, WhatsApp, ad tracking.
• What is explicitly excluded. The most important line, and the one most often missing.
• Acceptance criteria. "Works on the last two versions of Chrome and Safari, mobile and desktop, and passes the attached test scenarios" is measurable. "Professional quality" is not.
• A change-request mechanism: how a request is submitted, who estimates it, how it moves the timeline.
• A warranty period covering bugs inside the agreed scope, excluding new features.
• Termination and exit clauses: what happens if either side stops, and what is handed over.
• An NDA covering your data and your customers' data, surviving the engagement.

"The code is yours" gets said in every meeting and means nothing until written down. The wording that protects you says everything produced for the project — source code, designs, source files, database, documentation — becomes solely yours once each phase is paid, with an explicit assignment of intellectual property to your legal entity.

Three points usually get skipped:

A company that ties code delivery to later conditions, or refuses a repository in your name, is holding leverage it does not need.

• Third-party components. Every project uses libraries, templates, fonts and images. Ask for the licence list, and make sure commercial ones — a paid Arabic typeface, a template, a stock image — are bought in your name.
• The agency's internal tooling. Keeping reusable components is normal, but you need a perpetual, irrevocable licence to use and modify them in your project.
• Access during the build, not only after. Insist the repository sits in an account your company owns from day one, with the agency as a member. If the relationship ends mid-project, you still own what was built.

Every account carrying your company's identity should be registered with your company's email, the agency added as administrator or developer — never owner.

Check this list line by line before you sign:

Then add one sentence: the agency transfers full ownership of the accounts in the handover annex within a defined period after launch.

• The domain, registered to your legal entity and its email, with your own registrar access.
• Hosting on your account, or with a documented, unconditional right of transfer.
• DNS control, because whoever changes the records controls your email and your site.
• Google Analytics and Search Console on a company account where you are Owner, not a user.
• Your Google Business Profile, a marketing asset independent of the website.
• App-store developer accounts in the company's name; moving apps later is painful.
• The payment-gateway merchant account in your company's name and commercial registration, so collections land in your account.

A project does not end when the site goes live. It ends when another developer could pick it up. Make the handover checklist a signed annex, not a last-day WhatsApp message.

The checklist to demand:

A simple test: ask the company to assume it will never work with you again, and hand over enough for a new developer to start tomorrow. How they react tells you more than any reference call.

• Owner access to the repository with full commit history, not a final zip file.
• Credentials delivered securely: admin panel, database, hosting, mail.
• A two-page deployment document: how the build is produced, where it is deployed, which environment variables it needs.
• A complete backup of database and files, plus an automatic backup schedule.
• A short admin-panel guide, ideally with a screen recording.
• A list of external services and their renewal dates.

The most expensive mistake here is comparing three proposals that describe three different projects, then picking the lowest. A fair comparison takes two steps.

First, normalise the scope. Send all three the same brief. When the proposals arrive, list every item any of them mentioned, then ask each company plainly: inside your price or outside it? You will find one has no Arabic content, another excludes the payment gateway, and a third bills translation, imagery and device testing separately.

Second, build a comparison sheet with identical rows for all three: scope items, technology, languages, phased timeline, team composition and allocation, revision rounds, post-launch support, ownership terms, change requests. Identical rows make differences surface instead of hiding behind wording.

What does a suspiciously low proposal leave out in silence? Cross-browser and device testing; a genuine, indexable Arabic version instead of a translation loaded by JavaScript — the difference between appearing in Arabic search and not, as we explain in why your website loses customers without a real Arabic version; speed work; analytics; the warranty; revision rounds; content migration.

That is why the lowest proposal ends up the highest. Every missing item returns as a change request, which costs more mid-build than it would have inside the original scope, because it reopens design, code and testing already closed. The factors that move a price are in website design cost in Egypt.

"Your website will be ready in two weeks" is sold often and delivered rarely. A realistic plan admits coding is not the only thing consuming time.

What actually eats the schedule:

Read the plan looking for slack. A schedule with no time for review and testing is not optimistic, it is late already. Ask for a clause saying either side's delay stops the clock rather than becoming a dispute. In our experience the client's content and approvals cause most overruns.

• Content. Copy, photography and product data are the top cause of delay in the Egyptian market. Put your own content dates in the contract.
• Approvals. Every review round passing through several people adds days. Name one person with final sign-off.
• Integrations and third parties. Activating a merchant account, connecting a courier, an app-store review: durations nobody on the build team controls.
• Revision cycles. Two included rounds is one thing; open-ended rounds are another.

Milestone structure is risk management for both sides. Every milestone should map to a specific, accepted deliverable, not to the passing of days.

The milestones that make sense:

Tie each to a written acceptance criterion and a review window, with a clear rule: no response inside the window means accepted. That protects the agency from limbo and you from paying before you have tried anything.

• Kickoff, after the contract and scope annex are signed and brand materials handed over.
• Design approval for all key screens in Arabic and English.
• Development milestones tied to modules you can try on a staging link, not a completion percentage nobody can verify.
• User acceptance testing, run by your team against scenarios written in advance.
• Launch, after acceptance passes and accounts and documentation are handed over.
• End of warranty, after post-launch issues are closed.

The proposals you receive mirror what you sent. Two careful pages save weeks of back and forth and make proposals comparable at all.

Put in the brief:

Never ask for a price before a discovery call: a company that quotes before it understands will either raise the number later or quietly shrink the scope. If you are comparing web design companies in Cairo, we cover the local differences in how to choose a web design company in Cairo.

• Your business and target market: Egypt, the Gulf, or both.
• The commercial goal in one measurable sentence: online orders, qualified inquiries, fewer support calls.
• The pages or screens you imagine.
• Languages, and who supplies content and translation.
• Required integrations, named.
• Who provides photography and brand assets, and whether a brand guide exists.
• Your target date and the reason: an exhibition, a season, a launch.
• Two or three sites you like, and what you like about each.
• What the proposal should contain: itemised scope, phases with dates, team, ownership terms, post-launch support.

A distribution company wanted to replace a slow, dated website. Reviewing the accounts revealed the domain registered to the previous agency under its own email, hosting on that agency's account, and nobody inside the company owning the analytics property. The first step was not design but recovering ownership: producing the commercial registration, asking the registrar to transfer the domain, creating hosting and analytics in the company's name. Only then did the build start, with a clause that every new account opens with the company's email. The lesson: audit account ownership before you write your brief — recovering it can take longer than building the site.

The firm received three proposals that looked far apart. Once the scope was normalised, the lowest excluded Arabic as a separate indexable version, excluded legal proofreading, and allowed one revision round. Once those were added, two proposals converged and one real difference remained: team composition and warranty length. The choice became a conscious decision, not a number comparison. Proposals differ by scope long before they differ by price.

• Refusing to register the domain or repository in your name, or making code delivery conditional.
• A contract with no scope annex, or a two-line quote with one number.
• No written acceptance criteria, replaced by phrases like "high quality".
• Pressure to sign today for a discount that expires tomorrow.
• Refusing to define a warranty period.
• Silence on change requests, or an estimate "to be determined".
• A promise of first position on Google within weeks. Nobody can guarantee rankings; the honest method is in our SEO guide for business owners.
• Declining to name the project manager or describe how progress is tracked.

• Who owns the code, designs and source files once each phase is paid, and where does the contract say so?
• Which account will the repository live in, and when do I get owner access?
• Which items are explicitly excluded?
• What are the acceptance criteria, and who signs off?
• How many revision rounds are included, and what then?
• How long is the warranty, and what does it cover?
• What do you need from me and when, and what if I am late?
• Who will actually work on the project, at what allocation?
• What happens if we end the engagement halfway, and what do I receive?

The choice between web development companies in Egypt is settled on paper before it is settled in code. A clear scope annex, written ownership of code and accounts, a handover checklist, a fair comparison of proposals, a schedule with slack, milestones tied to acceptance: six things that turn the rest into detail. See how we work in web development, and for the wider picture start from the complete guide to choosing a software company.