KOTLIN & COMPOSE MULTIPLATFORM CONSULTANCY

Fewer codebases. Better decisions.

Kotlin Multiplatform consulting for teams who keep owning their code.

Devolic does not take over your repo. We guide the decisions that are expensive to get wrong: what belongs in shared Kotlin, how to collapse the three codebases you are maintaining in parallel, and how to run a modern development process, including putting Claude and Codex to work on code review. Your engineers ship it. We make them faster at it.

Partner-led, with two engineering practices behind them, so a recommendation can be proven rather than asserted.

See the code we ship →
Compose Multiplatform running natively on Apple TV
Compose Multiplatform running natively on Apple TV, from the same UI code as the Android TV build.

SETTINGS.GRADLE.KTS

id("dev.sajidali.compose-tvos") version "1.4.2"

One Kotlin codebase, six targets

Apple TV is the one JetBrains does not ship. We do.

  • AndroidStable
  • Android TVStable
  • iOSStable
  • Apple TVOur plugin
  • DesktopStable
  • Web / WasmBeta
BUILT ONKotlinCompose MultiplatformGradle

The first team to run Compose Multiplatform natively on Apple TV, published on Maven Central and used in production today.

Years shipping Kotlin
10+Years shipping Kotlin
Clients advised
35+Clients advised
Projects delivered
100+Projects delivered
Code shared after migration
70%+Code shared after migration

WHY TEAMS CALL US

Does any of this sound familiar?

These are the six situations we are brought in for most often. If more than one of them is true, a two-week architecture review will pay for itself.

  • The same feature, built three times

    Android ships it, then iOS reimplements it, then the TV team does it again. Every bug gets fixed in three places, and the platforms drift apart between releases.

  • iOS is always a release behind

    One team is bigger, better staffed, or simply further along. Roadmap dates get set by whichever platform is slowest, and nobody wants to say so out loud.

  • A KMP migration that stalled

    You started sharing code, hit a boundary that did not want to move, and the shared module has been half-finished since. Now it is a third codebase rather than one fewer.

  • TV or a new platform is blocking a deal

    Sales needs Android TV, Apple TV, or desktop, and the estimate to build it natively is longer than the opportunity will wait for.

  • AI tooling is in the team, but not in the process

    Some engineers lean on Claude or Codex, some do not, and nobody has agreed what it is allowed to touch. Review quality is drifting in both directions.

  • Nobody can say whether KMP is the right call

    The team is split, the internet is full of confident opinions, and committing to the wrong answer costs a year. You want a straight assessment from someone who has shipped it.

FREE, TWO MINUTES

Not sure Kotlin Multiplatform is worth it for you?

Eight questions on your codebases, the platforms you owe and how your team works. You get a score and a straight read, with no email required to see it. It can come back telling you not to bother, and sometimes it does.

YOUR RESULT

78/100

Strong fit

“You are paying for duplication that Kotlin Multiplatform is designed to remove...”

WHAT WE DO

Five ways we help

Every engagement is some combination of these. Pick one to see what it covers.

“Is Kotlin Multiplatform right for us, and what would it cost?”

KMP Architecture & Decision Support

Should you adopt Kotlin Multiplatform at all, and where should the line between shared and native sit? We answer that before you commit.

WHAT YOU GET

  • A read of your existing Android, iOS and shared code
  • Where the shared/native boundary should sit, and why
  • Module structure and the order to migrate in
  • An effort and risk estimate you can budget against
What this looks like in practice →

WHY DEVOLIC

Why teams bring us in

Kotlin Multiplatform is easy to start and expensive to get wrong. Teams bring us in to decide what to share, to collapse the codebases they are maintaining in parallel, and to modernise how the work gets done. We advise and review; your engineers stay the ones shipping.

The same feature, three times, versus one shared coreTODAYAndroidthe same feature, againiOSthe same feature, againTVthe same feature, againThree teams. Three bugs. Three fixes.Consolidate what can be sharedOne Kotlin coreBusiness logic and Compose UI, written onceAndroidAndroid TViOSApple TVDesktopWeb

  1. Advice From People Who Have Actually Shipped It

    When JetBrains had no tvOS target, we built one: a fork of compose-multiplatform-core and a Gradle plugin that adds Apple TV to an existing Compose project in a single line, published on Maven Central. We are not reading you the documentation. We tell you where Kotlin Multiplatform genuinely holds up and where it does not, because we have hit both edges.

  2. Fewer Codebases, Not More Contractors

    Most teams we meet are paying to build the same feature three or four times. We map what can be consolidated into shared Kotlin, sequence the migration so nothing stops shipping, and hand your team a plan they can execute. The measure of the engagement is how much duplication is gone, not how many hours we billed.

  3. We Modernise the Process, Not Just the Code

    A shared codebase only pays off if the workflow around it keeps up. We help teams put Claude and Codex to real use in code review, refactoring, and migration work, and tighten the CI, branching, and release habits underneath. The goal is a team that moves faster after we leave.

Where the advice comes from

We are consultants, not a build shop, so our proof is our own work rather than a portfolio of client apps. These are open source, in production, and free for anyone to read.

Compose Multiplatform on Apple TV

Compose Multiplatform on Apple TV

JetBrains ships no tvOS target, so we added one and published the whole stack to Maven Central. This is Google's JetStream TV sample running natively on Apple TV from the same Compose code as the Android TV build. It is the reason teams trust our advice on how far shared UI can actually go.

SOURCETHE PLUGIN

Compose EPG Viewer

Compose EPG Viewer

A programme guide that stays at 60fps with 10,000+ channels, by virtualising the viewport instead of composing the whole grid. Roughly 50,000 composables down to 500. When we tell a client their shared UI can carry the hard screens, this is the work behind that claim.

SOURCE

How it works

01Tell us where you are

How many codebases are you maintaining, which platforms do you owe, and where does the team keep losing time. Our NDA covers you from the first message.

02Architecture review

A working session with your engineers, not a sales call. We read the code, map what can be shared, and say plainly what Kotlin Multiplatform will and will not fix for you.

03A roadmap you own

A written plan: module boundaries, migration order, target platforms, and the workflow changes worth making. It is yours to execute with or without us.

04We guide the first migration

Your team moves the first bounded piece into shared Kotlin while we review, pair, and unblock. Once they have done one, they can do the rest without us.

HOW WE WORK TOGETHER

Three ways to engage us

Every engagement is led by a partner and staffed from the practice behind them. Most clients start with a review and only continue if the answer warrants it: there is no obligation to take the next step, and no retainer required to get one.

Architecture Review

2 to 3 weeks, fixed scope

The starting point for most clients. We read the codebase, talk to your engineers, and tell you plainly whether Kotlin Multiplatform is worth it for your product.

  • Codebase and architecture assessment
  • Working sessions with your engineers
  • A written recommendation with trade-offs
  • Module boundaries and migration order
  • Effort and risk estimate you can take to a budget holder

A decision you can defend, including a clear no if that is the honest answer.

Who runs it: Sajid and the Multiplatform Engineering practice, who spike the questions the code cannot answer on its own.

MOST COMMON

Migration Guidance

3 to 6 months, alongside your roadmap

We guide the consolidation while your team does the work. One bounded piece moves first and proves itself in production before the shared surface widens.

  • Everything in the Architecture Review
  • Pull request review while conventions are setting
  • Pairing on the parts nobody wants to touch
  • CI, Gradle, and release pipeline setup
  • AI-assisted workflow for the repetitive migration surface

Duplication measurably gone, and a team that has done it once and can do the rest.

Who runs it: Both practices: Multiplatform Engineering on the shared client, Backend, Web & Cloud on everything it talks to.

Ongoing Advisory

From $1,500/mo, cancel anytime

A standing line to our engineers once you are running. Kotlin and Compose move quickly, and a codebase two versions behind cannot adopt the next platform.

  • Scheduled architecture reviews
  • Version and dependency upgrade planning
  • A second opinion on the decisions that deserve one
  • New platform targets as you need them
  • A shared Slack or Teams channel, no ticket queue

The shared codebase stays current instead of quietly ageing out.

Who runs it: The partners directly, with either practice pulled in when a question needs more than an opinion.

BEFORE YOU ASK

Questions we get on the first call

Do you write our code for us?

No. We are consultants, not an outsourced build team. Our partners each lead a practice of engineers, and they do build things during an engagement: spikes and prototypes that prove a recommendation before you commit to it. But your production code stays yours. That is deliberate. If we wrote it, you would need us to maintain it.

What if Kotlin Multiplatform turns out to be wrong for us?

Then we tell you that, and the Architecture Review has done its job. We have advised clients against adopting it where the shared surface was too thin to justify the migration cost. A clear no in three weeks is far cheaper than the wrong yes over a year.

We already started a migration and it stalled. Can you help?

That is one of the most common reasons teams call us. Usually the boundary was drawn in the wrong place, or a platform-specific concern leaked into shared code. We work out where it went sideways and sequence the recovery so you are not starting over.

How much of our UI can actually be shared?

It depends on your surfaces, and anyone who answers that without reading your code is guessing. In practice our clients run 70%+ of their code shared, including the Compose UI. We will tell you which screens are safe to share and which still earn a native implementation.

What does the AI-assisted development work involve?

Putting Claude and Codex where they genuinely pay off: first-pass pull request review, the repetitive surface of a migration, and test coverage on code that never had any. Equally important is where to hold them back, and what review discipline stays human. We set up the guardrails and conventions with your team.

Do we need to stop shipping during a migration?

No, and we would push back if a plan required it. We move one bounded piece of the domain at a time, prove it in production on every target, then widen the shared surface release by release. There is no big-bang rewrite waiting at the end.

How do we know you have actually done this?

Because you can read the work. When JetBrains shipped no tvOS target for Compose Multiplatform, we built one and published the whole stack to Maven Central. That, our EPG and player libraries, and the JetStream port are all open source and linked from the Open Source page.

Where are you based, and how do you work with teams?

We are distributed across the US and Pakistan, and we work remotely with overlap into both US and European hours. Engagements run over your existing tooling: your repo, your CI, your tracker.

Tired of Building the Same Feature Four Times?

Tell us where your codebase is today.

Separate Android and iOS teams, a Flutter app you have outgrown, or a KMP migration that stalled. Fill out the form below and we'll set up an architecture review with our engineers.