Use the questions to clarify the work
A discovery conversation should make the proposed product easier to define and price. Bring the main workflow, the people involved and any systems you already use. The questions below help turn a broad idea into responsibilities and decisions that can go into a proposal.
Ask for concrete answers relevant to your project. Some answers will need investigation. It is useful to know which assumption is unresolved, who will check it and how it could affect the scope.
1. What is included in the first release?
Ask the team to describe the primary user journey from start to finish. Include the administrator’s work and the cases where something goes wrong. A booking workflow, for example, may need approval, cancellation and notifications as well as a form.
A useful answer names the included roles, platforms and acceptance criteria. It should also identify what is deferred. If “MVP” appears in the proposal, ask which exact tasks users can complete in that version.
2. Which existing systems will it depend on?
List the payment provider, business software, data source and external APIs the product may use. Ask who supplies access and documentation, whether a test environment exists and what needs investigation.
A useful answer separates known integrations from assumptions. It explains what happens if a provider lacks a required endpoint or access takes longer than expected. Those dependencies can affect both the design and delivery order.
3. Why this technology for this product?
Ask how the proposed stack supports the workflow, team and expected maintenance. A Flutter app, native Android application and browser-based tool involve different delivery work. The recommendation should explain the fit and the trade-offs relevant to your requirements.
For a connected product, ask which system owns each record. Orders, employee permissions and payment state should have defined responsibilities. You do not need a detailed architecture specification at the first meeting, but you should understand the main boundaries.
4. How will progress and changes be reviewed?
Ask when you will see designs and working builds, who approves them and how feedback is recorded. Find out which decisions require your involvement. A useful plan includes review points and the access or content needed from your side.
Also ask how a change affects the estimate. The process should distinguish a defect against the agreed scope from a new requirement. Written approval makes the effect on delivery and budget easier for both sides to follow.
5. How will quality be assessed?
Ask the team to identify the critical flows: account access, purchases, record changes or other tasks on which the business depends. Discuss devices, browsers, permissions and unsuccessful requests. The answer should connect testing to the product’s risks.
Acceptance needs an agreed meaning. A demonstration of the main screens may be useful, but it does not cover every workflow. Ask what will be checked, what you will review and how unresolved issues are handled before release.
6. Who owns code and accounts?
Discuss the source repository, hosting, app-store accounts, domain, paid services and administrator access. Ask what you receive at handover and who is responsible for recurring charges. Clarify any third-party code or licences that affect future use.
Ask for a practical account and access plan. Your team should know where the current source and release information will be, and how access changes when people leave.
7. What does the estimate exclude?
| Cost area | Ask whether it is included |
|---|---|
| Development | Design, backend, admin tools, migration and launch work. |
| External services | Hosting, messaging, maps, payment providers and store accounts. |
| Business input | Copy, product information, translations and approvals. |
| After launch | Defect coverage, maintenance and later features. |
Ask about taxes, payment milestones and assumptions as well. Use the app cost guide for planning context, then compare quotations against the same written scope.
8. What happens after launch?
Ask how issues are reported, who can deploy a fix and what response arrangements are included. An app may need a store review after an update; a backend may need a different release process. Those responsibilities should be part of the support discussion.
Find out how new work is estimated and how the current version can be handed to another team. Documentation, account access and a reproducible release process are useful deliverables to name in the agreement.
Take away a decision record
After the conversation, summarise the agreed scope, open questions, assumptions and owners. Share it with the team before approving a proposal. This avoids treating an unresolved idea as an agreed feature.
For partner selection, read how to choose an app development company. If you are ready to discuss the product itself, explore Cloudemy’s software services or send a project brief.