Technology in practice
Android (Kotlin)
Build an Android app around its actual users
A fit for recurring mobile experiences and device capabilities within the Android ecosystem.
Let’s discuss your situation ↗01
Choose with context
What we assess before recommending it
Identical behaviour across every existing device cannot be promised. We agree supported versions and device ranges; for simple use cases we also assess a responsive website.
This capability supports those areas according to the project. If the solution is still unclear, we start by organising needs and priorities. Explore Strategy ↗
02
What we can address
We design native workflows in Kotlin and adapt the interface to target screens.
We integrate accounts, data and notifications where the agreed journeys need them.
We test an agreed device matrix and prepare Google Play publication and updates.
Technical detail, explained
- Kotlin
- The language used to develop the native app.
- Device matrix
- Versions and device types agreed for testing and maintenance.
03
What you receive
We specify these deliverables in the proposal, according to what needs building or reviewing.
- The app and source code for agreed workflows.
- Compatibility matrix and test results.
- Publishing configuration and integration documentation.
The proposal identifies source code and documentation to deliver, client access and third-party licences. We agree ownership and handover before starting.
04
Getting started
We review users, devices and backend. Fragmentation, offline use and integrations influence testing, effort and maintenance.
- Share the context: what exists, who uses it and what needs to change.
- Where technical uncertainty remains, we propose a bounded review before estimating implementation.
- We agree deliverables, phases, acceptance criteria, schedule and budget before building.
Timing, investment and third-party costs
We do not publish a single figure because a review and a full build are different engagements. The estimate separates our work from hosting, licences and usage-based services, and identifies dependencies such as access, content or app store approval.
What happens after handover
We define validation, handover and any included support period. Ongoing maintenance is agreed separately, with explicit coverage, channels and response times; continuous availability is not assumed.
Let’s start with your situation.
Tell us what you want to improve and what exists today. You do not need to have chosen the technology.