Skip to content
TWINJAM

SOW template · Mobile

Mobile App Redesign Statement of Work Template

A 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.

Download the DOCXRun a free SOW audit
Fixed fee, 10 to 16 weeks6 deliverables · 5 exclusions
Mobile App Redesign SOW.docx Parsed
6
Deliverables
5
Exclusions
2 rounds
Revision rule

Mobile · Exclusion rule

New features, new screens and changes to business logic or APIs.

Ambiguity fix

Redesign and improve the app.

Redesign the 26 existing screens in Appendix A and re-implement their UI without changing functionality.

Best for

Mobile agencies redesigning and re-implementing the UI of a live app built in Swift, Kotlin, Flutter or React Native.

Redesigns are where "while you're in there" requests thrive. Once the team is touching every screen, the client sees no reason not to add the feature they have wanted for a year. Redesigns also expose old defects that suddenly look like the agency's fault. This template fixes the redesign to existing functionality, inventories the screens, and defines a baseline defect list at kickoff.

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.

§ 2

Deliverables

Count everything. A deliverable a client cannot count is a deliverable a client can expand.

  1. 2.1A UI audit of the current app and a redesign direction with two style tiles.
  2. 2.2Redesigned UI for the 26 existing screens listed in Appendix A, in Figma with a mobile component library.
  3. 2.3Implementation of the redesigned UI in the existing codebase for iOS and Android.
  4. 2.4Updated app icon, launch screen and store screenshots for one locale.
  5. 2.5A baseline defect report produced in week one, separating existing defects from new ones.
  6. 2.6Regression testing of existing user flows on the device matrix in Appendix B and one store release per platform.
§ 3

Exclusions (out of scope)

Name what the engagement does not include. These are the lines your PMs will cite most often.

  1. 3.1New features, new screens and changes to business logic or APIs.
  2. 3.2Fixing defects listed in the baseline defect report.
  3. 3.3Migration to a new framework, architecture or state management library.
  4. 3.4Tablet layouts and dark mode, unless listed in Appendix A.
  5. 3.5Localization of new UI strings beyond US English.
§ 4

Revision limits

Style tiles include one revision round. Each screen design includes two consolidated revision rounds. Changes to implemented screens after design sign-off are changes.

§ 5

Acceptance criteria

Acceptance needs a measurable test and a window. Without both, delivery never formally ends.

  1. 5.1Each screen matches the approved Figma design within platform conventions on the device matrix.
  2. 5.2No new severity 1 or 2 defects introduced by the redesign.
  3. 5.3Existing defects from the baseline report are excluded from acceptance criteria.
§ 6

Client assumptions & dependencies

Tie each dependency to a date so a late input has a known effect on the schedule.

  1. 6.1The client provides repository access, build credentials and a working development environment in week one.
  2. 6.2The existing codebase builds and passes its test suite at kickoff.
  3. 6.3Current analytics events are preserved. New tracking is a change.
§ 7

Change control

New features, screens, logic changes, framework changes and fixes to baseline defects are changes. The agency replies with a change order within two business days stating the work, hours, cost and release impact.

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.

Ambiguity check1 vague term flagged

Before

Redesign and improve the app.

Safer rewrite

Redesign the 26 existing screens in Appendix A and re-implement their UI without changing functionality.

Why it matters: "Improve" invites new features. "Redesign the listed screens" does not.

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. 1

    Read the Mobile App Redesign SOW end to end and mark every number, appendix and named tool that does not match your engagement.

  2. 2

    Screenshot every existing screen to build Appendix A before quoting.

  3. 3

    Run the baseline defect report in week one and have the client acknowledge it.

  4. 4

    Check the codebase builds before you sign. If it does not, add a setup phase.

  5. 5

    Offer a separate feature phase so new ideas have a home.

  6. 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. 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 Mobile App Redesign 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.

  • 17 numbered clauses
  • Revision and change control language
  • Change order form with hours and rate fields

Mobile App Redesign SOW.docx

Editable Word file with appendix placeholders

One email with the file, then The Profitable Agency newsletter. Unsubscribe in one click.

Related templates

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.

Start free trialRun a free SOW audit