Spain
We build Android apps in Kotlin and take them all the way through Play Console review, staged rollout and the updates after.
Jetpack Compose interfaces, offline-first data, background sync that survives Doze and manufacturer battery savers. One codebase, no wrapper around a website.
Store listing, data safety form, permissions justification, target API upgrades. We prepare the release so review has nothing left to ask about.
Email and Google sign-in, session handling, Play Billing subscriptions with restore on a new device. The parts users notice only when they break.
Crash and ANR dashboards wired up before launch, triaged against real device models, and a patch release when a stack trace earns one.
Strings externalised, both locales tested on-device, consent and privacy copy written for EU users rather than translated at the last minute.
Ask for one of these by name in your enquiry — it speeds up the first conversation.
From an idea or a Figma file to a signed release on the Play Store.
You have an app; getting it published is the problem.
Someone on call for the app you already shipped.
A written read of what you inherited, before you commit to rebuilding it.
Scope and cost are quoted per project after the first call. Nothing here is a fixed package.
Device walls, build logs and the unglamorous parts of shipping Android.
A paragraph is enough: what the app should do, who uses it, whether anything exists already.
We go through screens, data, logins and payments, and say plainly which parts are cheap and which are not.
You get a build plan broken into releases, with what each one contains and what it costs. No work starts before you sign it.
Installable builds on an internal test track as we go, so you are holding the app rather than reading a status report.
Staged rollout on the Play Store, crash monitoring live, signing keys and repository handed to you with the documentation.
Our core work is native Android. If you need both platforms we will say so at the scoping call and structure the project around a shared backend, rather than promising an iOS build we would not be the right team for.
You do. The app is published under your developer account where possible, and the repository, signing keys and build configuration are handed over at release.
We read the policy citation, fix the cause — usually permissions, data safety declarations or a target API level — and resubmit. Handling review back-and-forth is part of the release work, not an extra.
Yes, and the audit exists for exactly that. We read the codebase first and tell you honestly whether continuing or rebuilding is the cheaper road.
Android changes every year: target API requirements, permission rules, SDK deprecations. A maintenance retainer covers those so the app does not quietly stop being installable.
We came with a rejected submission and a deadline. They found the data safety declaration that was wrong, fixed it and walked the resubmission through with us.
The weekly test build mattered more than any report. I had the app on my own phone from the second week and could say what felt wrong early.
Straight answers about what would be expensive. They talked us out of one feature entirely, which I did not expect from a development company.
A few lines about the app, the users and where it stands today is enough to start.
Thank you — someone from the team will get in touch shortly at the email you gave us.
This page uses cookies for analytics and advertising measurement, but only after you give your consent. Learn more