New Android app
From a brief and some sketches to a signed build on a Play Store track.
- Scoping session and written spec
- Kotlin app, built in the open repo
- Play Console setup and store listing
- Staged rollout with a rollback plan
We build Android apps, put them through the Play Console, and stay on them after release — updates, crash triage, in-app support.
Photographs from the room where the builds get made.
Bor Group is a small Android studio. We write the app, we take it through the Play Console ourselves, and we are still there when the first crash report arrives at seven in the morning.
Most of what we are asked for falls into three shapes: a new app that exists so far as a document and a few screens; an app somebody else built that now needs a keeper; and an app that works but has to survive the next target API level, the next policy change, the next phone.
We do one platform. That is a choice, not a gap — it means the person reading your crash log is the person who wrote the code.
Ask by name. Scope and cost are written after we have seen what exists.
From a brief and some sketches to a signed build on a Play Store track.
Someone else built it and has moved on. We read the code before we promise anything.
The work that keeps an app installable: target API bumps, SDK upgrades, regression fixes.
A help entry inside the app, wired to a real inbox, with the device details already attached.
Every engagement starts with a written scope — no work begins on a verbal brief.
Emulators catch the easy things. The shelf of physical devices catches the rest — old chipsets, odd screen ratios, manufacturer battery managers killing background work.
A release goes to a small percentage first. If the crash-free rate moves the wrong way, it is halted before most of your users ever see it.
Every permission has to justify itself, because each one is a line in the data safety form and a reason for someone to back out of the install.
Title, short description, screenshots in the order a person scrolls them, and a data safety declaration that matches what the code really does.
Android moves. Target API requirements change, libraries are deprecated, a new OS version breaks something quiet. That is scheduled work, not an emergency.
We came with an app nobody had touched in two years and no signing key. They found a way through it and told us honestly which parts were worth keeping.
The staged rollout caught a crash on one manufacturer's launcher. It was paused and fixed before our users noticed anything.
Scoping took longer than I expected, but the spec we signed is the app we got. No surprise invoices.
Yours, wherever possible. You own the listing, the signing key and the reviews. We work inside your console with the access we need and hand it back when the engagement ends.
It is planned work, not a fire. We upgrade, retest the affected flows on real devices and ship an update before the deadline that would otherwise stop new installs.
Yes, and that is a large part of what we do. We read the code first and give you a written account of its state before quoting anything — including the cases where a rewrite is cheaper than a rescue.
No. Android is the whole of our practice. If you need both platforms we will say so at the first call rather than take the work and subcontract it.
If you want the in-app support desk, tickets arrive with the device, OS version and app build already attached, and go to whoever you nominate. We can triage them or simply fix what gets escalated.
A brief, a repository, a half-finished build or just an idea on one page — all of it is a fine place to start.
Thank you — someone from Bor Group will get in touch shortly to talk through what you need.
This site uses cookies for analytics and advertising measurement, but only after you give your consent. Learn More