Outsourced Mobile App Development Contracts: What to Demand Before You Sign

The average enterprise mobile development contract is 12 pages. The clauses that protect the buyer are typically absent from 8 of them. What most outsourcing contracts do well is protect the vendor - payment schedules, liability caps, and limitation-of-remedies language drafted by counsel who has seen what goes wrong from the vendor's side. What they leave out is the clause you will need in month four when a key engineer leaves, the scope turns out to mean something different than you thought, or the app keeps crashing and you need a way out. This is the specific list of what to demand before you sign.

Clauses most contracts omit

The three clauses most commonly absent from outsourced mobile development contracts are IP assignment on a rolling basis, attrition minimums, and performance gates tied to payment. These are not exotic demands. They are standard in well-drafted technology services agreements. Their absence in most vendor templates is a feature, not an oversight.

Rolling IP assignment. Most contracts include some form of IP transfer language, but it is often structured as a single event at project close - or, worse, conditioned on "full and final payment" without defining what that means. If the engagement ends early, or if there is a payment dispute, you may find that the app your team has been running for six months technically belongs to the vendor until settlement. The correct structure: IP transfers continuously to the client as work is completed and invoiced, with each payment triggering transfer of the IP for that payment period's work.

Attrition minimums. Staffing agencies know their attrition rates. They do not volunteer them. An engagement that starts with a strong senior engineer and a mid-level developer can, within two months, become two new hires who are still reading the previous team's notes. Without a contract clause that defines the maximum team turnover rate and the minimum notice period before a change, you have no recourse and nothing to act on.

Performance gates. Fixed-price contracts without milestone-linked acceptance criteria give the vendor one obligation: deliver something that could be described as meeting the spec. Time-and-materials contracts without quality gates give the vendor one obligation: bill hours. Neither structure protects you from an app that technically ships but crashes on specific device configurations or breaks under load.

How to define "done"

"Done" in a mobile development contract means whatever the acceptance criteria say it means. If the contract does not define acceptance criteria, "done" means whatever the vendor says it means on the day they send the invoice.

A correctly written scope clause defines done across four dimensions: functional completeness, quality thresholds, documentation requirements, and transfer obligations. Functional completeness means each feature in the scope list has a specific, testable acceptance condition - not "the login flow works" but "a user can complete registration, log in, and reach the home screen in under four taps on iOS 17 and Android 14 without error messages." Quality thresholds mean the app meets specific crash-rate, load-time, and defect-density targets before a milestone is considered closed. Documentation requirements mean the team has produced written notes on how the app is structured and how to extend it - not optional, not best-effort. Transfer obligations mean the vendor provides all credentials, keys, and access needed to hand the app to another team without a negotiation.

The practical test for a scope clause: give it to someone who was not in the sales conversation and ask them to tell you when the milestone is complete. If they cannot answer without calling the vendor, the clause is too vague.

What a poorly defined scope clause costs you is not just a delayed payment dispute. It is six weeks of "almost done" emails, an internal escalation that pulls your CTO off other work, and a vendor who has no contractual obligation to do anything differently because nothing in the contract says they are late. The engineers are billing hours. Everything is, technically, proceeding.

Attrition protection

Attrition is the most common source of delivery failure in outsourced mobile programs, and it is almost never addressed in vendor contracts. When you outsource mobile app development, you are buying a specific team's knowledge of your app, your systems, and your standards. When that team changes, you lose that knowledge - and you pay for the new team to acquire it.

The clause you need covers four things. First, a maximum attrition rate: no more than 20% of the named team members turning over in any 90-day period is a reasonable baseline for most engagements. Second, a minimum notice period: the vendor must notify you at least 15 business days before any named team member's last day. Third, a knowledge-transfer obligation: the departing engineer must document their active work and complete a handoff session with their replacement before leaving the engagement. Fourth, a replacement timeline: a qualified replacement must be active on your work within 10 business days of the departure.

Vendors who resist this clause typically have one of two problems. Their attrition rate is high enough that the clause would trigger regularly - which tells you something about working conditions or pay. Or they staff projects with whoever is available at the moment rather than with a committed team - which tells you something about how they think about your engagement relative to their next one.

One thing to watch: "replacement within 10 business days" is meaningless if the replacement does not meet the same seniority standard as the person they are replacing. The clause should specify that the replacement matches or exceeds the experience level of the departing engineer for the specific role.

Quality gates

Vague quality language in a contract is not quality assurance. "The app will be of professional quality" is not a clause. "The app will maintain a crash-free session rate of 99% or above on iOS 17 and Android 14 for 30 consecutive days following launch" is a clause.

Quality gates work when they are specific, measurable, and tied to payment. The specific targets depend on your app's complexity and audience, but these are the categories that belong in every mobile development contract.

Crash rate. Define the maximum acceptable crash rate by platform and OS version, and the measurement window. A 99% crash-free session rate over 30 days is a reasonable minimum for a field ops or sales enablement app. Specify which analytics tool will be used to measure it - this prevents disputes about whose numbers are correct.

Performance thresholds. Define the maximum acceptable app startup time (cold launch, from tap to interactive) and the maximum load time for the app's most common user flow. For an internal enterprise app, a cold launch under three seconds on a mid-range Android device is achievable and worth specifying.

Defect density. Define the maximum number of open severity-1 and severity-2 defects that can exist at milestone close. "Zero severity-1 defects and no more than five severity-2 defects open at the time of acceptance" is a clause you can enforce.

Accessibility and platform compliance. Specify that the app passes App Store review without rejection on the first submission and meets the accessibility standards your industry requires. This is particularly relevant if the app is used by field employees who may have different device configurations or connectivity constraints.

What quality gates do is move the conversation from subjective to factual. When a vendor misses a quality gate, there is no argument about whether the work is good enough. The numbers say what they say. That changes the vendor's incentive structure during the build - not just at acceptance time.

Exit clauses

A confident vendor agrees to exit clauses. An exit clause does not hurt a vendor who is delivering - it only matters if they are not. Resistance to exit rights is, therefore, a data point about how the vendor expects the engagement to go.

You need two types of exit rights written into the contract.

The first is a convenience exit: the right to terminate the engagement on 30 days notice, paying for work completed through the notice period plus a defined wind-down fee. A reasonable wind-down fee is two to four weeks of the monthly engagement rate. This is not a penalty - it is compensation for the team wind-down the vendor has to manage. What it is not is a three-month penalty that makes switching prohibitively expensive.

The second is a cause-based exit: the right to terminate immediately when specific trigger conditions are met, with no wind-down payment required. Trigger conditions should be objective and measurable. Examples: the crash rate exceeds 2% on a 30-day basis for more than 14 consecutive days after a fix has been attempted. Three successive milestones are missed by more than five business days each. A named key team member leaves the engagement and a qualified replacement is not active within 10 business days. The vendor fails to provide access to a weekly status call for four consecutive weeks.

Both exit clauses should include a handoff obligation that activates the moment termination notice is given. The vendor must transfer all code in the state it is in, all credentials, all documentation, and all access within five business days. This obligation should survive termination - meaning it does not disappear because the engagement ended.

One clause that belongs alongside exit rights: a no-poaching provision that runs in both directions. The vendor should not be able to hire your internal staff. You should not be able to poach the vendor's engineers directly. This is standard and keeps the relationship professional during a wind-down.

What Wednesday includes by default

Wednesday's standard engagement terms include rolling IP assignment, attrition limits, cause-based exit rights, and measurable quality gates as default provisions - not as negotiated additions. The reason is practical: these clauses describe how a good engagement should work anyway. If Wednesday is delivering well, none of them ever get invoked.

The attrition limit in Wednesday's standard terms is 20% in any 90-day period, with 15 business days notice and a 10-business-day replacement window. Every engagement uses named team members, and any change to the team requires client notification before it happens - not after.

Quality gates are written specifically for each engagement. For a field service app running on Android across a mixed device fleet, the crash-rate target and the load-time threshold are different than for a consumer iOS app on current hardware. The targets are agreed at the start of each phase and become the acceptance criteria for that phase's milestone payment.

The exit rights in Wednesday's terms are symmetrical. You can exit on 30 days notice for convenience. You can exit immediately on cause, using objective trigger conditions agreed at contract signing. Wednesday can also exit on cause if, for example, the client fails to pay for 30 days past the invoice date or fails to provide the system access needed for the team to work. Both sides have the same structural protection.

The reason these terms exist is not legal caution. It is that engagements run better when both sides know the rules. A vendor who knows you can leave on cause if the crash rate spikes has a stronger incentive to prevent crashes from the start. A client who knows exactly what the acceptance criteria are stops second-guessing every decision and trusts the process. Clear terms reduce the negotiation cost of every difficult conversation the engagement will eventually have.

What you learn from how a vendor responds to these terms matters as much as the terms themselves. A vendor who pushes back on rolling IP assignment, attrition limits, and cause-based exit rights is telling you something about how they expect the engagement to go. A vendor who accepts them without comment is telling you they do not plan to be in the position where any of those clauses get triggered. That difference is worth more than anything their sales team says in a pitch.