Fixed-Price React Native B2B Field App: What Belongs in the SOW

A fixed price on a B2B field app is only as good as the document behind it. Field apps break fixed-price quotes more often than dashboards do, and always in the same four places: offline behaviour, ERP integration, the device fleet, and app store release.

This is what a Statement of Work needs to name so the number holds — whether you are writing an RFP or reading an agency’s proposal.

Why field apps break fixed-price quotes

A field app is not a web app in a shell. It runs on a phone in a warehouse with no signal, a truck cab on a highway, or a customer site behind a guest network. That environment introduces three costs that generic mobile quotes leave out:

Offline is a data architecture, not a feature toggle. Once two reps can edit the same record while disconnected, you own a conflict-resolution policy whether you designed one or not.
The ERP is the real integration. The app is the easy half. Syncing bidirectionally with NetSuite or Microsoft Dynamics 365 Business Central — respecting branch pricing, ship-to logic, and tax jurisdiction — is where the hours go.
Distribution is a project of its own. Store review, MDM enrolment, and device provisioning are calendar time that a quote covering “development” quietly omits.

The scope lines that must be explicit

Offline and sync

Name the model, not the adjective. “Works offline” is unpriceable; these are priceable:

Which entities are available offline, and for how long — full catalogue, or the last 90 days of the rep’s own accounts?
The conflict policy: last-write-wins, server-authoritative, or field-level merge — and what the user sees when their edit loses.
The sync trigger: on reconnect, on app foreground, on a timer, or manual pull.
The local store: WatermelonDB, SQLite via op-sqlite, Realm, or a queue of pending mutations against a normalized cache. The choice drives weeks of effort.
Queue durability: what happens to 200 queued line items if the app is force-quit or the device reboots.

ERP integration

The SOW should name the system, the version, the specific endpoints or objects, and who owns credentials and the sandbox. Two lines that decide the price:

Direction and frequency per entity. Products read-only, hourly. Orders write, immediate. Inventory read, every 15 minutes. Customers read, nightly.
Who provides the sandbox, and by when. Waiting on ERP access is the single most common cause of a fixed-price project slipping — and if the delay is the client’s, the SOW should say so.

Rate limits, API version deprecations, and any middleware licence costs belong in the exclusions or in the price, explicitly.

The device fleet

Cheap rugged Android devices are where field apps actually die. Pin it down:

Named minimum OS versions for iOS and Android, and the specific devices in the fleet.
Hardware integrations: barcode/QR via camera or a hardware scanner (Zebra, Honeywell — these need vendor SDKs and native modules), NFC, printers, GPS, camera and photo upload.
Battery and screen conditions — a full shift of scanning, and outdoor daylight readability.

Any hardware SDK is a native module, which means it may not work under Expo Go and may require a custom development build. That is a scope fact, not a detail.

Auth and permissions

Role-based access — a rep sees their accounts, a supervisor sees the branch — plus the session policy for a device that goes days without connectivity, and the remote wipe path for a lost phone.

Release and distribution

Public App Store and Play Store, or internal distribution via MDM (Intune, Jamf) or Play Managed? These are different amounts of work and different amounts of waiting. The SOW should name who owns the developer accounts, who submits, and what the agency’s obligation is if Apple rejects the first submission.

Acceptance criteria that are actually testable

Fixed price without demonstrable acceptance criteria is an argument waiting to happen. Write them as things a person can run:

“A rep can create a 20-line order in airplane mode; on reconnect it appears in Business Central within 5 minutes with correct branch pricing.”
“Scanning 100 barcodes in sequence takes under 90 seconds on the [named device].”
“A conflicting edit surfaces a resolution prompt and never silently discards the local change.”
“Cold start to usable list view is under 3 seconds on the oldest supported device.”

Each of those either passes or does not. “The app is fast and reliable” does neither.

The exclusions list

On a fixed-price field app, the exclusions protect both sides. Expect to see — and to negotiate — these:

Historical data migration and cleanup in the ERP.
Third-party licences: MDM seats, scanner SDKs, map or address-validation APIs, push infrastructure.
Content: product imagery, descriptions, translations.
Cloud costs during and after the build.
ERP-side customization — if a required field does not exist in NetSuite yet, someone has to add it, and that someone may not be the app team.
Store review delays and any changes demanded by Apple or Google review.
Support beyond the warranty window (typically 30 days of defect fixes against the acceptance criteria).

What you should own at handoff

The repository, from day one rather than at the end. Infrastructure as Terraform. The CI pipeline that builds and signs both platforms. Environment variables documented, with a .env.example. A runbook covering how to cut a release, how to roll back, and how to read the sync logs when a rep says an order vanished. And the store listings under your developer accounts, not the agency’s.

If any of those live with the vendor, you have not bought an app. You have rented one.

Work with us

We build React Native field apps for wholesale distributors and multi-location operators under fixed-scope SOWs — offline sync, ERP integration, and the acceptance criteria written down before the price is agreed. If you want the scope pinned down before you commit to a budget, get in touch.

Need this built? Our team does fixed-scope mobile app development — scoped, priced and delivered in weeks.