// mobile app procured through a tender

Technical Specification for a Mobile App Tender: What Usually Gets Missed

A technical specification for a mobile app tender most often covers an app with a personal account, notifications, sometimes payments and a map — for both iOS and Android at once. The client is usually a government body or a company that already has a website or back office, and needs the mobile app as an extra channel for customers or staff.

This kind of spec looks clear enough: screens, features, platforms are all listed. But a mobile app isn't a standalone program — it's a client that runs on top of a server side, gets published through someone else's app stores, and keeps living long after one release. If the spec doesn't describe these layers, the contractor physically can't price the project accurately — and the gap surfaces either in the budget or at acceptance.

Here's a look at which parts of a typical mobile app technical specification tend to stay vague, and what to do about it at the procurement stage.

What specs usually miss

No mention of whose developer account is used in the App Store and Google Play, or who publishes the app

What it leads to. Without clarity on which legal entity the account is registered to, a dispute surfaces after delivery: either the contractor publishes under its own account and the client stays dependent on it for every update, or publication drags on because the client's account was never created and verified before development started.

How to write it right. The spec states that App Store Connect and Google Play Console accounts are registered to the client's legal entity before work begins, and the contractor gets team-member access with publishing rights.

No minimum supported versions of iOS and Android are set

What it leads to. Without a version range, the contractor either builds in support for outdated systems "just in case," which drives up development cost, or targets the latest versions only — leaving users with older phones unable to install the app.

How to write it right. The spec fixes the minimum iOS and Android version, along with the device types (phone, tablet) the interface must display correctly on.

No requirements for the server side and API

What it leads to. The app is described as if it exists on its own: screens and features are listed, but where the data comes from and how it's stored is left unsaid. As a result, the contractor either builds a backend from scratch, or finds out partway through that the API needs to integrate with the client's existing system — which changes the scope and timeline of the contract.

How to write it right. The spec includes a separate section stating whether a ready API exists or a backend needs to be built, what data is exchanged and in what format, and who is responsible for the server after launch — the mobile app contractor or another team.

No acceptance scenarios on real devices

What it leads to. Without a list of device models and test scenarios, acceptance turns into an arbitrary check: the client finds a bug on their own phone that wasn't in the contractor's test set, and refuses to sign off, even though the features formally work.

How to write it right. The spec lists the device models and system versions to test on, along with acceptance scenarios — exactly what gets checked: registration, notifications, payments, behavior on weak internet and offline.

Post-launch support and updates for new system versions aren't addressed

What it leads to. After a project is delivered, Apple and Google periodically change their app requirements, and new iOS and Android versions sometimes break old code. If support isn't spelled out separately, the client ends up with an app that stops launching after a few system updates, while the contractor is no longer obligated to fix it.

How to write it right. The spec or contract separately states the period of technical support after publication, whether it covers adaptation to new iOS and Android versions, and how further work beyond the warranty period is arranged.

Payments and the in-app map are described in one line with no details

What it leads to. A phrase like "payment integration" or "map with geolocation" says nothing about which payment provider is needed, which map — Google Maps, Yandex Maps, or a local service — and what data it should display. The contractor builds the minimum viable version, while the client expects more at acceptance — leading to extra work that wasn't part of the original scope.

How to write it right. The spec names the specific payment provider and map service required, along with the exact data each should handle and display.

What a good spec gives

A good technical specification for a mobile app covers not just the screens, but the server side, publication, and the app's life after the first release.

For the client, this means comparable bids from contractors and clear acceptance criteria instead of a dispute at the final stage.

For the contractor, it means an accurate scope estimate and protection from extra work that was never actually part of the specification.

A project the client can maintain and update on their own, rather than depending on a single contractor indefinitely.

Price and timeline

Technical specification: from $400, 1-4 weeks; the price depends on the system's complexity, architecture, stack and integrations. Subcontracted development: priced by contract scope, estimated before the bid is filed.

Tender specs or subcontracting: details →

We do not name buyers or tenders: we look at a typical spec, not at anyone's procurement.

Preparing a procurement or already won a tender?

Discuss a tender