SOW template · Mobile
React Native App Statement of Work Template
A fixed-fee SOW for cross-platform iOS and Android builds that names every screen, caps device coverage, and keeps store submission and backend work from drifting into the base fee.
- 7
- Deliverables
- 7
- Exclusions
- 2 rounds
- Revision rule
Mobile · Exclusion rule
Design, development or hosting of backend services, databases or admin panels.
Ambiguity fix
The app will work on all modern phones.
The app is tested on iPhone 12 and newer running iOS 17 and 18, and on the four Android 12 to 15 reference devices in Appendix D.
Best for
Agencies shipping a first cross-platform app on React Native or Expo for a funded startup or a mid-market brand.
Mobile builds creep in three predictable places: screens nobody listed, devices nobody capped, and backend work that quietly becomes the agency's problem. This template pins each of those down. It lists screens by name, sets a supported OS and device matrix, separates the mobile client from any API work, and treats App Store and Google Play review cycles as a dependency the agency supports rather than guarantees.
Copy any clause block below into your own SOW. Numbers, appendix names and tools are placeholders drawn from a typical engagement, so replace them with the counts from your proposal. Every clause is written to be read by a client, not used against one.
Deliverables
Count everything. A deliverable a client cannot count is a deliverable a client can expand.
- 2.1A React Native (Expo managed workflow) application for iOS and Android built from one shared TypeScript codebase.
- 2.2The 14 screens listed in Appendix A, including onboarding, authentication, home feed, item detail, search, cart, checkout handoff, profile, settings and four empty or error states.
- 2.3Email and password authentication plus Sign in with Apple and Google Sign-In against the client's existing identity provider.
- 2.4Push notifications for the three notification types listed in Appendix B, delivered through Expo Notifications or Firebase Cloud Messaging.
- 2.5Integration with the client's documented REST API endpoints listed in Appendix C. The API itself is provided by the client.
- 2.6One production build per platform submitted to App Store Connect and Google Play Console under the client's developer accounts.
- 2.7A handover pack: repository access, environment variable inventory, build and release runbook, and a 60-minute recorded walkthrough.
Exclusions (out of scope)
Name what the engagement does not include. These are the lines your PMs will cite most often.
- 3.1Design, development or hosting of backend services, databases or admin panels.
- 3.2Tablet-optimized layouts, iPadOS split view, Apple Watch, Wear OS, widgets and App Clips.
- 3.3Offline-first data sync beyond caching the last loaded feed for read-only display.
- 3.4In-app purchases, subscriptions and any payment processing inside the app.
- 3.5Localization into languages other than US English, and right-to-left layout support.
- 3.6Ongoing maintenance, OS upgrade compatibility work and store listing optimization after the warranty period.
- 3.7Accessibility certification or third-party audit. The app targets the platform accessibility guidelines for listed screens only.
Revision limits
Each screen in Appendix A includes two rounds of consolidated revisions at the high-fidelity build stage. A round is one written list of changes delivered by the client's named product owner within five business days. Additional rounds, or changes to an approved screen after its round closes, are handled under the Change Control clause.
Acceptance criteria
Acceptance needs a measurable test and a window. Without both, delivery never formally ends.
- 5.1Each user story in Appendix A passes on the supported device matrix: iPhone 12 and newer on iOS 17 and 18, and Android 12 to 15 on the four reference devices listed in Appendix D.
- 5.2No open defects of severity 1 (crash or data loss) or severity 2 (core flow blocked) at release candidate.
- 5.3The client has ten business days to test each release candidate. Silence after ten business days counts as acceptance.
- 5.4Store rejection caused by app code is fixed at no charge. Rejection caused by client content, account status or policy questions is supported at the hourly rate.
Client assumptions & dependencies
Tie each dependency to a date so a late input has a known effect on the schedule.
- 6.1The client provides a stable staging API with documented endpoints and test credentials before the build phase begins.
- 6.2The client holds active Apple Developer and Google Play developer accounts and grants the agency access within five business days of kickoff.
- 6.3Final copy, imagery and legal text (privacy policy, terms) are delivered before the screen they appear on enters build.
- 6.4One product owner on the client side consolidates feedback and has authority to approve screens.
- 6.5Push notification content and triggers are defined by the client in writing before notification work starts.
Change control
Any request that adds a screen, a platform, a device class, an integration or a notification type, or that changes an approved screen, is a change. The agency will reply within two business days with a written change order stating the work, estimated hours, cost at the rates in Schedule 1 and schedule impact. No change work starts until the client's product owner approves the change order in writing. Approved changes adjust the fee and the timeline together.
These clauses are drafting guidance written from agency delivery practice. They are not legal advice. Agencies should have final MSAs and SOWs reviewed by counsel, especially for liability, IP, payment and termination terms, which this template does not cover.
Ambiguity check
The phrases that turn into free work, and what to write instead.
These are the vague lines we see most often in mobile SOWs. Each one sounds reasonable at signature and becomes a dispute three months later.
Before
The app will work on all modern phones.
Safer rewrite
The app is tested on iPhone 12 and newer running iOS 17 and 18, and on the four Android 12 to 15 reference devices in Appendix D.
Why it matters: "All modern phones" means thousands of Android models. A named matrix turns a promise into a test plan.
How to adapt it
7 steps from template to signed SOW.
A template saves drafting time. The protection comes from replacing every placeholder with the real counts, names and dates from your engagement.
- 1
Read the React Native App SOW end to end and mark every number, appendix and named tool that does not match your engagement.
- 2
Replace the 14-screen list in Appendix A with your wireframe inventory and name every empty and error state.
- 3
Set the device matrix from the client's analytics, not your test lab. Cut anything under 3% of their sessions.
- 4
Attach the API endpoint list as Appendix C, or move API work into a separate priced phase.
- 5
Confirm who owns the developer accounts before signing, and write that owner into the assumptions.
- 6
Run the ambiguity check: search your draft for words like all, any, ongoing, as needed, unlimited and timely, and replace each one with a count, a list or a date.
- 7
Have your counsel review the final MSA and SOW before signature, then load the signed SOW into TWINJAM so every request is checked against it.
Editable Word file
Get the React Native App SOW as a DOCX.
Every clause on this page in one formatted document, with numbered sections, appendix placeholders for your counts and a one-page change order form to attach to the SOW.
- 23 numbered clauses
- Revision and change control language
- Change order form with hours and rate fields
React Native App SOW.docx
Editable Word file with appendix placeholders
One email with the file, then The Profitable Agency newsletter. Unsubscribe in one click.
Related templates
- MobileMobile App Redesign SOWA redesign SOW for an existing iOS and Android app that separates visual refresh from new functionality and protects you from inheriting the old codebase's defects.
- E-commerceShopify Plus Migration SOWA replatforming SOW that fixes the data you migrate, the apps you replace and the redirects you map, so a Magento or WooCommerce move to Shopify Plus does not absorb every loose end in the old store.
- Design & UXUI/UX Design Sprint SOWA sprint SOW that fixes the number of flows, screens and revision rounds, so a five-day or three-week design sprint ends with a decision rather than an open-ended redesign.
Client asking for something outside the SOW already? Use a change order script to raise it warmly.
Signed the SOW? Let TWINJAM hold the line.
TWINJAM turns these clauses into boundary rules, flags Slack and Jira requests that cross them, and drafts the change order with the clause already cited.