NextEraSolutionsAndroid POS and store-floor apps that work with scales, printers and scanners, even offline
Next Era Solutions helps POS software vendors and retail-tech teams with the Android side of their product. We work on checkout with weighed goods, receipt printers and barcode scanners, and connect several registers on one store network. Key flows keep going when the internet drops. Our engineers can join your product team, as they did on a POS platform used by food retailers across the DACH region. Not for a single shop that needs a till (see "Probably not a fit" below).
Is this you?
You sell POS software, and the Android side has a queue.
A new terminal, a new scale, a new printer model, and nobody free to connect it.
Checkout has to keep going when the store's internet drops.
Registers on the same store network still need to see each other. They also need to hand over a cashier's session.
Your team knows retail, not device SDKs
(the code kits that device makers ship). You want Android engineers who have made scales, printers and scanners work together in daily store use.
Probably not a fit:
you run one shop and need a till. A ready-made POS product will cost you far less than custom work.
What you get
- Android engineers in your product team. They work in your Jira, your Git and your release process. On the POS platform we shipped features, fixed stability issues and gave ongoing support. More on how this works: our mobile team augmentation service.
- A hardware layer for each device: scale, receipt printer, barcode scanner and POS device. Each layer is kept apart from the checkout logic. We built and supported these layers on the POS platform.
- Store-network flows. Several registers talk over the store's own network. A cashier's session can move from one register to another.
- Checkout that works offline. Key flows do not depend on the store's internet link.
- Device-management flows for the people who run the stores, such as scale setup and maintenance. On the POS platform we extended these flows.
Enterprise POS System
Our role: Android engineers inside the client's core product team.
A B2B retail platform needed Android engineers to extend an enterprise POS system. Bakeries, grocery stores and other food retailers in the DACH region use it. It runs on specialised Android POS devices, with scales and receipt printers. Key checkout flows must keep running inside the store's local network. Our part: we built and supported the hardware layers for POS devices, scales, receipt printers, barcode scanners and the store network. We also extended the cashier, register, checkout and device-management flows. The POS system itself was there before we joined. The client is under NDA. [TEAM SUPPLIES after the NDA answer: one sentence on the hardest store-floor problem and how it was fixed; the client's name only if they agree]
Read the Enterprise POS case →- 500+ businesses supported by the platform
- 1+ year of development and support: new features, stability fixes and ongoing support in the product team
- Scales, receipt printers, barcode scanners and POS devices working together in daily store use
- Stack: see Our POS stack, under Technical depth
More work on dedicated hardware
Automotive Radio System · client under NDA
Our role: Android AOSP engineering for the radio module of a carmaker's next-generation infotainment system.
AOSP is Android's open-source code base. Android talks to specialised embedded hardware, with touch-safe screens for in-car use. It is relevant if your POS runs on custom Android hardware.
6 mo engineering engagement
Read the case →How it runs
| Step | What happens | How long |
|---|---|---|
| 1. First call | Your product, your devices, your backlog, your markets. | 30 min |
| 2. Device list | Have your device list ready: every device model, SDK and protocol the work touches, and what documentation exists for each. | Depends on scope |
| 3. Start | An engineer (or a small team) joins your product team. | Usually within one working week |
| 4. Build and test | Work in your sprints. | Your cadence |
| 5. Support | Fixes, new devices, new rules. On the POS platform this ran for more than a year. | Ongoing |
- What to have ready: most POS work touches the items below. Which of them yours needs depends on your devices.
- Your device list: every terminal, scale, printer and scanner model the work touches.
- SDKs and docs for each device, and the right to use them.
- Test hardware: the devices the engineers will test on, or remote access to them.
- A test or pilot store, or a store-like setup, before a release reaches real stores.
- Access to your code, backlog and release process.
- Who owns fiscal and payments: your certified TSE or signature provider, and your payment provider.
Pricing
- Rates are per engineer, about $30–$90 an hour, depending on level and experience. No minimum project size. We work three ways: time and material, a fixed price, or engineers in your team.
- Engineers in your team are billed by the hour, at each engineer's rate. We invoice in USD or EUR (GBP possible), on net 14 or net 30 terms. The notice to scale down or stop is set in the agreement. In the first two weeks you can stop, or ask for a different engineer, with no notice; you pay only the hours worked.
- A fixed project starts as a range, ±15% around the scoped midpoint. That could be a set list of device integrations.
- What moves a POS price most: how many device models and SDKs the work touches; whether those SDKs are documented; how much must work offline; the rules of the markets you sell in; how many registers share one store network.
- Our cost calculator gives a first range for a whole app. Pick "Enterprise / custom" and "Offline mode". It has no line for hardware work, so we price each device on the call.
Technical depth
What the store floor demands, and where we met it
Each row is a feature of the POS platform we worked on. Each row keeps the platform's feature apart from our part, as set out in the featured case above. Where the case does not record our part, the row names the platform's feature only.
| On the store floor | What it means for the Android app; on the platform, and our part | Where we met it |
|---|---|---|
| Goods sold by weight | The price comes from the scale's reading, not from a number the cashier types. The app must read the scale reliably and show the weight clearly. On the platform: weighted products from digital scales; scale setup and maintenance modules. Ours: the scale integration layer. | Enterprise POS System |
| A receipt for every sale | The printer has to be ready at the moment of sale. The cashier needs to see when it is not. On the platform: receipt printer integration; Zebra printers in the stack. Ours: the receipt printer integration layer. | Enterprise POS System |
| Scanning | Scanners from different makers send input in different ways. Checkout should not care which one is plugged in. On the platform: barcode scanner integration. Ours: the scanner integration layer. | Enterprise POS System |
| Several registers in one store | Registers share state over the store's local network, with or without internet. On the platform: multi-register local network communication; device-to-device workflows. Ours: the local network layer. | Enterprise POS System |
| Shift changes | A cashier's session moves from one register to another without losing the open sale. On the platform: cashier session transfer. Ours: we extended the cashier and register flows. | Enterprise POS System |
| The internet drops | Key flows keep working inside the store network. On the platform: offline-ready critical workflows. | Enterprise POS System |
| A new device model | New hardware should mean a new adapter, not changes all through checkout. On the platform: hardware abstraction layers. | Enterprise POS System |
Rules a POS app has to fit: these rules belong to the merchant and the POS vendor. We list them so you can see what your app has to fit. This box is not a claim that we did fiscal work.
Our POS stack, from the shipped work
Kotlin, the Android SDK, custom POS devices, receipt printers, Zebra printers, barcode scanners, digital scales, local network communication, device-to-device workflows and hardware abstraction layers.
Rules a POS app has to fit
Last checked: [TEAM SUPPLIES: date at publish. All rules read 2026-09-23. On publish day, re-read Directive 2014/31/EU on EUR-Lex and the RKSV at RIS.]
- Germany: a certified security device and a receipt. Electronic tills must be protected by a certified technical security device (TSE). A receipt must be issued for each sale (§ 146a AO). The rule covers electronic or computer-based cash registers (§ 1 KassenSichV, gesetze-im-internet.de/kassensichv/__1.html). Gesetze im Internet
- Germany: telling the tax office. Since 2025, businesses report their electronic POS systems and TSEs through ELSTER. Third-party software can report through ELSTER's ERiC interface. Systems bought before 1 July 2025 had to be reported by 31 July 2025. Later ones must be reported within one month of purchase. Finanzverwaltung NRW
- Austria: signature cards. Registers work with a signature or seal unit, such as a signature card. The business reports both the unit and the register through FinanzOnline (RKSV § 16, at RIS: ris.bka.gv.at). The finance ministry says cards with the ACOS-ID 2.1 chip stopped meeting the rules on 7 June 2025. They must be swapped and set up in the register by May 2027 at the latest. BMF Austria
- EU: scales that sell by weight. Directive 2014/31/EU covers non-automatic scales used for "determination of mass for commercial transactions". The approval sits with the scale. Directive 2014/31/EU, Art. 1(2)(a) (EUR-Lex)
- Android: developer verification. Enforcement starts on 30 September 2026 in Brazil, Indonesia, Singapore and Thailand. It goes global in 2027. It applies to certified Android devices on Android 7 or higher. Apps your organisation puts on its own managed devices through its own store don't need it. Installs over a cable during development (ADB) are exempt too. Android Developers FAQ
- Google Play: target API. Does your POS app ship through Google Play? Then new apps and updates must target Android 16 (API level 36) from 31 August 2026. You can ask for more time, up to 1 November 2026. Permanently private apps, kept to one organisation for internal use, are exempt. Google Play Console Help
Who you'll work with
A senior, distributed team. Our engineers work remotely across Europe, from the UK to Portugal, the Nordics and DACH, and a few work in Ukraine.
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]
FAQ
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 POS platform we built and supported the layers for scales, receipt printers, barcode scanners and POS devices. We also made several registers talk over the store's local network. What to have ready is listed under How it runs.
On our DACH POS work, our Android engineers joined the client's core product team for more than a year.
Our POS case does not list fiscal or TSE work, and we claim none here. The TSE or signature device stays with your certified provider, so ask them early what an app has to do to work with it. The main rules are listed under Rules a POS app has to fit.
Yes. We have integrated payment-card terminals in work shipped under NDA, so we can't name the client or project. They were not part of the DACH POS case, whose devices were scales, receipt printers, barcode scanners and the Android POS devices.
On the POS platform, key checkout flows had to keep working inside the store's local network. They could not depend on outside internet access.
With AppVanta OÜ, an Estonian company (reg. 17188835, VAT EE102858846). Next Era Solutions is its trading name. So your contract is with an EU company. Our engineers work remotely across Europe. The rights to the code pass to you as each invoice is paid.
How personal data is handled and transferred is agreed in writing for each project. Ask us about it on the first call.
Usually within one working week.
Tell us about your POS product.
Which devices it runs on, what's in the Android backlog, and which markets you sell in.
Oleksiy replies within 1 business day.