Ask to see how a candidate handles a failed payment, a lost connection, or an app upgrade, not only its best-looking screens. Those examples help show how the team thinks about the product your customers will actually use.
A strong selection process gives every candidate the same problem brief and asks for comparable evidence. It does not depend on an unverifiable claim to be the best, cheapest, fastest, or highest quality.
Related service: Android & iOS Application development- 01Create a one-page problem, user, journey, system, and constraint brief.
- 02Shortlist teams with relevant product and technical evidence.
- 03Run the same discovery and risk scenario with every candidate.
- 04Score architecture, security, QA, delivery, ownership, and support separately.
- 05Normalize scope, assumptions, exclusions, team roles, and commercial terms.
- 06Verify access, transition, and acceptance conditions before appointment.
SECTION 01
Give every candidate the same selection brief
Describe the business outcome, target users, current workaround, critical launch journey, desired platforms, required device features, systems and data, offline needs, privacy or compliance constraints, timing driver, internal decision owners, and known unknowns. Label assumptions; do not ask vendors to infer the entire product from a slogan.
Ask candidates to respond with questions, risks, proposed validation, delivery stages, roles, deliverables, agreed test results, assumptions, exclusions, and ownership. A useful early response narrows uncertainty instead of promising a fixed outcome before inspecting the difficult parts.
SECTION 02
Inspect relevant evidence without demanding confidential work
A portfolio proves that screens exist; it does not automatically prove who built the backend, how security was handled, whether the team supported launch, or what outcome was achieved. Ask the candidate to explain an authorized project or sanitized example: problem, constraints, role, architecture, hardest trade-off, quality evidence, release, and ongoing ownership.
For your project, request sample artifacts at an appropriate depth: discovery questions, a journey map, architecture decision record, API example, test strategy, risk register, release checklist, or support runbook. Do not ask for another client's source code or confidential information. Evaluate the method and clarity.
Product evidence
Can the team turn outcomes and user context into prioritized, testable journeys?
Technical evidence
Can it explain client, backend, data, integration, security, and failure boundaries?
Quality evidence
Does it define devices, lifecycle states, accessibility, security, and release acceptance?
Operational evidence
Can it show how monitoring, support, incidents, updates, and transition are owned?
SECTION 03
Use one difficult scenario to test reasoning
Choose a scenario central to your app: a field worker completes a job offline and reconnects; a customer retries a payment after a timeout; a user changes devices during account recovery; or a camera upload is interrupted. Ask each candidate to map states, data ownership, permissions, duplicate prevention, user feedback, observability, recovery, and tests.
There may be several valid solutions. Score whether the team identifies missing information, explains trade-offs, separates assumptions from facts, and proposes evidence. Be cautious when a candidate names a framework or promises reuse before examining the platform-dependent path.
SECTION 04
Score the same dimensions before reviewing price
Assign weights before final presentations so a polished pitch does not redefine what matters. Score each candidate from 0 to 2: no evidence, partial evidence or material risk, and clear relevant evidence. Attach notes and mark any critical zero that disqualifies a proposal regardless of total.
The score does not make the decision automatically. It creates a record for product, technical, security, operations, and commercial owners to discuss. Adjust the weights to the actual consequence of failure.
| Dimension | Suggested weight | Evidence to seek |
|---|---|---|
| Discovery and product framing | 5 | Questions, journey prioritization, assumptions, prototype and acceptance plan. |
| Architecture and backend | 5 | Platform trade-offs, system boundaries, API, data, offline, integration, and recovery reasoning. |
| Security and privacy | 5 | Threat-informed controls, data mapping, review standards, findings process, and declaration ownership. |
| QA and accessibility | 5 | Device matrix, lifecycle and network cases, automation, accessibility, security, and release evidence. |
| Delivery control | 4 | Named roles, review cadence, working increments, change control, risks, and acceptance. |
| Ownership and transition | 5 | Client-controlled assets, documentation, reproducible builds, access, and handover. |
| Operation and support | 4 | Monitoring, incident roles, updates, service expectations, maintenance, and exit. |
| Commercial clarity | 4 | Comparable scope, assumptions, exclusions, third-party cost, change, tax, and payment terms. |
SECTION 05
Resolve ownership and commercial boundaries
Confirm ownership and access for repositories, source code, design files, store accounts, signing materials, domains, cloud, databases, analytics, crash reporting, documentation, and third-party services. Define licensing for reused or third-party components and the process for exporting data and transitioning to another team.
Normalize proposals by deliverables, roles, stage, assumptions, exclusions, client responsibilities, third-party costs, acceptance, defects, changes, payment, cancellation, confidentiality, data handling, security reporting, maintenance, and support. Obtain appropriate legal advice for contracts; a technical buyer guide is not legal advice.
SECTION 06
Run final diligence and a bounded first stage
Verify the proposed people, availability, communication path, and who may be subcontracted. Check references only when legitimate and permitted, asking about the team's specific role, communication, risk handling, transition, and support rather than requesting confidential outcomes. Confirm business and security details through appropriate due diligence.
When major unknowns remain, appoint a bounded discovery or technical validation stage with explicit questions, deliverables, access, acceptance, and an exit. The output should be useful even if another team continues: prioritized scope, prototype evidence, architecture decisions, risks, and an updated delivery estimate.
- 01
Confirm the actual proposed team and responsibilities.
- 02
Verify authorized evidence and references at the relevant depth.
- 03
Resolve ownership, access, data, security, and transition terms.
- 04
Start with a decision-led stage when high-risk unknowns remain.
- 05
Approve the build only when scope and agreed test results are clear.
SECTION 07
Frequently asked questions
What should I ask a mobile app development company?
Ask how it will validate the riskiest user journey, choose architecture, protect data, handle offline and backend failures, test real devices and accessibility, manage stores, transfer ownership, and support the product after launch.
Should I choose the cheapest mobile app proposal?
Choose the proposal that offers the strongest fit and evidence for the required outcome at an acceptable total ownership cost. A low initial total may omit discovery, backend, QA, security, stores, monitoring, transition, or maintenance.
How do I verify a mobile developer's portfolio?
Ask what the team specifically owned, which constraints and trade-offs it handled, and what authorized artifacts or references support that account. Do not assume a listed product proves responsibility for its full design, backend, release, or outcome.
Who should own the app-store accounts and source code?
The client organization should generally control its business-critical accounts, repositories, signing recovery, cloud, data, and documentation, subject to the agreed contract and licensing. Define access and transition before work begins.
PRIMARY REFERENCES
Sources and further reading
These references cover the standards, platforms, or published prices discussed in the guide. Worked examples and checklists are our editorial guidance.
- Secure Software Development Framework (SP 800-218)National Institute of Standards and Technology
- OWASP Mobile Application Security Verification StandardOWASP Foundation
- Core app quality guidelinesAndroid Developers
- App Review GuidelinesApple Developer
- AccessibilityApple Developer
EDITORIAL METHOD
About this guide
We use AI to assist with drafting and editing. Catapult AI Work is responsible for the published content. Examples illustrate possible approaches; they are not client case studies unless identified as such.
Budget examples are not Catapult package prices. Check linked provider pages for current fees and plan limits before making a purchase.
Read the editorial policy