NextEraSolutionsAndroid app development: native Kotlin apps, from phones to POS terminals and car dashboards
Next Era Solutions builds native Android apps, from phones to POS terminals and car dashboards: a senior team working remotely across Europe, an EU contract, rates per engineer by level. We design and build Android apps from scratch. Two of our Android projects were built for dedicated hardware: a POS platform for food retail businesses in the DACH region, and the radio module of a carmaker's Android Automotive infotainment system.
Building for hardware? Send us your device list with your first message (see Talk to us, below).
Is this you?
Your app has to talk to hardware.
Scales, receipt printers, barcode scanners, a custom POS device, or a car's head unit.
Your Android app is unstable on some phones.
Android users run many different devices, and your app lags or crashes on some of them.
Your iOS app is ahead of your Android app.
You have an iOS app, or a cross-platform one, and the Android side needs to catch up.
Key flows must work without the internet.
A store checkout on a local network, or a trip record made at an airport gate.
What you get
- A native Android app in Kotlin. Who owns the code, the repository and the Google Play account is set out under Contract, code and data, at the top of the FAQ.
- Crash reporting and analytics before the first release. Travel Security Kit shipped with Firebase Crashlytics and Firebase Analytics.
- A release bar you can check. Google Play's Android vitals include two core numbers. Play flags an app when more than 1.09% of its daily users see a crash, or more than 0.47% see an ANR. ANR means "Application Not Responding": the app froze, and Android reported it. On any single phone model the limit is 8%. Ask any team you hire what crash and ANR rates it aims for, and whether it watches Android vitals after release.
- Why those limits matter: above them, Google Play may show the app to fewer people and warn users on its store page (Android Developers, developer.android.com/topic/performance/vitals, updated 21 September 2026).
- A separate hardware layer between the app and each device, when your app uses scales, printers or scanners. We built these layers for the Enterprise POS platform.
- Google Play release and updates: store listing, QA, fixes and updates after launch.
- Weekly progress you can check against the plan.
Travel Security Kit
Our role: we designed and built the native Android app.
Clixar makes a physical Security Seal for checked luggage. The app turns that seal into a digital travel record. A traveller registers the trip and photographs the bag and seal before departure. After arrival, they check the seal. If the bag is lost or damaged, the app gives them a ready Lost & Found claim.
Read the Travel Security Kit case →- 6 mo from product flow to a completed Android foundation
- Trip state tracking that copes with patchy airport connections
- Stack: Kotlin, Android Jetpack, MVVM, Coroutines, Retrofit, Room, Firebase Analytics and Crashlytics
More Android work
Enterprise POS System · DACH food retail
Our role: Android engineers inside the client's core product team.
Hardware integration for scales, receipt printers, barcode scanners and POS terminals, multi-register communication on the store's local network, and checkout that keeps working offline.
500+ businesses supported1+ year development and support
Read the case →
Automotive Radio System · client under NDA
Our role: Android AOSP engineering for the radio module of a carmaker's next-generation infotainment system (client under NDA).
AM/FM and HD Radio for the US market, channel browsing, now-playing states, embedded hardware.
6 mo engineering engagement
Read the case →Motiday · UK
Our role: six months of native Android delivery for a consumer app that was live at the time.
Categories, daily notifications, favorites, sharing and Premium surfaces. The 1M+ downloads were the whole product's public figure across iOS and Android, not ours alone; the client has since closed the app.
1M+ downloads before closure5 Android flows
Read the case →How it runs
| Step | What happens | How long |
|---|---|---|
| 1. First call | Your app, your devices, your deadline. | 30 min |
| 2. Scoping | A short discovery call, then a written proposal. On a hardware project, have your device list ready for this step (see Devices, below). | Depends on scope |
| 3. Start | We staff the team. | Usually within 1 working week |
| 4. Build | Weekly progress. Each build is tested on the agreed device plan (see Devices, below). | Depends on scope (see below) |
| 5. Release on Google Play | Google Play offers internal, closed and open testing before production, and a staged rollout to a share of users at a time (Play Console Help). | Review times are set by Google |
| 6. After release | Fixes, updates, and the yearly target API update Google Play requires. | Ongoing |
- How long overall. Our cost calculator's model puts a focused app at about 6–12 weeks from design to release. A mid-size app takes about 3–6 months, and a large one 6–12+ months. Travel Security Kit took 6 months.
- Devices: your device list comes first. Every device model the app must run on, its Android version, and the SDK or protocol documents for each accessory. (An SDK is the software kit a device maker supplies.) Have it ready for step 2 above.
- Devices: what we have and have not shipped. We have not shipped apps for Wear OS watches or Android TV. Tell us early if your app needs one of them. We have shipped layouts for foldable phones, under NDA.
Pricing
- Rates are per engineer: about $30–$90 an hour, depending on level and experience. Our cost calculator uses one blended planning rate to give you a first range; it is a planning figure, not a single price.
- No minimum project size. We work time and material, at a fixed price, or with our engineers inside your team.
- Before discovery you get a range, not a number. The calculator shows ±15% around the scoped midpoint. After a short discovery call we send a written proposal.
- Android alone costs the same as iOS alone in our model. The calculator prices one native platform at 0.9 times the hours of a shared codebase, whichever platform it is. Two fully native apps (Android and iOS) come to 1.7 times: about 70% more than one shared codebase.
- On hardware projects, each device adds hours. Every device with its own SDK (a scale, a receipt printer, a scanner, a POS terminal) needs its own integration and its own tests on the real device. Our calculator has no line for this yet, so its range leaves that work out. Your device list (see Devices, under How it runs) is what lets us price it.
- Other things that move an Android price: the feature list, offline mode, and compliance work in regulated sectors (legal, finance, health).
Technical depth
When native Android may be the better choice
Common reasons to build native Android rather than one shared codebase. The last column links a related case study.
| Constraint | Why it can favour native Android | Related case |
|---|---|---|
| Device SDKs for scales, receipt printers and scanners | A shared-code layer adds a bridge to the device's SDK that someone then has to maintain. | Enterprise POS System |
| Changes to Android itself (AOSP, Android Automotive) | Platform work happens below any cross-platform framework. | Automotive Radio System |
| Offline work on a local network: several registers, cashier session transfer | It usually needs direct control of local networking, storage and background work. | Enterprise POS System |
When a shared codebase may suit you better: the same screens on both platforms, no special hardware, and one team for both. We build those too: Flutter is our default for shared code (Rethought and Gamble Count are our Flutter builds), and we have shipped Kotlin Multiplatform projects.
Our Android stack, from shipped projects
App code: Kotlin, Jetpack Compose, Android Jetpack, MVVM, Coroutines. Data and network: Retrofit, Room. Services: Firebase (Analytics, Crashlytics), push with deep links (OneSignal, Firebase), Google Play Billing. Platform and hardware: Java for AOSP, the Android framework and SDK for hardware integration. AOSP is the Android Open Source Project: the base that carmakers and device makers build their own Android on. Delivery: CI/CD pipelines, Jira, Git.
Google Play rules we plan for
Last checked: [TEAM SUPPLIES: date at publish; re-check both rules]. The full, dated list lives in our store-rules post.
- Target API level. New apps and updates on Google Play must target Android 16 (API level 36) from 31 August 2026. Developers could ask for an extension to 1 November 2026. Google Play Console Help
- Developer verification. Enforcement starts in Brazil, Indonesia, Singapore and Thailand from 30 September 2026, and goes global in 2027. Android Developers
Who you'll work with
Our engineers are a senior team working remotely across Europe, from the UK to Portugal, the Nordics and DACH, and a few work in Ukraine. Under 20 people work on client projects regularly, contractors included. These are the people you deal with:
Oleksiy Kazavchynskyy, CEO: takes the first call, leads discovery and is your commercial contact
Andriy Kazavchynskyy, Co-founder, responsible for delivery; your staffing contact- Dmytro, Business analyst and project manager
[TEAM SUPPLIES (review step): add "Reviewed by <name>, <date>" only after that person reviews the page]
Contract, code and data, and other questions
With AppVanta OÜ, a company registered in Estonia (reg. 17188835, VAT EE102858846). Next Era Solutions is its trading name. So your contract is with an EU company. The engineers who build your app work remotely across Europe.
The rights to the code and designs pass to you as each invoice is paid. Where the repository lives is set in the agreement: often it is yours from day one; on some projects, an MVP especially, it sits on our side while we build, to move faster, and is then transferred to you.
It depends on the agreement; there is no single default. Often the app is published from your own Play Console from day one. On some projects, an MVP especially, the account and the upload key sit on our side while we build, and are then transferred to you. So it is worth knowing whose account your app lives in.
With Play App Signing, Google Play keeps the key that signs your app. If the separate upload key is lost, the account owner can ask Google for a new one (Play Console Help). An app can also move from one Play developer account to another, and its users, ratings, reviews and download statistics move with it (Play Console Help). Both read 23 September 2026.
How personal data is handled and transferred is agreed in writing for each project. Ask us about yours.
USD or EUR, and GBP is possible. Payment terms are net 14 or net 30, depending on the client. Time and material is invoiced monthly in arrears, on logged hours. A fixed price has a first payment at signing, then one per milestone. Our calculator can show estimates in GBP, EUR or USD.
No. We also build native iOS, Flutter is our default for one shared codebase, and we have shipped Kotlin Multiplatform projects. This page covers the cases where native Android is the better choice. On the first call we'll tell you which fits your app and why.
Yes. A device is easiest to integrate when its maker supplies an Android SDK or documents its protocol, so ask them for those first. On the Enterprise POS platform we integrated digital scales, receipt printers (including Zebra), barcode scanners and POS terminals. We also made several registers talk over the store's local network. Send us your device list first (see Devices, under How it runs).
Yes, both shipped under NDA. We have integrated payment (card) terminals, and we have set up MDM and kiosk mode for dedicated devices.
Yes. Several of our Android projects were live products. We extended an enterprise POS platform already used in stores and delivered Android features for Motiday while it was a live consumer app (the client has since closed it). If you don't know what state your app is in, start with our free high-level audit: what users say in your Google Play reviews, the Play rules your next update has to meet and, if you give us read access, your crash and ANR rates.
Usually within 1 working week.
Tell us about your Android app.
What it must do, which devices it runs on, and when you need it. Building for hardware? Send us your device list: the device models, their Android versions, and the SDK or protocol for each accessory. The first call is more useful with it.
Oleksiy replies within 1 business day.