Povse GmbH

We build Android apps and publish them on Google Play — from the first installable build to the update you ship two years later.

Request a quote How we work
  • Android
  • Play Console releases
  • In-app support

What we actually do

Povse GmbH writes mobile applications and puts them in front of the people who will use them. In practice that means two things that are usually sold separately: the engineering — the code, the screens, the thing that has to work on a four-year-old handset with a weak connection — and the release work that follows it, which is the store listing, the signing key, the data safety declaration and the staged rollout.

We do not start with a design language or a brand workshop. We start with the sentence that explains why the app exists: what a person opens it to do, and how long that should take them. Everything in the first release is measured against that sentence. Features that do not serve it wait for the second release, where they are cheaper to add and easier to remove.

The result is the kind of app a person installs, uses on the first evening without being taught, and still has on the phone a year later. That is a narrow goal, and it is the one we are good at.

The work, in plain terms

Android builds that hold up on real devices

We test on handsets, not only on an emulator: older hardware, small screens, flaky networks, battery saver on. An app that is fast on a developer machine and slow in a train carriage is not finished.

Release management on Google Play

Store listing text and screenshots, the data safety form, app signing, internal and closed testing tracks, then a staged rollout you can halt. We handle the rejections and the resubmission if a review comes back.

Updates on a calendar, not on a panic

Target API level deadlines, new Android versions, dependency and SDK changes. We plan the compatibility work before the deadline forces it, so an update is routine rather than an emergency.

Support routed through the app itself

A feedback path inside the app that arrives with the device model, the OS version and the build number attached. Most reports are reproducible the same day because nobody has to ask what phone it was.

You keep the code and the keys

The repository, the signing key and the Play Console entry belong to you from the start. If you ever continue without us, another developer can pick it up from the documentation we leave behind.

What you can ask us for

Four pieces of work people come to us by name for. Scope and cost are written down before anything is built.

Most asked for

App build from scratch

An idea turned into an Android app that is on the store and in people's hands.

  • Scope session and written build plan
  • Android application, built in visible increments
  • Store listing text, screenshots and declarations
  • First public release and handover
Request a quote

Release and Play Console setup

For a finished app that needs to get out of the repository and onto the store properly.

  • App signing and key custody under your account
  • Data safety and content declarations
  • Internal and closed testing tracks
  • Staged rollout with a stop plan
Request a quote

Maintenance and updates

The longer half of an app's life, handled on a schedule instead of when something breaks.

  • Target API level and OS compatibility work
  • Dependency and SDK upgrades
  • Crash and ANR monitoring with fixes
  • Regular release cycle with changelogs
Request a quote

Takeover of an existing app

When the previous developer is gone and the build no longer runs on a clean machine.

  • Code and architecture review, written up
  • Build pipeline restored and documented
  • Signing and store access transferred to you
  • Prioritised backlog of what to fix first
Request a quote

Every engagement is quoted individually after the first conversation — there is no standard rate card on this page.

How an engagement runs

  1. You tell us what the app has to do

    One message with the purpose, who uses it and where the project stands today. You get questions back, not a brochure.

  2. We scope it and write the estimate down

    What belongs in the first release, what waits for the second, what we consider risky — with the cost and the time attached before any code is written.

  3. You get installable builds early

    The app lands on your own phone while it is still rough. Feedback on a running build is worth more than feedback on a mockup, and it is cheaper to act on.

  4. We publish and hand over the keys

    Listing, declarations, signed release, staged rollout. The Play Console entry and the signing key sit under your ownership from the day it goes live.

  5. We keep it current

    Updates on a planned cycle, support reports triaged with device data attached, and a note each release of what changed and why.

The part after launch is the longer part

Publishing an app is a day. Keeping it installable is years. Android moves underneath you: a target API level becomes mandatory, a permission changes meaning, a library is abandoned, a manufacturer ships a battery policy that quietly stops your background work. None of that is visible from the store listing, and all of it ends with a one-star review that says the app stopped working.

So we treat maintenance as the normal state of an app rather than an incident. Compatibility work is planned before the deadline, not after the warning email. Crash reports are read weekly and grouped, so a fix addresses a pattern instead of a single device. Support messages arrive from inside the app with the build number attached, which is why most of them can be reproduced the same day they arrive.

What you end up holding is not just a binary: a repository you own, a build that runs on a clean machine, release notes that explain each version, and a store entry registered to you. If you continue elsewhere one day, you can. That is the point.

Tell us about your app

A few lines about what it should do is enough to start a useful conversation.

  • Your message is read by the people who would build it, not by a sales desk.
  • You get questions first: purpose, users, platforms, what the first release must contain.
  • Then a written scope and an estimate — before any code is written.

Your details are used only to answer this enquiry. Privacy Policy