We build Android apps and keep them alive after launch — accounts, core features, sharing, store release, updates.
We R Inc. is a development studio with one specialism: Android. We write the app, we put it in the Play Console, and we are still there the week after it goes live, reading crash reports.
A typical piece of work runs the whole way through. The product gets scoped down to the screens a person really uses. Sign-up, sign-in, password reset and account deletion get built properly, because the store asks for them and because users notice when they are sloppy. The core features — the two or three things the app exists for — get the attention the rest of the industry spends on splash screens. Then sharing: share sheets, deep links that open the right screen, invites that survive a reinstall.
After that it is release work. Internal track, closed track, staged rollout, watch the numbers, widen it. Then the next version, because an Android app that stops being updated starts breaking on its own — new OS releases, new policy requirements, new devices.
Kotlin and Jetpack Compose, built against real devices rather than one emulator. You get the source, the signing setup and a build that installs.
Sign-up, sign-in, password reset, session handling and in-app account deletion — the flows Play checks for, wired to your backend or one we stand up.
Share sheets that produce something worth opening, links that land on the right screen, and invite flows that still work after the app is reinstalled.
Internal and closed tracks first, then a percentage rollout with crash and ANR rates watched before the number goes up.
Screenshots, feature graphic, description, content rating and the data safety form filled in to match what the code genuinely sends.
Photographs from the bench where the builds happen.
Pick the one closest to your situation — we scope the real thing after we talk.
An app from an idea and a few sketches to a published listing.
Dropped into an app that already exists.
Keeping a live app current instead of letting it rot.
For a finished build that still has to get out the door.
You inherited a codebase and nobody knows how it builds.
Scope, timeline and cost are written down after the first call, before anything is built.
A few lines about the app, who it is for, and whether anything exists yet. It is read by the person who would scope the work, not by a form inbox.
We ask the awkward questions early — accounts, data, who owns the backend — and send back a screen list, a sequence and what each part involves.
Every slice ends with an APK on your phone. You use it, you tell us what is wrong, we change it before the next slice rather than at the end.
Closed track, staged rollout, crash watch, then the handover pack: source, signing, store assets and the next version's list.
Android is not one device, it is a spread: old handsets on small memory budgets, new ones with aggressive battery killers, manufacturer skins that treat background work differently. An app that was written for one flagship and tested on an emulator will look fine in a demo and fall apart in the field.
So we keep the stack narrow and go deep on it. We care about the size of the download, what happens when the network drops mid-action, whether the back gesture does what a person expects, and whether anything still runs when the screen is off. We write the data safety declaration from the code, not from a guess, because that is the line that gets an app pulled.
The result is unglamorous and it is the point: an app that installs quickly, starts quickly, survives an OS upgrade, and can be changed six months from now by someone who is not us.
A couple of sentences is enough to start — we will come back with questions and a rough shape.
Thanks — someone from We R Inc. will get in touch shortly to pick this up.
This page uses cookies for analytics and advertising measurement, but only after you give your consent. Learn More