Android
A custom Android app can bring a customer service, sales journey, field workflow, or internal business process to a mobile device. On DitWork, customers can compare developers by platform experience, architecture, the quality of their discovery questions, testing, release support, and maintenance. A useful estimate requires more than a screen count. It should define user roles, systems of record, required integrations, supported devices, offline behavior, and a measurable outcome for the first release.
Apps you can order
In the Android category, you can order MVPs and commercial Android apps, customer portals and workforce apps, mobile stores, catalogs, and loyalty programs, apps using camera, maps, NFC, and Bluetooth, API, CRM, and payment integrations and maintenance, migration, and repair of an existing Android project. Separate the mandatory MVP from ideas for later releases. For every journey, state who starts the action, which data is entered, what response is expected, what happens after an error, and where the final result is stored. This level of detail prevents estimation from becoming a rough multiplication of screen numbers.
- MVPs and commercial Android apps
- customer portals and workforce apps
- mobile stores, catalogs, and loyalty programs
- apps using camera, maps, NFC, and Bluetooth
- API, CRM, and payment integrations
- maintenance, migration, and repair of an existing Android project
Deliverables by stage
| Stage | Deliverable | What to verify |
|---|---|---|
| define the MVP and supported devices | source-code repository | core flows pass on the agreed device matrix |
| prototype the principal user journeys | Gradle project with pinned dependency versions | the interface remains usable on small screens and with larger fonts |
| design modules and API contracts | build variants and environment documentation | permissions are requested only in a clear context |
What to include in the brief
Prepare the product goal and user roles, key screens and user journeys, minimum Android version and device classes, design files or interface requirements, API, authentication, and data contracts, payments, push, and background processing and MVP acceptance criteria and later releases for the task. Do not publish real passwords, signing keys, tokens, customer databases, or personal information. Attach anonymized examples and test accounts. When the interface has not been designed, order the journey map, wireframes, and clickable prototype first, then give the developer an agreed scope rather than an evolving collection of screenshots.
- the product goal and user roles
- key screens and user journeys
- minimum Android version and device classes
- design files or interface requirements
- API, authentication, and data contracts
- payments, push, and background processing
- MVP acceptance criteria and later releases
What to check before development
Before development, review design and backend API readiness, existing modules, SDKs, and licenses, Google Play account and team permissions, supported screen sizes and device architectures, permissions and background-work requirements, local data volume and synchronization and migration of users from an older app. If the backend is incomplete, the developer needs an agreed API contract, response examples, and a test environment. For an existing app, an audit should determine whether builds are reproducible, who owns the signing assets, which dependencies are outdated, where configurations live, and whether an update can be released safely.
- design and backend API readiness
- existing modules, SDKs, and licenses
- Google Play account and team permissions
- supported screen sizes and device architectures
- permissions and background-work requirements
- local data volume and synchronization
- migration of users from an older app
Development workflow
A controlled workflow includes define the MVP and supported devices, prototype the principal user journeys, design modules and API contracts, build the interface and business logic, integrate payments, push, and background work, test across a device matrix and release tracks and prepare the App Bundle, publication, and maintenance. Accept milestones through test builds rather than waiting for one final demonstration. Confirm authentication, the principal user journey, and the highest-risk technical feature first. Add the remaining screens, loading states, empty results, failures, analytics, and recovery behavior only after the foundation is proven.
- define the MVP and supported devices
- prototype the principal user journeys
- design modules and API contracts
- build the interface and business logic
- integrate payments, push, and background work
- test across a device matrix and release tracks
- prepare the App Bundle, publication, and maintenance
Technical requirements
Technical requirements should cover Kotlin with an agreed Jetpack Compose or Views approach, clear architecture and state management, secure token storage, correct permission and background-task behavior, adaptation to screen sizes and densities, accessibility, localization, and dark theme and logging, crash analytics, and personal-data minimization. A mobile interface must respect system text size, safe areas, the keyboard, orientation, dark theme, and slow-network conditions. Permission requests should appear in a clear user context. Secrets must not be stored in the repository, and application logs or crash reports must not expose personal data.
- Kotlin with an agreed Jetpack Compose or Views approach
- clear architecture and state management
- secure token storage
- correct permission and background-task behavior
- adaptation to screen sizes and densities
- accessibility, localization, and dark theme
- logging, crash analytics, and personal-data minimization
What the developer should deliver
At completion, request source-code repository, Gradle project with pinned dependency versions, build variants and environment documentation, build and signing instructions, an inventory of variables and secrets without values, test scenarios and device matrix and handover documentation for another team. The customer should be able to produce a future build without the original contractor. That requires source code, dependencies, instructions, account ownership, app identifiers, and securely transferred signing assets. Documentation should explain environments, test and production releases, data migrations, and rollback to a previous version.
- source-code repository
- Gradle project with pinned dependency versions
- build variants and environment documentation
- build and signing instructions
- an inventory of variables and secrets without values
- test scenarios and device matrix
- handover documentation for another team
What affects the price
The cost of Android development depends on number of screens and user roles, design and backend readiness, breadth of the supported device matrix, offline mode, synchronization, and background work, payments, maps, and hardware features, complexity of migrating an existing app and testing, release, and maintenance period. Compare proposals with the same scope: design, backend, admin interface, analytics, publication, testing, and the defect-correction period. A low quote may omit error states, device adaptation, store-review support, or source-code handover.
- number of screens and user roles
- design and backend readiness
- breadth of the supported device matrix
- offline mode, synchronization, and background work
- payments, maps, and hardware features
- complexity of migrating an existing app
- testing, release, and maintenance period
How to choose a developer
When selecting an Android developer, ask for relevant apps and request an explanation of the person’s contribution, architecture, and release process. A responsible specialist asks about users, APIs, analytics, accessibility, security, offline behavior, and ownership of platform accounts. They do not guarantee store approval without review and clearly separate defect correction from new features.
How to accept the app
Before acceptance, verify core flows pass on the agreed device matrix, the interface remains usable on small screens and with larger fonts, permissions are requested only in a clear context, background work respects system restrictions, network loss does not duplicate operations, personal data is absent from logs and the release build can be reproduced from the instructions. Use test data and real devices rather than only an emulator. Check first launch, repeat login, network loss, session expiry, double taps, return from background, denied permissions, and upgrade from the previous version. Critical operations should not be duplicated by a retry.
- core flows pass on the agreed device matrix
- the interface remains usable on small screens and with larger fonts
- permissions are requested only in a clear context
- background work respects system restrictions
- network loss does not duplicate operations
- personal data is absent from logs
- the release build can be reproduced from the instructions
An Android project should not be evaluated on a single flagship phone. Screen size and density, memory, system version, manufacturer software, battery restrictions, and network quality all affect behavior. The brief should define a practical device matrix and critical scenarios rather than promise identical testing on every model. For publication, the customer should control the account, signing key, package name, Google Play Console access, and secure backups of release assets.
Access, data, and responsibility
In an Android project, the customer is responsible for lawful data use, content, trademarks, payment terms, privacy policies, and accurate store declarations. The developer is responsible for the agreed implementation, failure handling, minimum access, documentation, and handover. Before work begins, agree on SDK licenses, analytics retention, account deletion, backups, and the maintenance period.
How to post a task on DitWork
To order Android development on DitWork, post a task with a concise product description, user roles, mandatory MVP, design and API references, and measurable acceptance criteria. State devices, languages, offline journeys, payments, notifications, desired timing, and publication ownership. Compare proposals by business understanding, architecture, test plan, delivered assets, and post-release support.
