Most failed software projects don't fail because of weak engineers. They fail because expectations were never made explicit. The client pictured one thing, the vendor delivered another, and both believed they were right.
Working with clients in Iraq and internationally, we've noticed a pattern: the clients who ask the right questions in the first meeting are the ones who end up with a product they're happy with. So here are the seven questions that matter most. Ask them of us, or of anyone else you're considering.
1. Who owns the code and the IP after delivery?
This is the most consequential question, and the one clients ask least. Insist that the contract states explicitly that the source code, database, hosting accounts, and domain belong to you once payment is complete. Some vendors keep the code as leverage, which means you can't switch providers even when you want to.
2. What exactly does the price include — and what falls outside it?
A number on its own tells you nothing. Ask for a breakdown: Does it cover design? An admin dashboard? Both iOS and Android, or just one? First-year hosting? App store fees? Training for your team? The cheapest quote is often the most expensive one, because everything unlisted arrives later as a change order.
3. How will I track progress before delivery?
You should see a working build at least every two weeks — not a written status report. A project where the team disappears for three months and returns with "the final product" is a project you'll be rebuilding.
4. What happens after launch?
Ask about the warranty period and what it covers. Get a clear distinction in writing between a bug (fixed free under warranty) and a new feature (paid work). Ask about the annual maintenance contract and its cost now, not twelve months from now.
5. Who will actually work on my project?
Sometimes a senior engineer attends the pitch and a junior inherits the work. Ask about the size and seniority of the team assigned to you, and who your direct point of contact will be for the duration.
6. How do you handle change requests?
Scope changes are normal — you'll request them yourself. What matters is that the process is defined upfront: how is a change estimated, and how does it affect timeline and cost? A vendor who says "sure, any change is free" either doesn't understand the work or will quietly recover the cost in quality.
7. Can you show me something comparable — and can I speak to a past client?
A portfolio shows you the finished surface. A past client tells you what the surface hides: Did they hit the deadline? How did they behave when something broke? Do they still answer the phone after launch? A confident vendor won't hesitate.
Red flags
A very low price offered with no questions asked. Anyone quoting a final number before understanding your requirements hasn't understood your project.
An implausibly short timeline. "A complete system in one week" is a promise you pay for later.
Reluctance to put everything in the contract. Verbal agreements are worth nothing in a dispute.
Vagueness about ownership or what happens to the code.
The bottom line
A software project isn't a purchase that ends at delivery — it's a relationship that runs for years. The right partner is the one who welcomes these questions and answers them plainly.
[CTA] If you have a project in mind, book a free 30-minute consultation. We'll talk through your idea and give you an honest view of scope, timeline, and cost — even if you decide not to work with us.
