App projects drift when the scope lives in email threads. A client asks for a simple iOS app, then mentions Android halfway through. Login becomes login plus social sign-in plus password reset. A "small admin panel" turns into a full web dashboard. Push notifications, offline mode, and store submission all get assumed. Each one is a few days of work nobody quoted, and by launch the budget is gone.
This page gives you a practical way to write that scope before you quote. It covers what to include, such as screen counts, platforms, integrations, and acceptance criteria. It lists the items clients usually assume are free but are not. It explains how app work is typically priced and walks through a worked example. And it ends with a fill-in template you can copy, edit, and send with your estimate.
Scoping a new app development job right now?Paste the email or chat thread. One-page scope in under a minute. Free preview, then $19 for 10 scopes.
What your app development scope of work should include
Platforms and minimum OS versions, stated explicitly (for example, iOS 16 and later, Android 11 and later, phone only, no tablet layouts). Each additional platform, OS version, or device class adds build and test time, and clients rarely say which ones they expect.
A numbered screen inventory with the main actions on each screen, attached as a list or wireframes. The screen count is the clearest measure of size and the easiest reference point when a new screen appears mid-project.
A feature list with quantities and limits, such as one login method, one payment provider, one language, and up to three push notification types. Features without limits expand quietly, and a written cap turns every addition into a quoted change instead of an argument.
Backend and integration boundaries: whether you build a new API, connect to an existing one, or use a hosted backend, plus each third-party service by function. Backend work and integrations are where most unplanned hours go, so the scope must say who builds what and what already exists.
Deliverables and formats: source code in a repository the client controls, signed build files, environment configuration, and a handover document. Clients often expect the source and the ability to hire someone else later, and stating the format avoids a dispute at handover.
Revision rounds per milestone (design sign-off, alpha, beta, release candidate) and what counts as a revision versus a change request. Unlimited feedback loops are the most common cause of a fixed-price app project losing money.
Acceptance criteria and a warranty window: how each milestone is accepted, what a defect is, and how many days of bug fixes after store approval are included. Without a definition of done, the project ends when the client stops asking for things, which may be never.
What to put under “out of scope”
These are the things app development clients most often assume are included. Listing them up front is what keeps the project
from growing after you've quoted.
The second platform. A quote for an iOS app does not include an Android build, and vice versa, unless it says so.
A web admin panel or dashboard for managing users, content, or orders. This is a separate product with its own screens and auth.
UI and UX design. If the client has no final screens, design is a separate phase, not something absorbed into the build price.
App store listing assets and submission extras: screenshots, preview video, store copy, privacy policy, terms of service, and age rating questionnaires.
Ongoing maintenance after the warranty window, including OS update compatibility, new device sizes, dependency upgrades, and third-party API changes.
Third-party service fees and accounts: developer program fees, hosting, push notification services, map or SMS usage, and payment processor charges.
Data migration from an existing app or spreadsheet, user import, and content entry. Test data is provided by the client, not created by you.
Example: from a messy client email to a one-page scope
This is the kind of request that usually lands in your inbox:
Hey, I run a landscaping company (14 crews). I want an app where my crew leads can clock in, see today's jobs, snap before/after photos and mark the job done, and I see it all in the office. Customers should get a text when we're on the way. Something like what the big guys have but simpler. We use QuickBooks Online. iPhone and Android. Budget is flexible-ish if it saves me the 2 hours a day I spend on the phone. Can it do payroll too eventually?
And this is the one-page scope ScopeSnap produced from it, unedited:
Landscaping Crew Field App MVP
A simple field-service app that lets 14 crew leads clock in, work jobs with photos, and auto-text customers, so the office sees status without phone calls.
In scope
Cross-platform mobile app (iOS + Android, one codebase) for crew leads: clock in/out and today's job list
Job detail screen: address, notes, before/after photo upload (up to 10 per job), mark job done
One-tap 'on our way' SMS to the customer via Twilio, single editable message template
Web office dashboard: live job status, timesheets, photos, per-crew view for up to 3 office users
Admin tools: create and assign jobs to 14 crews, manage crew leads and customer records
One-way QuickBooks Online customer import (names, addresses, phones) into the app
Two rounds of revisions per milestone, 2-crew pilot, App Store and Google Play submission
One 60-minute crew-lead training session plus 60 days of post-launch bug fixes
Out of scope
Payroll processing or QuickBooks Payroll integration; v1 provides a CSV timesheet export only
Invoicing, estimates, payments, or pushing hours and completed jobs back into QuickBooks
Customer-facing app or portal, online booking, or customer photo delivery
Live GPS truck tracking, ETA calculation, route optimization, or geofenced clock-in
Recurring-schedule automation (weekly mowing templates); jobs are entered individually
Migration of existing job, customer, or schedule data from spreadsheets or current tools
Third-party running costs: Twilio SMS, hosting, Apple and Google developer accounts
Ongoing maintenance, new features, and OS updates after the 60-day warranty period
Assumptions
Owner is the sole decision-maker and returns feedback within 3 business days per milestone
Owner provides QuickBooks Online admin access, Apple Developer, Google Play, and Twilio accounts before build
Crew leads carry smartphones on iOS 16+ or Android 11+ with a data plan
Customer phone numbers are in QuickBooks and customers have agreed to receive texts
Single company, English only, roughly 14 crews and under 100 jobs per day
Jobs are entered by office staff in the dashboard; no import from an existing scheduling tool
Open questions
Is the 'on our way' text a manual tap, or must it fire automatically from GPS with an ETA?
Do you need recurring weekly job schedules in v1, or can the office enter jobs individually?
Beyond importing customers, must hours or completed jobs flow into QuickBooks for invoicing now?
Where do jobs and schedules live today, and does that data need to move into the app?
Do crew leads have company phones, and how many office users need dashboard access?
Does clock-in need to be tamper-resistant (GPS or photo verification) for future payroll use?
Suggested price band
Low$28,000
Likely$45,000
High$75,000
Custom mobile app plus web dashboard, SMS, and QuickBooks sync; cost swings on GPS automation, recurring scheduling, and two-way accounting integration, with roughly $150–400/mo in third-party fees on top.
Reply to send the client
I understand you want a simple crew app where leads clock in, see today's jobs, upload before/after photos, and mark jobs done, while customers get an on-our-way text and you watch everything from an office dashboard. This scope covers that core on iPhone and Android with a one-way QuickBooks customer import, but not payroll, invoicing, GPS tracking, or recurring-schedule automation, which we can plan as phase two. I'd estimate roughly $28,000–$75,000 depending on whether the customer text is a manual tap or needs automatic GPS-based ETAs and how deep the QuickBooks sync must go. To lock in a firm number, please send a quick note on how jobs get scheduled today and confirm you can give me QuickBooks admin access.
How to price app development work
Most app work is priced one of five ways: fixed price for a defined feature list, hourly for open-ended or maintenance work, day rate for short embedded engagements, a monthly retainer for ongoing updates, or packages such as a fixed-scope MVP. The number rises with each platform, each third-party integration, custom backend work, offline sync, real-time features, and any design you have to produce yourself. Quote a range until the open questions are answered: Are designs final? Does an API exist? Who owns the developer accounts? Each unknown can add weeks, so a single figure given too early becomes a discount you did not intend.
Free app development scope of work template
Copy this, fill in the brackets, and delete anything that doesn't apply.
PROJECT
[APP NAME] for [CLIENT NAME], prepared by [YOUR NAME] on [DATE]
Platforms: [iOS / Android / both], minimum OS versions [X / Y], [phone only / phone and tablet]
SUMMARY
[One or two sentences: what the app does, who uses it, and the business goal]
IN SCOPE
[NUMBER] screens as listed in the attached screen inventory
Features: [LIST, e.g. email login, product list, checkout, order history, push notifications]
Backend: [NEW API / EXISTING API / HOSTED BACKEND], running on the client's [HOSTING ACCOUNT]
Integrations: [PAYMENT PROVIDER, ANALYTICS, PUSH SERVICE, CRASH REPORTING]
Testing on [NUMBER] physical devices: [DEVICE LIST]
One submission to [STORE / STORES] under the client's developer accounts, including one resubmission if rejected
Deliverables: source code in [REPOSITORY], signed build files, environment config, and a handover document
OUT OF SCOPE
[e.g. Android version, admin web dashboard, offline mode, localization, tablet layouts]
Bug fixes beyond [NUMBER] days after store approval
Store listing assets, marketing copy, privacy policy, and terms of service
ASSUMPTIONS
Client supplies final UI designs in [FORMAT] before development starts
Client provides API documentation, test credentials, and sample data by [DATE]
Third-party services are available and their fees are paid directly by the client
CLIENT RESPONSIBILITIES
Developer accounts, signing certificates, and hosting are opened in the client's name; access granted by [DATE]
One named contact, [NAME], reviews each build and gives consolidated feedback within [NUMBER] business days
TIMELINE
Start [DATE]; milestones: [DESIGN SIGN-OFF DATE], [ALPHA BUILD DATE], [BETA BUILD DATE], [STORE SUBMISSION DATE]
Estimated completion [DATE], assuming the feedback turnaround above; delays in client input shift all later dates
REVISIONS
[NUMBER] rounds of revision per milestone; extra rounds billed at [RATE]
Changes to approved designs, the screen inventory, or the feature list are quoted separately as change requests
PRICE AND PAYMENT
[FIXED PRICE / HOURLY RATE / DAY RATE], payable [DEPOSIT %] up front and [%] at each milestone
Invoices due within [NUMBER] days; work pauses on overdue balances
ACCEPTANCE
Each milestone is accepted when the client signs off in writing or [NUMBER] business days pass without objection
Final acceptance on store approval or delivery of the final build, whichever comes first
Rather not fill in the blanks by hand?Paste the email or chat thread. One-page scope in under a minute. Free preview, then $19 for 10 scopes.
Yes. A screen inventory is the single most useful line in an app scope. List each screen by name, one per line, and note the main actions on it. Attach wireframes if you have them. When the client later asks for a settings page that is not on the list, you point to the inventory and quote the addition. Without it, every new screen is an argument.
How do I handle bug fixes after launch?
Set a warranty window in the scope, commonly 14 to 30 days after store approval, during which you fix defects in features you built at no charge. Define a defect as behavior that differs from the agreed spec. Anything else, including OS updates that break something later, new device sizes, or third-party API changes, is billed hourly or under a maintenance retainer.
Who should own the app store developer accounts?
The client should. Have them open the developer accounts for each store in their own name and pay the fees, then invite you as a team member with the access you need. If you publish under your account, you own the listing, the reviews, and the liability, and transferring later is slow and sometimes blocked. Put this in the client responsibilities section.
What if the client does not have designs yet?
Say so in the assumptions and price accordingly. Either quote a separate design phase with its own deliverables and sign-off, or state that development starts only after the client delivers final screens in an agreed format. Do not fold unpriced design into a build quote. Building from rough sketches means you make design decisions the client will later want changed, and every change costs you.