Next-generation software, shipping today.

Small, precise tools for the work you already do — each one takes a daily annoyance off your hands, does it quietly, and stays yours once you have it.

  • 7 shipped products
  • design + code
  • kotlin multiplatform
products shipped
7
years in Android
7+
open-source tools
4

New, for iPhone and Android.

tamatem is the studio’s focus timer. It is free to start, and its Premium tier is a subscription — the one product of ours that has one.

Free to use. Never a subscription.

Every app runs on your own machine and stays yours once you have it. One has a one-time Pro unlock. Nothing to cancel, ever.

Apps

Developer tools

The team you didn’t hire.

Hiring froze; the roadmap didn’t. One senior Android engineer with AI doing the routine code and a person making every call: Kotlin Multiplatform apps, SDKs, and the release work where a mistake costs real money.

Start here

KMP Readiness Audit

A senior read of your Android app before you commit a budget: what can be shared with iOS, what should stay native, and what getting there will cost.

  • A written report on your architecture, build and release setup
  • A module-by-module migration plan with milestones
  • A fixed quote for the build, if you want one

$2,500

5 days · fixed price

Book the audit
  • KMP apps — iOS & Android

    One Kotlin codebase, two native apps — and the call on what to share made by someone who has shipped both.

  • Compose Multiplatform

    One UI codebase across iOS, Android and desktop, adopted screen by screen so releases never stop for a rewrite.

  • SDK development

    Public Kotlin APIs other teams build on, where one breaking change lands on every customer at once.

  • Release engineering

    Signing, staged rollouts and the CI checks that stop a bad build — the work where one mistake reaches every user.

Five steps, no surprises.

  1. Listen

    You send what you are building and roughly when. The reply comes from the person who would do the work.

    you get a reply, not a sales desk

  2. Scope

    A call to pin the scope down, then a written plan with milestones — before anything is committed.

    you get a written plan with milestones

  3. Build

    Work lands in your repository as it is written, on your CI, to your review and testing standards.

    you get code in your repo from the first commit

  4. Ship

    Signing keys and store accounts in your name, staged rollouts, and the checks that stop bad builds.

    you get a release pipeline you own

  5. Keep going

    Longer product work runs month to month, and you can end it at the close of any month.

    you get a rolling monthly engagement

What we believe.

  1. One job per screen

    Each screen answers one question. The second question gets its own screen.

  2. Quiet by default

    The interface waits. Alerts are earned, and the gentle one is the default.

  3. Measured, not guessed

    Sizes, angles and colours come from a few constants, so every application measures the same.

  4. Yours from the first commit

    Code, keys and store accounts sit in your name from day one. There is no handover, because nothing was ever held back.

Answered before you email.

What kind of work do you take on?

Kotlin Multiplatform apps that ship on both iOS and Android, Compose Multiplatform for the shared UI, SDK and library development, and the CI, signing and release plumbing underneath. We do not take on web front-ends, brand and marketing design, or staff augmentation by the seat.

We are not hiring right now. Can you cover the work?

Yes, and that is most of what this studio is for. You get the output of a small team without adding headcount: one senior engineer, AI tools for the routine code, and every decision about architecture, releases and trade-offs made and reviewed by a person. Work is quoted as a fixed scope or a monthly engagement you can end at the close of any month, so it follows your hiring plan instead of fighting it.

How do you use AI on our code?

AI coding tools write routine code and tests, on settings where your code is not used to train their models. Every line is read by a person before it lands in your repository, and signing keys, store credentials and other secrets never go into an AI tool. If your company has its own AI policy, raise it at the scoping call and the plan is written to follow it.

How does a project start?

Send a short description of what you are building and roughly when you need it. You get a reply from the person who would do the work, not a sales desk, then a call to pin the scope down, then a written plan with milestones before anything is committed.

Fixed scope or ongoing?

Both. A defined deliverable — an SDK, a KMP module, a release pipeline — is quoted as a fixed scope with milestones. Longer product work runs as a rolling monthly engagement you can end at the close of any month. The one fixed public price is the KMP Readiness Audit: $2,500 for five days. Everything else depends on scope, so it is quoted after the scoping call rather than off a day-rate card.

Who owns the code, and when?

You do, and from the first commit rather than at the end. Work lands in your repository as it is written, on your CI, with signing keys and store accounts in your name — so there is no handover event, no escrow, and nothing the studio keeps a key to. Copyright in everything written for the project transfers to you on payment for that milestone; if we walk away mid-project you still hold every line already paid for.

What licences will we inherit with it?

Only ones you can live with, and you see the list before you own it. Dependencies are permissive by default — MIT, Apache-2.0, BSD — and anything copyleft that would reach a shipped binary is raised for your decision before it goes in, not discovered at review. Every build emits an attribution file listing each dependency, version and licence, generated from the lockfile on CI so it cannot drift from what actually ships. Where the studio reuses one of its own internal libraries, it comes to you under MIT: no component you licence back, and no dependency on us staying in business.

Can you work inside our existing codebase and team?

Yes. Kotlin Multiplatform and Compose Multiplatform land alongside your existing native code — shared modules first, CMP screens where you want them — so the app ships throughout rather than waiting on a rewrite. We work to your review and testing standards and hand over code your own team can maintain.

Why should we believe any of this?

Because you can check it before you email. Every product on this page is a download away and the developer tools are MIT on GitHub, so how we structure a project, handle failure and treat someone else’s data is readable in public — which is not true of a case study PDF.

Does the iOS app have to share its UI with Android?

No. Kotlin Multiplatform shares the code underneath: data, networking and business rules. Each screen can stay native, move to Compose Multiplatform, or mix the two, and which screens to share is decided at the scoping call and written into the plan with the milestones.

Can you build one SDK that both our iOS and Android customers embed?

Yes. SDK and library development is one of the things the studio takes on. A defined SDK is quoted as a fixed scope with milestones, written in your repository from the first commit, and you see its dependency licences before you own it. How it is packaged for each platform's integrators is set out in the written plan.

Can you set up our release pipeline without holding our keys?

Yes, and that is the only way it is done. CI, signing and release plumbing run on your CI, with signing keys and store accounts in your name, so the pipeline keeps shipping whether or not the engagement does. A release pipeline on its own can be quoted as a fixed scope.

Have something to build? Let’s talk.

Tell us what you are building and roughly when you need it. No discovery deck — a reply from the person who would do the work: a senior Android engineer with 7+ years shipping production apps.

or reach out on LinkedIn