Questions to ask before signing a mobile app agency contract

A pre-contract checklist for founders and agencies to uncover scope, ownership, native risk, release support, and handover gaps.

A mobile app contract should clarify risk before it prices effort

A proposal can look professional and still leave the important mobile risks undefined. The scope may list screens. The timeline may show phases. The cost may feel precise. But if ownership, native constraints, release support, QA, and handover are vague, the contract may only move uncertainty into delivery.

Before signing a mobile app agency contract, ask questions that expose how the project will survive real launch pressure.

This checklist is useful for founders buying a V1, product teams extending capacity, and agencies subcontracting mobile delivery without a permanent app bench.

1. What is the smallest launchable version?

Ask the agency to define the V1 in terms of launch evidence, not screen count.

Good answers mention:

• the core user loop;
• what can be cut;
• what must exist for store submission;
• which assumptions need validation;
• what is explicitly out of scope.

Weak answers describe every requested feature as required. If nothing can be cut, the contract is not scoped. It is a wish list with a price.

2. Who owns native risk?

Even React Native apps can depend on native behavior: camera, notifications, maps, payments, location, files, Bluetooth, widgets, background tasks, SDKs, signing, and store review.

Ask:

• which features require native module review;
• who can debug iOS and Android issues;
• whether Expo managed, prebuild, or bare workflow is expected;
• what happens if a package breaks release;
• whether native work changes price or timeline.

If native risk is treated as “development detail,” it may become a surprise cost later.

3. How often will we see the app running on device?

Design reviews are not enough. A mobile project should show playable progress early and often.

Ask for the demo rhythm:

• weekly build or screen recording;
• device testing status;
• what is ready to test;
• what is blocked;
• what changed since the last demo;
• which decisions are needed.

A project that stays in Figma and tickets for too long can hide release risk until it is expensive.

4. What does QA include?

QA should not be a vague line item.

Ask whether it covers:

• iOS and Android devices;
• auth and account flows;
• permission denial;
• network failures;
• empty states;
• store metadata;
• regression checks;
• native module behavior;
• support/contact paths.

If the agency says QA happens at the end, ask how scope will be cut when QA reveals issues.

5. What happens at store submission?

Store submission is part of mobile delivery, not a small afterthought.

Ask:

• who prepares screenshots and metadata;
• who manages TestFlight / internal testing;
• who handles App Store Connect and Play Console tasks;
• what happens if Apple or Google rejects the app;
• whether privacy labels, account deletion, or permission copy are included;
• whether post-submission support is priced.

A V1 that cannot reach the stores is not store-ready, even if the feature backlog is complete.

6. Who owns the code after launch?

Handover should be defined before the build starts.

Ask for:

• repository ownership;
• setup documentation;
• release process;
• native module notes;
• environment variables and secrets handling;
• known risks;
• V2 backlog;
• transition session for your hire or team.

This is especially important if you are hiring mobile talent or using an agency as a bridge.

7. What would make the agency say no?

This is the most revealing question. A serious partner should know their no-fit conditions.

Examples:

• unrealistic budget;
• refusal to cut scope;
• missing backend ownership;
• native risk outside the timeline;
• no decision-maker availability;
• enterprise support expectations beyond the model.

If the agency says yes to everything, they may be avoiding the real conversation.

Use the answers to choose the model

The contract should make the delivery model obvious. If you need broad brand and marketing support, a full agency may be right. If you need concentrated mobile launch risk handled by a senior partner, a Hong Kong mobile delivery model may be cleaner.

Do not sign only because the number is acceptable. Sign because the contract explains how the app gets to launch, who owns the risk, and what happens when reality forces a decision.