Remote Android studio, working in European hours

Tovarich Labs

We build Android apps, put them on Google Play, and keep shipping updates long after launch day.

Start an enquiry See the work
  • Android only
  • Kotlin & Compose
  • Play Console releases

What we actually do

One platform, done properly

Android and nothing else. Kotlin, Jetpack Compose, one codebase that behaves the same on a flagship and on a four-year-old mid-range phone.

The Play release is our job

Listing copy, screenshots, signing keys, the data safety form, internal and closed test tracks, staged rollout. You do not learn the Play Console to launch.

Updates keep coming

A build is not finished when it is live. Crash and ANR reports get triaged, regressions get fixed, and the app keeps up with new Android versions and target API deadlines.

Everyday tools, not demos

Features people open on a commute: works offline, survives a rotated screen, does not ask for permissions it has no use for.

Support that lives in the app

A feedback route inside the app, messages read by the people who wrote the code, and answers that come back through the same screen the user sent them from.

How a build actually goes

Most Android projects go wrong in the same two places: the scope is agreed in adjectives, and the release is treated as an afterthought. We work the other way round.

The first thing we write is not code, it is a list of screens and what each one does when the network is gone. That list is the estimate. From there the app is built in short slices, and at the end of every slice there is an installable build on the internal test track — not a slide, not a mockup, the real thing on your own phone. If something reads wrong on a small screen, you find out that week instead of at launch.

Release engineering runs in parallel from day one: signing set up early, the store listing drafted while the features land, the data safety declaration written against what the code genuinely collects rather than what we hope it collects. Our own free app on Google Play goes through exactly the same pipeline, which is how we know where it bites.

What you can ask us for

Take one, or the whole run from idea to a live listing.

Most asked for

Android app build

From a screen list to a working app in your hand, built in short slices with a test build at the end of each one.

  • Screen-by-screen scope
  • Kotlin and Jetpack Compose build
  • Internal test track from week one
  • Offline behaviour defined per screen
Start an enquiry

Google Play release

Everything between a finished build and a live listing, handled by us in your Play Console account.

  • Listing copy and screenshots
  • Signing and app bundle setup
  • Data safety declaration
  • Staged rollout and rollback plan
Start an enquiry

Updates and maintenance

A standing release train so the app does not quietly rot between versions of Android.

  • Crash and ANR triage
  • Target API level upgrades
  • Dependency and library updates
  • Changelog written for real users
Start an enquiry

In-app support desk

User messages arrive inside the app, get answered there, and turn into tickets the build team can see.

  • Feedback screen inside the app
  • Replies delivered in-app
  • Reports folded into the backlog
  • Play Store review responses
Start an enquiry

Scope and estimate are written after the first conversation — we quote against a screen list, not a guess.

Working with us

  1. Tell us what the app should do

    A paragraph is enough. What the user opens it for, and what has to work when the signal drops.

  2. We turn it into a screen list

    Every screen, every state, named. That document is what we estimate against, and you keep it whether or not we build the thing.

  3. Build in slices, test on real phones

    Installable builds land on the internal test track as we go, so you are using the app while it is being written, not reading about it.

  4. Release, then keep shipping

    Staged rollout on Google Play, crash reports watched from the first hours, and the next update already scoped.

What you end up holding

When a project ends, nothing about it should live only on our machines. You get the repository with its full history, the signed app bundle and the keystore arrangement in writing, the CI configuration that produces a release build from a clean checkout, and owner-level access to the Play Console listing.

You also get the boring documents that decide whether the next developer can pick it up: the screen list kept current, the release checklist we actually follow, and notes on the decisions that look odd until you know why they were made. If you later move the work in-house or to another studio, that handover is a morning, not a negotiation.

We are a software studio, not a rights holder over your product. The app is yours from the first commit.

Tell us about the app

A couple of lines about what it should do is plenty to start.

  • A developer reads it, not a sales desk.
  • You get questions back first, then a screen list and an estimate.
  • No call needed unless you want one.

We use your details only to answer this enquiry. Privacy Policy