Skip to content
Mobile Byte Sensei

Desktop software

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

Written response within one week. No preliminary sales call.

Typical engagement

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

Indicative, not a quotation.

Engagement terms

Overview.

Long sessions, large files, direct filesystem and hardware access. The category is widely underserved, which is why the tools still running in these workflows are often fifteen years old.

Much of this work replaces an existing application rather than starting from nothing, and the binding constraint is usually that its users cannot be retrained. Established working patterns are treated as a requirement, not as a legacy inconvenience.

What the work covers.

The capabilities desktop software engagements draw on. Scope is agreed per engagement, against the requirement.

  • Compose Multiplatform desktop apps

    Desktop applications on the JVM, built from the same Kotlin codebase as the mobile apps where one exists.

  • Native installers

    DMG packages for macOS, MSI installers for Windows and Linux packages, produced by the build pipeline.

  • Signing and certificates

    Apple distribution and installer certificates managed with Fastlane Match, with scheduled renewal checks.

  • Background work on the desktop

    Scheduling daemons for Windows, macOS and Linux behind the same API as mobile background work.

  • Desktop billing

    Subscriptions and purchases on desktop through the same billing library as mobile and web.

  • Developer tools and IDE plugins

    IntelliJ IDEA and Android Studio plugins built on the IntelliJ Platform.

  • Replacing legacy tools

    Running old and new applications in parallel until the replacement is proven on production data.

What you receive.

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

Handed over

  • Signed installers for each target operating system
  • Signing and notarisation, set up in your accounts
  • A migration plan covering data and workflow
  • Support documentation written for your users

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
  • Compose Multiplatform
Packaging and signing
  • Gradle native distributions
  • Fastlane Match
Developer tools
  • IntelliJ Platform SDK

How it is delivered.

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

  1. Step 1: Discovery

    Confirm the workflow needs the operating system; where it does not, we recommend a web platform.

  2. Step 2: Shared-core architecture

    Reuse domain code from existing mobile or web apps where it exists.

  3. Step 3: Build in increments

    Installers produced by CI from the first increment.

  4. Step 4: Signing and distribution

    Certificates, notarisation and distribution set up in your accounts.

  5. Step 5: Parallel run and migration

    Run alongside the legacy tool until the replacement is proven, then hold and improve.

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.

  • PayCraft

    Developer infrastructure

    Live

    Billing with one API across Android, iOS, web and desktop.

    • Android
    • iOS
    • Web
    • Desktop

Tooling we publish.

Where this is not the right fit.

Where a workflow fits in a browser, we recommend a web platform instead. Desktop distribution carries a real cost — signing, packaging and update infrastructure — and is justified only when it delivers something a browser cannot.

Questions on desktop software.

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

All questions

Native toolkit or web wrapper?

Chosen per project and documented. The desktop work MBS ships uses Compose Multiplatform, which shares code with Android and iOS; where another toolkit suits the requirement better, the reasoning is set out in writing.

Can the desktop app share code with our mobile app?

Yes, with Compose Multiplatform. MBS builds desktop targets from the same codebase as its mobile apps.

Which operating systems?

macOS, Windows and Linux, with installers for each produced from one build pipeline.

Who owns the signing certificates?

You do. They are managed in your developer accounts.

Can you replace a legacy tool without downtime?

Usually by running both in parallel for a defined period, with the existing tool authoritative until the replacement has been proven on production data.

Do you build IDE or developer-tool plugins?

Yes. MBS builds an IntelliJ IDEA and Android Studio plugin for its own Gradle tooling.

Other core services.

  • Mobile apps

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

  • 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.

  • 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 desktop software work and receive a written assessment, including an indicative estimate and the risks identified at this stage.

Or write to hello@mobilebytesensei.com