Skip to content

// project

The KMP toolkit family

Three decoupled repos so a new app starts at "write the feature".

The brief

The KMP toolkit family is three decoupled repos (kmp-toolkit, kmp-build-logic and kmp-app-template) instead of one "platform" repo, so that using one of them never means dragging the other two along. None of the three were designed up front: each exists because a second consumer needed something the first one already had, and extracting it once was cheaper than copy-pasting it again. The family is vendored into Doori, PaymentsLab-KMP, Candidai, Gaddi and this portfolio's own Compose Multiplatform twin via Gradle includeBuild, so a fix or a version bump lands once and every consumer picks it up on its own schedule.

What shipped

  • kmp-toolkit: 39 modules, each extracted the moment a second consumer needed the same logic, never designed as a "platform" up front, from the MVI core four apps build on to modules like store and bots-policy still finding their first consumer.
  • kmp-build-logic: 17 convention plugins here (22 authored across all repos). The AGP / Kotlin / Compose / test / lint / Firebase / Room / Koin setup written once and applied with one line.
  • kmp-app-template, the app shape the toolkit slots into: one shared Compose UI, a wired Splash → Login → Home nav scaffold, thin Android + Desktop shells, and a customizer.sh that renames the whole project in one command.
  • Consumed by Doori (13 of its 49 modules), PaymentsLab-KMP (29 of its 44), Candidai and Gaddi. The composition is the proof the extraction was real, not a library nobody uses.
Kotlin MultiplatformGradle convention pluginsCompose MultiplatformMIT
kmp-toolkit kmp-build-logic kmp-app-template Doori (sibling KMP app) PaymentsLab-KMP (sibling KMP app) Candidai (sibling KMP app) Gaddi (sibling KMP app) Active · MIT · vendored across 5 repos

// case study

The short version

The problem

Four separate consumer apps each needed the same MVI core, the same AGP/Kotlin/Compose build setup and the same starting app shape: building any of that per-app again would be exactly the copy-paste a platform team exists to prevent.

The decision

Split into three decoupled repos instead of one "platform" repo (kmp-toolkit, kmp-build-logic, kmp-app-template) so using one never drags the other two along, and extract a module only the moment a second consumer actually needs it, never ahead of demand.

The result

Five independent consumers (Doori, PaymentsLab-KMP, Candidai, Gaddi and this portfolio's own Compose Multiplatform twin) now vendor the family via Gradle includeBuild, which is the actual proof the extraction paid off rather than a library nobody uses.

5 repos vendoring this family

36

modules · kmp-toolkit

17

convention plugins here · 22 across the family

5

repos vendoring this family

19

gateway providers behind one abstraction

// design notes

How it works

kmp-toolkit: 39 modules, extracted, never designed

The library repo, 39 modules, each pulled out the moment a second consumer needed the same logic rather than sketched in ahead of demand. In active use: the MVI ViewModel core (Candidai, PaymentsLab-KMP, Doori, Gaddi), network and on-device AI (both in Candidai), security (PaymentsLab-KMP) and Doori's own operation-log offline-outbox. Still finding a first consumer: typed Result, device-integrity, a screen-state store (ScreenState/DecisionEngine, a different module from Doori's outbox), settings, app-shell, llm-chat and a secrets vault pattern, plus bots-policy, the generic ISMCTS search shell Gaddi's own AI engine is actually built from. It is the smaller of the two contracts described in the shared-foundation write-up: the tiny (State, Event) → Effects mvi-core base four apps build their reducer/store layer on.

kmp-build-logic: the setup written once

17 convention plugins live in this repo (22 authored across the whole family). AGP, Kotlin, Compose, test, lint, Firebase, Room and Koin configuration for a module is one line (apply the plugin) instead of a build.gradle.kts a new module has to get right from scratch. This is the other half of the shared foundation: the composite build every consumer app pulls in for its module wiring.

kmp-app-template: the shape a new app starts from

The third repo is the app shape the toolkit and build logic slot into: one shared Compose UI, a wired Splash → Login → Home nav scaffold, thin Android and Desktop shells, and a customizer.sh script that renames the whole project in one command. A new app starts at "write the feature", not at "stand up the module graph".

The composition is the proof

Doori consumes 13 of its 49 modules from the toolkit; PaymentsLab-KMP consumes 29 of its 44; Candidai and Gaddi draw on the same foundation. This portfolio's own Compose Multiplatform twin is built on kmp-app-template too, which is the reason that project's write-up can say the template carries a real four-target app rather than a hello-world, the same claim this family makes about itself, checked by a fifth independent consumer.

One MVI contract, four apps

Doori, PaymentsLab-KMP, Candidai and Gaddi are not four isolated demos: they share a build-wiring contract and a unidirectional-state contract, both written once in this family and pulled in as composite builds rather than re-derived per app. The discipline the toolkit exists to enforce is exactly what a platform team is supposed to bring to a codebase at scale: one seam, reused, instead of the same decision made differently four times.

// architecture

How it's built

Three repos, one seam each

// under the hood

Tech stack

kmp-toolkit

  • typed Result
  • MVI ViewModel core (State, Event) → Effects
  • network + security
  • on-device AI seam
  • device-integrity
  • operation-log offline-outbox (Doori)
  • screen-state store (ScreenState/DecisionEngine, no consumer app yet)
  • settings
  • app-shell
  • llm-chat
  • secrets vault pattern
  • bots-policy (Gaddi's ISMCTS shell)
  • 19-provider payment-gateway abstraction

kmp-build-logic

  • AGP
  • Kotlin
  • Compose
  • test + lint
  • Firebase
  • Room
  • Koin

kmp-app-template

  • Shared Compose UI
  • Splash → Login → Home nav scaffold
  • Android + Desktop shells
  • customizer.sh

Distribution

  • Gradle includeBuild
  • MIT license

next build

The Loopdown

Field notes from an engineer who writes: one war story, four channels, one branded card.

→
See how everything connects →

frequently asked

What does he do at Dice.tech?

SDE-2, Android & Product Owner at Dice.tech (June 2023 - Present), platform owner of the app behind 50k+ monthly active users (22k+ daily, platform owner at Dice.tech). See the source.

What did he do to improve GPS accuracy?

Took GPS accuracy to 95%: up from 50%, by predictive dead reckoning. See the source.

How did he reduce production crashes?

80% crash reduction: Crashlytics + structured concurrency fixes. See the source.

How much of the app is Jetpack Compose?

~87% of the UI layer: 455k of 523k UI-layer LOC, verified screen by screen against the legacy XML. See the source.

Where did he study?

B.Tech, Computer Science & Engineering, NIT Bhopal (MANIT) (2017 - 2021). See the source.

What is the Neev Consulting role?

Consulting Engineer, Platform & AI at Neev Consulting (April 2026 - Present). Built the LLM assistant layer of an ERPNext/Frappe consulting ERP: business-context resolution, capability discovery, and an AI capability gate that defaults OFF with a test proving it. Models client to project to PO to milestone to GST invoice to payment end to end. See the source.

What is Doori?

Doori: Offline-first mileage, travel & expense tracker on one Kotlin codebase across Android, iOS, Wear OS, watchOS & Desktop. See the source.

What is Gaddi?

Gaddi: A Hinglish social-deduction bluffing game of power, satire & second chances. Gaddi ke liye kuch bhi karega. See the source.

What is PaymentsLab-KMP?

PaymentsLab-KMP: An Integration Lab for the Android payments ecosystem: every gateway behind one abstraction, with a live look at what actually happens on each transaction. See the source.

What is Candidai?

Candidai: A native, multiplatform AI career-intelligence engine, and the open-source project it's built on. See the source.

Does he write, outside of code?

Yes: The Loopdown, his field-notes writing hub, where the recurring bug characters are named after real production incidents. See the source.

What's he like to work with?

Answered by his own teammates, not by him: see the EB Profiles, one question per member, in their own words. See the source.

Is he available, and how do I reach him?

Open to remote (worldwide / India) and hybrid in Pune / Bengaluru. Email siddharthpandalai990@gmail.com. See the source.

What has he contributed outside employer work?

Shared Kotlin Multiplatform libraries used across his own apps, plus merged upstream pull requests on career-ops: see the repos and the running count. See the source.

Has anything he's built shipped for real?

Yes: see the Play Store shelf for the apps that are actually live and installable, not just source. See the source.

What can I try on this site besides reading it?

Every route on the site, as a tile you can open: 3D builds, labs and canvases, not screenshots. See the source.