Why choosing badly is expensive

Most bad software projects don't fail loudly — they die slowly. Six months in, the demo still isn't shippable, the invoice list keeps growing, and the agency has stopped answering calls on Fridays. By the time you start over, you've lost the budget and often the internal credibility to try again.

The good news: the difference between a strong software house and a weak one is visible before you sign anything. You just need to know where to look. This checklist comes from sitting on both sides of the table — building products for Egyptian companies since 2019, and inheriting the rescue projects of those that went wrong.

The checklist: 22 questions to ask before you sign

• 1. Can you show me three projects similar to mine, with a client I can call?

• 2. Who exactly will work on my project — names, seniority, and are they employees or freelancers?

• 3. What's fixed-price vs time-and-materials, and what happens when scope changes?

• 4. Who owns the code, design files and infrastructure accounts — in writing?

• 5. Where does the code live from day one (your repo or mine)?

• 6. How often will I see a working build? (Weekly or better. 'At the end' is a red flag.)

• 7. What's your process for bugs found after launch, and for how long is it free?

• 8. What happens if we pause the project for two months?

• 9. Which parts of my project will you outsource?

• 10. Can I see a sample statement of work and contract before paying anything?

• 11. What's your policy on deadlines you miss?

• 12. How do you handle Egyptian e-invoicing / tax authority requirements if relevant?

• 13. Is the interface Arabic-ready with proper RTL, and bilingual content?

• 14. What security practices do you follow — backups, encryption, access control?

• 15. What does hosting cost after launch, and who controls the accounts?

• 16. How do you hand over documentation and train my team?

• 17. What's the smallest first milestone we could ship in 4–6 weeks?

• 18. Can you walk me through a project that went wrong and what you did?

• 19. Who is my single point of contact, and what's their response-time promise?

• 20. What do you refuse to build, and why?

• 21. What analytics will be in the product so we can measure success?

• 22. If we part ways mid-project, what exactly do I walk away with?

Red flags that should end the conversation

A quote that arrives the same day as your first call (nobody understood your scope that fast). A refusal to put code ownership in the contract. No named team. A 100% upfront payment demand. A portfolio of only landing pages when you need a system. And the quiet one: no questions from them about your business — great software houses interview you as hard as you interview them.

Green flags

They push back on scope to protect your budget. They propose starting with a smaller milestone. They talk comfortably about projects that failed and what they learned. They give you a realistic timeline with a range, not a suspiciously exact date. And their existing clients answer the phone when you call for references — that last one settles more doubts than any proposal.

The bottom line

A software house is a long-term partner, not a vendor. The average business system lives 5–7 years — longer than most supplier relationships. Choose the team you'd still want to call in year three.

If you want to pressure-test us against this checklist, book a free consultation — we'll answer all 22 questions with receipts. And if we're not the right fit for your project, we'll tell you who is.