The 12 Questions We Need to Estimate Your App Accurately

Almost every painful software project starts the same way: a vague brief, an optimistic number, and a timeline that quietly doubles. The fix is not a better guess — it is better inputs. A reliable estimate is only as good as the questions answered before anyone writes code. This guide walks through the twelve questions we ask founders and SMB teams across Egypt and the GCC before quoting a timeline or a budget, why each one moves the number, and how a clear scoping conversation protects your runway instead of draining it.

Why estimates go wrong (and why questions fix them)

When a quote turns out to be half the real cost, the culprit is rarely bad coding — it is unspoken assumptions. The client pictured ten screens; the team scoped six. The client assumed payments, push notifications, and an admin panel were "obvious"; the proposal never mentioned them. Each gap becomes a change request, and change requests are where budgets and friendships die.

A structured estimate flips this. Instead of pricing a wish, we price a defined scope, attach a range to each unknown, and name the risks out loud. The twelve questions below exist to surface exactly the assumptions that usually stay hidden until it is expensive to discover them. We group them into five buckets: users, workflows, data, integrations, and constraints.

Users — who is this for, and how many?

The first thing that shapes effort is who logs in and what they are allowed to do.

• 1. Who are your user types? A single consumer app is one thing; a platform with customers, staff, and admins each seeing a different view is three apps in a trench coat. Roles and permissions are one of the biggest hidden cost drivers.
• 2. How will people sign in? Email and password is simple. Social login, phone-OTP (common and often expected in Egypt and the Gulf), single sign-on for business clients, or KYC-style verification each add real work.
• 3. What scale do you expect at launch and in year one? An MVP for the first 500 users is architected differently from something that must absorb a national campaign on day one. We do not over-build, but we do need to know which problem we are solving.

Workflows — what does the app actually do?

Features are easy to list; workflows are where the effort lives. A "booking" is not one feature — it is searching, selecting, paying, confirming, rescheduling, cancelling, and refunding.

• 4. What is the core job the app must do end to end? Describe the single most important flow as a story, from the user's first tap to a finished outcome. That story is the spine of the estimate.
• 5. Do you need an admin or back-office panel? Almost every real product does — someone has to manage content, users, orders, or disputes. Teams routinely forget to scope it, and it is often 20–40% of the build.
• 6. What needs to happen in real time vs. later? Live chat, live tracking, and instant notifications cost more than overnight reports. Knowing what truly must be instant keeps the architecture (and the bill) honest.

Data — what are you storing, and how sensitive is it?

• 7. What are the main things the app keeps track of? List your core entities — users, products, orders, appointments, documents. The shape and relationships of your data drive a large share of the back-end effort.
• 8. How sensitive or regulated is the data? Health records, financial data, or government IDs raise the bar for security, compliance, and audit trails. Gulf clients in particular often need data residency and clear privacy handling; this is a scoping question, not an afterthought.

Integrations — what must it talk to?

Integrations are the most underestimated line in any estimate because each one is a small project with its own documentation, edge cases, and failure modes.

• 9. Which payment methods do you need? The mix differs sharply by market — Egyptian apps often need local gateways, wallets, and cash-on-delivery logic, while Saudi and UAE products may prioritize regional cards, Apple Pay, and Gulf processors. Each gateway is its own integration.
• 10. What third-party services must it connect to? Maps, SMS/WhatsApp, email, accounting, CRM, shipping, analytics — name them now. Two integrations versus eight is a completely different timeline.

Constraints — the boundaries around the build

• 11. What are your platform and deadline? Web, iOS, Android, or all of them? A hard launch date (Ramadan, a funding milestone, an event) changes how we sequence work and what ships in v1.
• 12. What is your budget range and content readiness? A range — not a single number — lets us right-size scope honestly. And content (copy, images, logos, legal text) is the silent timeline-killer: development rarely waits on developers, it waits on content.

What your answers turn into

Once these twelve are answered, the fog clears and the estimate becomes a document you can actually use, not a number you have to trust on faith.

Deliverable	What it gives you
Scope outline	A written list of what is in v1 and, just as importantly, what is deliberately out.
Timeline range	A realistic window (e.g. 6–10 weeks) tied to milestones, not a fragile single date.
Risk list + mitigation	The unknowns named up front, each with a plan — so surprises become decisions, not emergencies.
Phasing recommendation	What to ship first to learn fastest, and what can safely wait for v2.

This is why a 30-minute scoping call almost always saves more money than it costs: it converts a guess into a plan and a plan into a range you can budget against.

Egypt vs. the GCC: where the answers differ

The twelve questions are the same everywhere, but the answers carry different weight by market. In Egypt, founders are more price-sensitive and WhatsApp-led, local payment rails and cash-on-delivery logic show up often, and an MVP-first, phased approach fits tight budgets well. In Saudi Arabia and the UAE, buyers tend to weight trust, polish, Arabic-first UX, data residency, and compliance more heavily, and timelines are frequently tied to events or funding milestones in Riyadh or Dubai. The same disciplined estimate serves both — what changes is which integrations, which compliance answers, and which contact channel come first.

Frequently asked questions

Can you give me a price before I answer all twelve questions?

We can give a broad range to confirm we are in the same ballpark, but a number you can actually budget against needs the inputs above. Quoting a precise figure on a vague brief is how projects end up costing double — the honest answer early is a range, then a firm scope once the questions are answered.

What if I do not know the answers yet?

That is normal, and it is exactly what a short discovery conversation is for. "I am not sure" is a useful answer — it tells us where the risk lives so we can phase the build to reduce it. You do not need a perfect spec; you need to be honest about what is decided and what is still open.

How accurate is the final estimate?

With all twelve answered, a fixed, well-defined MVP can be quoted tightly. Where requirements are still being discovered, a time-and-materials or phased model is often safer and cheaper in the long run. Here is how to choose between the two contract models.

Will answering these questions narrow my scope too much?

The goal is the opposite — to protect your budget so the features that matter get built well, instead of spreading it thin across everything at once. Defining a tight v1 is how good products get to market; the rest goes into a clear backlog. See our MVP scope template for separating must-haves from nice-to-haves.

Next step

If you want a timeline and budget you can actually plan around, the fastest path is a short scoping conversation built on these twelve questions. See how we scope and ship products in MVP & Product Delivery, learn to reduce app cost without killing quality, or send us a message and we will turn your idea into a clear scope and an honest range.