How to choose a software house in Egypt or the Gulf — and what to ask before you sign

The short answer: choose on evidence, not on the pitch. Live work like yours that you can open, a past client you can call, a written scope before a fixed price, and the code and accounts in your name from day one.

We are a software house ourselves, so read this knowing that. We have tried to write the checklist we would want a client to use on us.

1. Start with shipped work, not the portfolio page

A portfolio page shows what a company wants you to see. Ask for things you can open yourself: an app in the App Store or Google Play, a live website, a system you can see in a demo account. Then ask what, exactly, they built — design, app, backend, all of it — and what was done by someone else.

2. Talk to a past client — ideally about a project that went wrong

Every project hits a problem. What you want to know is what the company did when it happened: did they say so early, absorb their own mistakes, and put a plan in writing? Ask for a reference and ask that question directly. Reviews on independent sites such as Clutch or Google help, but one honest phone call helps more.

3. Read the quote for what it assumes

A fixed price given in the first meeting, for a project nobody has scoped yet, is a guess. The risk doesn’t disappear — it comes back later as change requests, or as corners cut quietly to protect the margin. A more honest structure is a short paid discovery phase, then a fixed price for a defined scope, one phase at a time.

4. Ask who owns what — and get it in the contract

The code repository, the cloud account, the App Store and Google Play listings, the domain and the documentation should be in your name from the start — not transferred “at the end”. If a company hosts your product on its own account, leaving it later becomes a negotiation.

5. Treat Arabic as a test, not a checkbox

Almost everyone in the region says they support Arabic. Ask to see an Arabic screen they have shipped. Is the layout properly right-to-left? Do phone numbers and prices sit correctly inside Arabic sentences? Is the Arabic written for the reader, or translated from English? You will see the difference in ten seconds.

6. Ask how the work runs week to week

You should see working software regularly — every week or two — and be able to test it on your own phone, not only read status reports. Ask who your day-to-day contact is, who actually writes the code, and how a change request is handled and priced.

7. Ask what happens after launch

Apps need updates for new phone operating systems, libraries need patching and small features never stop. Ask what support looks like, how fast they respond, and — just as important — what a clean handover to your own team or another company would include.

Red flags

• A price before they have asked you any real questions.
• No live work you can open yourself.
• Reluctance to put ownership of code and accounts in the contract.
• Everything is “possible” and nothing has a trade-off.
• You can’t find out who will actually build it.
• No Arabic sample, or an Arabic sample that reads like a translation.

Questions to ask before you sign

1. Which live product you built is closest to ours, and can we open it?
2. Can we speak to that client?
3. What exactly did you build, and what did someone else build?
4. What do you need to know before you can give a fixed price?
5. What does discovery produce, and is it ours if we don’t continue?
6. Whose name are the repository, cloud account and store listings in?
7. How often will we see working software?
8. Who is our day-to-day contact, and who writes the code?
9. How are change requests handled and priced?
10. What does support after launch look like, and what would a handover include?