We build Android apps for the phones, tablets, and counter terminals your staff actually hold — order taking, warehouse and delivery work, inspections, kiosks, and customer apps. It is the platform we have the deepest production history on: the POS software we architected runs on more than 10,000 Android devices in daily retail use.
A published Android app, the server behind it, the accounts it depends on in your own company name, and documentation good enough that another engineer could take it over without calling us. In practice that means:
One thing we insist on: the Play Console account is yours. If the store listing sits in a vendor's account, you cannot ship an urgent fix to your own customers the day you fall out with them. We set that up correctly before any code is written, and we integrate with the hardware ecosystems our clients already use rather than pushing you onto a device family that suits us.
Android punishes shortcuts more than any other platform we work on, because the app does not run in one environment — it runs on a dozen manufacturers, five OS versions, and whatever cheap tablet the branch manager bought. Decisions made in week one decide whether that is a manageable long tail of small fixes or a permanent tax on every release.
The most expensive mistake we see in inherited Android projects is manufacturer SDK code sprayed through the application. A printer library is called from the receipt screen, a card reader SDK from the checkout screen. It works, it demos, and then you switch hardware supplier — or your supplier ships a new model — and the change touches forty files. On the POS platform we architected we solved this once with a hardware abstraction layer, which is why new terminals can be certified there without a full application rebuild. We design client work the same way, even when the first version only supports one device.
The second is treating offline as a feature to add later. It is a data model decision. Whether the app can queue work, survive a restart mid shift, and reconcile two people editing the same record is settled by how the local store and sync layer are designed, not by a checkbox. We decide that deliberately at the start — including deciding not to do it when your users are always online, because offline sync you do not need is money burned.
Cheap development shops skip these decisions because they are paid for visible screens, and the bill arrives later as a rewrite. We write the architecture down in plain language first, you get to challenge it, and then we build in one-to-two-week increments you can install on a real device. We also operate our own products in production, so the cost of our own shortcuts lands on us.
No price on a web page — anyone quoting your project without seeing it is guessing. But you can place yourself on the four things that actually move the number.
Every printer, scanner, card reader, or RFID device needs physical testing, and each behaves differently. Supporting one device family is a known quantity; supporting four is roughly four times the testing, not four extra days.
A fleet of identical company-issued tablets is cheap to support. An app for whatever phone your customers own means older OS versions, low-memory devices, and manufacturer quirks — all of which need real testing, not an emulator.
Working without connectivity, then reconciling conflicting edits across branches, is real engineering. Essential for retail floors, vehicles, and warehouses; wasted effort for an office app that always has WiFi.
Payments demand audit trails and idempotent handling so a retry cannot double charge. Integrating with your existing ERP or accounting system adds weeks of approvals and undocumented behaviour that have nothing to do with the app.
As a rough shape: a focused single-role internal Android app is typically a 6–10 week build. Add peripheral hardware, a second user role, or an admin console and it lengthens. A multi-branch, offline-first system with payments — the category our POS and payment work falls into — runs materially longer and should be phased so you see value before the whole thing is finished.
Order taking, stock counts, transfers between branches, and counter-side apps driving printers and card readers. Android is the default here because the hardware is Android — and this is exactly the ground our 10,000-store POS platform covers.
Driver apps with route lists and proof of delivery, scanner-based picking and putaway, vehicle checks, and ticketing. These live where signal is unreliable, so offline-first is not optional.
Line-side quality checks, machine logs, maintenance jobs, and inspection sheets on rugged tablets. Frequently paired with an AI layer that reads the captured documents instead of a person retyping them.
Our largest production deployment is Android: point-of-sale software in more than 10,000 retail stores carrying over $50M in annual transactions, offline-first, multi-tenant, with payment hardware abstracted behind one layer. Alongside it, our AI systems are in production at over 200 Japanese firms, and you can open the CEO's Cockpit dashboard yourself — fictional data, real product. The two case studies closest to Android work:
Offline-first point of sale, multi-tenant cloud, and a payment-hardware abstraction layer carrying $50M+ in annual transactions.
A React Native marketplace with multi-currency settlement and bilingual listings, shipped to both app stores.
Being wrong for a project is cheaper to say now than to discover in month three:
Point of sale, RFID/NFC cards, payment terminals, and cloud sync for multi-branch retail, food service, and transport operators.
React Native and Flutter apps that ship to both stores from a single codebase, when the app is business logic rather than heavy device work.
Native iPhone and iPad apps for field teams, sales floors, and customers — built in Swift, submitted to the App Store under your own developer account.
A focused single-role app with a straightforward backend is typically a 6 to 10 week build from signed scope to Play Store release. Hardware work — printers, scanners, card readers, kiosk-mode devices — adds time in a way that screens do not, because each device family behaves differently and has to be tested physically. A multi-role platform with offline sync and payments is a multi-month engagement and we would rather phase it.
Both, from the first day. The repository is created under your company, and the Google Play Console and cloud accounts are registered in your company name with you as owner. We are a collaborator you can remove. This is the opposite of the common arrangement where the listing lives in the vendor’s account and you cannot publish an update without them.
Yes — this is where most of our Android depth sits. We architected the POS platform running in more than 10,000 retail stores, including a hardware abstraction layer that keeps device-specific code out of the application. That layer is why new terminal models can be certified without rebuilding the app, and we design client work the same way rather than wiring one manufacturer’s SDK straight into your screens.
Usually. We do a paid review first, typically one to two weeks: we build it, read it, and give you a written verdict on what is salvageable, what is fragile but load-bearing, and what should be replaced. Old Android projects often need a targeted rescue — a dependency upgrade, a data-layer rewrite — rather than a full rebuild, and it is cheaper for you if we say that out loud.
Yes, end to end: signing, release tracks, data safety declarations, permissions justification, and the correspondence when Google pushes back. Google enforces target-API deadlines every year and removes apps that miss them, plus tightening rules around background location, storage, and account deletion. We design for those rules rather than discovering them at submission.
If the app is mostly business logic and screens — orders, listings, approvals, dashboards — cross-platform is usually the better commercial answer and we will say so. Native Kotlin earns its keep when the app is bolted to hardware, runs in kiosk mode on company-owned devices, needs deep background work, or has to squeeze performance out of cheap phones. See our cross-platform page for the honest comparison.
Android fragmentation means testing never really finishes: a bug that appears only on one manufacturer’s Android 13 build is normal. We offer an ongoing arrangement covering crash monitoring, device-specific fixes, annual target-API upgrades, Play policy changes, and a defined response time on defects. Businesses that skip it typically return two years later unable to publish an update at all.
A 30-minute call with an engineer, in English or Japanese. Bring the devices, the branches, and the process you want replaced — we will tell you honestly what it takes.