Skip to content
Mobile Byte Sensei

Mobile apps

Android and iOS apps, native or on a shared codebase where the product and the team justify one.

Request a proposal What you receive

Written response within one week. No preliminary sales call.

Typical engagement

Typical duration
4–8 months
Team
2–4 people
Starts with
Discovery sprint, then monthly
Entry billing
Fixed fee, 2–3 weeks

Indicative, not a quotation.

Engagement terms

Overview.

Mobile software is judged on the devices customers actually own, not on the devices used in design review. Offline operation is treated as a normal state rather than an error.

Whether the product warrants two native codebases or one shared codebase is decided with the client after scoping, not in advance. Kotlin Multiplatform is the right choice for some products and a net cost for others; the assessment and its reasoning are provided in writing.

What the work covers.

The capabilities mobile apps engagements draw on. Scope is agreed per engagement, against the requirement.

  • Shared-code apps

    Kotlin Multiplatform and Compose Multiplatform apps that share interface and domain code across Android and iOS, where the product justifies it.

  • Platform surfaces that stay native

    Android input methods and overlay surfaces, such as system keyboards and floating controls, built against the platform APIs they require.

  • Offline-first storage

    Local persistence with Room, SQLDelight and DataStore, so the app works without a connection and syncs when one returns.

  • Background work

    Scheduled and deferred work across Android, iOS and desktop through a shared API.

  • Billing and subscriptions

    Google Play Billing, StoreKit, and Stripe or Razorpay through webhooks, on MBS’s own open-source billing library.

  • Ads and reward economies

    AdMob placements, rewarded unlocks, soft currencies and feature gating.

  • App-platform plumbing

    Deep links, in-app updates and reviews, remote configuration, network monitoring, sharing and in-app support tickets.

  • Migration to Kotlin Multiplatform

    Incremental migration of an existing Android codebase, starting with an audit.

  • Store release

    Play testing tracks, TestFlight groups, Firebase App Distribution, store listings and compliance declarations.

What you receive.

What changes hands during the engagement, and remains yours after it.

Handed over

  • Source repository in your organisation from the first commit
  • Signed release builds, with the signing setup in your accounts
  • Store listings, metadata and compliance declarations
  • Play, TestFlight and Firebase testing tracks, configured
  • A CI pipeline that produces the release builds
  • An operational runbook your team can use independently

From the discovery sprint

2–3 weeks · Fixed fee

  • A written scope stating what is in and what is explicitly out
  • An estimate expressed as a range, with the assumptions behind it
  • A written risk register
  • A build plan in two-week increments
About the discovery sprint

Technologies in use.

Evidenced in our own products and tooling for this service. Where your team already runs a stack, the work proceeds within it.

Language and interface
  • Kotlin
  • Kotlin Multiplatform
  • Jetpack Compose
  • Compose Multiplatform
Architecture and data
  • Koin
  • Ktor
  • Ktorfit
  • Room
  • SQLDelight
  • DataStore
  • kotlinx.serialization
Backend services
  • Supabase
  • Firebase Analytics
  • Firebase Crashlytics
Monetisation
  • Google Play Billing
  • StoreKit
  • AdMob
  • PayCraft
Release
  • Fastlane
  • Firebase App Distribution
  • TestFlight
  • Detekt

How it is delivered.

The sequence an engagement follows, from the first assessment onward.

  1. Step 1: Discovery sprint

    A platform assessment, shared codebase or two native ones, with the reasoning in writing and a prototype of the core flow.

  2. Step 2: Foundation

    Repository in your organisation, CI, signing and testing tracks, set up before feature work starts.

  3. Step 3: Build in increments

    Two-week increments, each installed on your devices through an internal testing track.

  4. Step 4: Store submission

    Listings, compliance declarations and review handling.

  5. Step 5: Hold and improve

    Crash triage, OS and SDK upgrade cycles, and phased rollouts.

Evidence in our own work.

Products we engineered and operate under our own name, and tooling we publish. Client engagements ship under our clients’ names and are not listed.

  • ReelsDownloader

    Utility

    Live

    A Kotlin Multiplatform app on Google Play, with stories, a downloads library and subscription billing, alongside a web tool.

    • Android
    • Web

  • Healld

    Mental wellness

    Live

    A Kotlin Multiplatform wellness app on Google Play, with assessments, journeys and crisis-safety flows on a Supabase backend.

    • Android

  • Cappy

    Focus & wellbeing

    Live

    A focus companion on Google Play that works without an account, with local persistence and subscription billing.

    • Android

  • Hacker Keyboard

    Personalisation

    Live

    An Android system keyboard that renders themes behind the keys, with no network code in the keyboard process.

    • Android

Tooling we publish.

Where this is not the right fit.

This discipline is not suited to white-label rebranding of an existing application, or to engagements in which a design file is handed over and a build returned without collaboration. Both are legitimate ways to procure software; neither plays to our strengths.

Questions on mobile apps.

Commercial, ownership and engagement questions are answered on the FAQ page.

All questions

Native or cross-platform?

Decided after scoping, against your team and roadmap rather than a house preference. Our own apps use Kotlin Multiplatform where the domain is shared, and surfaces that belong to one platform stay native.

Can you take over an existing app?

Yes. A takeover begins with a paid two-week audit before either party commits, because inheriting a codebase without an assessment exposes both sides to avoidable cost.

What about the backend?

We build it, or integrate with an existing one. An app is rarely the whole product, and owning the integration boundary avoids disputes across it.

Who holds the signing keys and store accounts?

You do. Signing is configured in your accounts and handed over with the release builds.

Can you add billing or subscriptions to an existing app?

Yes. MBS maintains its own open-source billing and monetisation libraries for Kotlin Multiplatform and uses them in its own apps.

Can you migrate an Android-only app to Kotlin Multiplatform?

Yes, incrementally, starting with an audit of the existing codebase.

Other core services.

  • Games

    Casual and children’s games, from playable prototype through store submission and live operations.

  • Web platforms

    Dashboards, product sites and the data layers behind them, built to perform on a mid-range phone.

  • Desktop software

    Windows, macOS and Linux applications for workflows that do not belong in a browser.

  • Applied AI

    On-device speech and language models, and the evaluation work that decides whether a feature ships.

  • Design & planning

    Product definition, scope and interface design, delivered as a fixed-fee engagement.

  • Something else?

    Describe the requirement. Any other application or product is scoped against it.

Request a proposal.

Submit the requirement for mobile apps work and receive a written assessment, including an indicative estimate and the risks identified at this stage.

Request a proposal Something else? Describe the requirement.

Or write to hello@mobilebytesensei.com