Kotlin development services
Kotlin engineering for Android, the server, and every platform in between
· Average time to first merged PR: 12 to 15 days
Most Kotlin vendor pages read like a product brochure and leave the buyer with the same three questions: what will my engineers actually do on a Tuesday, what will it cost, and how do I know this will not become yet another procurement mistake. This page is the answer.
Siblings Software is a small Argentine firm that has been staffing Kotlin product teams since the JetBrains blog post announcing Kotlin 1.0. We build Android apps, server-side services and Kotlin Multiplatform modules, and we migrate aging Java code into something people enjoy reading again. No dashboards of fake metrics, no rewrite pitches you cannot afford.
Who actually hires a Kotlin team from us
Four buyer profiles account for most of our Kotlin engagements.
Product teams whose Android app has aged into a liability
Started in Java around 2016, moved to Kotlin piecemeal, still has a Fragment that nobody will touch. RxJava everywhere, Compose nowhere, AsyncTask occasionally. You want Jetpack Compose, coroutines and a CI that does not take twenty-four minutes, and you want it without a six-month rewrite.
Startups building an Android-first product from scratch
Seed or Series A. A designer with Figma flows, a founder who has been burned by native vs hybrid once already, and a deadline set by the board rather than the backlog. You want a squad that will ship a Jetpack Compose app with a Ktor backend and a clear seam for an iOS client via Kotlin Multiplatform later.
Scale-ups modernising a Spring Java backend
A Spring Boot monolith from the mid-2010s, written in Java, now carrying fifteen microservices grafted on the side. Leadership wants less boilerplate, saner concurrency and faster onboarding, without a stop-the-world rewrite. You want Kotlin engineers who can introduce idiomatic Kotlin and coroutines one bounded context at a time.
Teams evaluating Kotlin Multiplatform before committing
Two mobile apps, two separate teams, two different bugs for the same rule. Your CTO has read the KMP case studies and wants an honest proof of concept, not a marketing deck. You want engineers who have shipped real KMP in production and can tell you, on day 20, whether it is worth expanding or whether the domain is not ready for it.
If none of those describe you, we will still take the call, and say so in the first fifteen minutes if we are not the right fit.
What Kotlin engineers do day-to-day
Most service pages stop at “we do Android and Spring.” That is not enough to decide whether to hire a team. The scope below is what a typical Kotlin engineer works on in a given sprint. The mix shifts per engagement, but rarely is it fewer than four of these areas.
Native Android apps with Jetpack Compose
Compose-first UI, MVVM with StateFlow, navigation with type-safe arguments, DI with Hilt, persistence with Room and DataStore. Offline-first where the product needs it, not because someone read a Medium post. Play Billing, push notifications with Firebase, App Links, proper WorkManager usage for background tasks. Accessibility checked by TalkBack, not by checklist.
Server-side Kotlin that Java teams can read
Spring Boot, Ktor or Micronaut depending on what the rest of the org runs. Exposed, jOOQ or R2DBC for typed database access. Suspending controllers where WebFlux made reactive code unreadable. Idiomatic DSLs for routing and JSON. Tests that use Kotest or JUnit 5 instead of inheriting a 2014 base class.
Kotlin Multiplatform where it pays for itself
Shared domain, serialization, networking and storage layers across Android, iOS, backend and sometimes web. Kotlin Multiplatform is not a silver bullet. We advise clients to start with the business logic layer, stay native for UI until Compose Multiplatform is clearly the cheaper option, and measure build times honestly instead of assuming they will stay low.
Coroutines and Flow without leaked scopes
Structured concurrency as the default mental model, not an afterthought. Cold flows for data streams, StateFlow for UI state, SharedFlow for events, and cancellation boundaries that survive configuration changes. We lean on the official Kotlin coroutines guide as the common reference during reviews, not stale Stack Overflow answers from 2019.
Testing and CI with quality gates that bite
JUnit 5 or Kotest for unit, MockK for test doubles, Turbine for flow assertions, Roborazzi or Paparazzi for screenshot regressions, Espresso or Compose Test for UI. Detekt and ktlint as CI-blocking rules. Gradle remote build cache so the pipeline does not become the slowest part of your day. Flaky tests are triaged, not retried-until-green.
Migration from Java without freezing the roadmap
We do not pitch rewrites. We enable Kotlin next to Java, rely on the two-way interop that actually works, and convert modules in order of risk-vs-value. Callbacks become suspend functions when the call site is ready, not when a script runs. By the time the migration is “done”, most of the product team has forgotten it was happening. Details are in the migration path section below.
Every senior we place has shipped at least one Kotlin codebase to production and migrated at least one Java module into idiomatic Kotlin. Most have both, across fintech, health, retail, logistics and media.
Engagement models and what they cost
We publish ranges because hidden pricing wastes everyone’s time. The final number depends on seniority mix, English fluency (some buyers pay a premium for engineers who are comfortable facing their own stakeholders directly), and whether you need specialists such as a staff-level Android architect or a KMP engineer with shipped iOS targets.
Kotlin specialist
One senior engineer embedded in your team. Good when the engineering org is solid and you need one more pair of hands who already knows idiomatic Kotlin. Pairs with your team on the hardest parts, owns one slice of the codebase — usually the Android module or a backend service — and attends your stand-ups.
Price: USD 7,500 to 11,500 per month. Minimum: 3 months.
Product squad
Three to five engineers (senior and mid mix) with a tech lead, QA automation and part-time DevOps. Delivers features, owns the design system or the backend slice, keeps the CI honest. Works well alongside our dedicated Kotlin development team page for scope references, or combined with our Android development or Java development services when the stack calls for a mixed team.
Price: USD 22,000 to 40,000 per month. Minimum: 4 months.
Migration and hardening squad
Two to four engineers focused on a bounded goal: convert a Java backend to Kotlin, modernise a legacy Android app to Compose, or retire a specific class of production bug. Often runs alongside your feature team, not instead of it. Hands over when the scorecard is green.
Price: USD 15,000 to 28,000 per month. Minimum: 3 months.
Numbers assume 40-hour weeks and include recruiting, benefits, laptops and local taxes. Third-party services — Firebase, Sentry, Datadog, Play Console, App Store Connect — stay on your accounts so you keep control of data and billing.
The Java-to-Kotlin migration path we actually use
Full rewrites get pitched in sales decks and rarely survive contact with a roadmap. What works is incremental: the codebase stays green, the product team keeps shipping features, and Kotlin spreads module by module until the last Java class is a thin wrapper around a shipping dependency.
- Baseline audit (week 1). We catalogue the hotspots, circular dependencies, Rx-to-coroutine seams and boundaries that leak platform types. The output is a risk map per module: what to convert first, what to quarantine behind an interface, and what to leave alone until the end.
- Gradle toolchain and interop (week 1–2). Unified Gradle setup with the Kotlin plugin, kapt or ksp where annotations live, shared Detekt and ktlint configs, and a remote build cache that keeps CI under ten minutes. No language-level migration yet — the point is to make the two languages coexist without friction.
- Module-by-module conversion (week 2–10). Utilities first, then domain, then UI. Each module gets a pull request that converts the sources, renames nothing external, and keeps the public API stable. Tests are converted with the module. The IntelliJ Java-to-Kotlin converter is the starting point, not the finish line.
- Coroutines and null-safety tightening (week 8–12). Callbacks become
suspendfunctions. Rx chains become flows where the consumer benefits. Platform types (String!) get replaced by explicit nullable or non-nullable types at the interop seams. This is where latent bugs surface; that is expected, not a regression. - Legacy removal (week 10–14). The remaining Java classes are either wrappers around shipping libraries, generated code, or modules nobody should touch. We document which is which, retire what can be retired, and leave a clear map of what stays Java on purpose.
Timelines above are for a 30,000 to 100,000 line codebase. Bigger multi-repo estates mostly extend step 3. Android apps follow the same shape, with Compose adoption replacing the “UI” conversion phase. We have not seen a migration that required stopping feature work, and we would push back if a client asked for one.
Kotlin with us vs freelancer, in-house or generic offshore
Most prospects have already tried at least one alternative. Here is an honest comparison. If a row does not match what you have seen, say so on the first call and we will adjust.
Where a freelance Kotlin developer wins
Scoped tasks. A Compose animation that nobody can get quite right. A one-off conversion script. A Play Billing or App Check integration with a clean spec. If the work is under roughly 80 hours and the boundary is well defined, a specialist freelancer is usually cheaper and faster.
Where a freelancer hurts
Continuity. They juggle three other clients, take holidays without warning, and rarely do the unglamorous work that keeps a Kotlin codebase healthy: Gradle upgrades, Compose stability audits, coroutine leak hunts, Detekt rule tuning. You ship tickets fast and the platform rots in parallel.
Where an in-house hire wins
Long-term ownership. If Kotlin is central to your product for the next five years and you can afford a four-month search, a full-time senior is irreplaceable. Plenty of our clients start with us, see what “good” looks like, and then hire internally. That is a healthy outcome.
Where in-house hurts
Funnel risk and regret cost. Senior Kotlin engineers in US and UK markets take three to four months to close, with high offer-rejection rates. If the hire turns out wrong at month six, you are looking at severance, not notice. Meanwhile the roadmap stalls and the Android app ships with a placeholder banner.
Where large offshore agencies win
Warm bodies at low rates when the work is genuinely generic: internal tools, CMS skins, data-entry Android apps for a field team. If the brief really is “give me ten Kotlin developers and assign them tickets”, they are built for it.
Where large offshore agencies hurt
The engineer in the interview is rarely the one in the commits. Timezone overlap with the US tends to be two to four hours. Compose, coroutines and KMP work get treated as extra scope rather than defaults. Notice periods of 30 to 90 days make ramp-down painful.
Where we fit in
Between the two. Small, senior, full-time employees in a timezone that overlaps a full US business day. You interview the exact engineer who will write your code. Compose, coroutines, Detekt, CI hygiene and accessibility are part of the default scope, not an upsell. Minimum commitments are three to four months, not a year.
For narrower gaps, our Kotlin staff augmentation service is usually the better fit — same engineers, different commercial model.
Real Kotlin scenarios we see repeatedly
These are composites from recent engagements. Details anonymised, numbers rounded, but the shapes are accurate. They are here because buyers usually want to know whether their situation is something we have dealt with before.
Scenario A — the Android app stuck on RxJava and Fragments
Context. US retail app, 220,000 lines of mostly Kotlin, still using RxJava everywhere, a navigation graph that nobody trusted, and a test suite that took 38 minutes. Crash-free sessions hovered at 98.1% on a quarter-on-quarter downward trend.
What we did. Three-person modernization squad alongside the internal team. Replaced the home and checkout screens with Compose, migrated Rx chains to Flow and StateFlow feature by feature, introduced Turbine for flow assertions and Roborazzi for screenshot tests. No features paused.
Outcome. In thirteen weeks we shipped Compose across the three top-revenue screens. Crash-free sessions climbed to 99.4%, CI time fell from 38 minutes to 14, and onboarding a new Android engineer dropped from five weeks to eight days.
Scenario B — the startup that needed Android and backend shipped together
Context. Series A healthtech in London. Figma ready, no mobile engineers, a Postgres schema the CTO had sketched herself. Investors expected a working product in a quarter, covering clinician scheduling and patient chat.
What we did. Two Android engineers plus one backend engineer. Jetpack Compose for the app, Ktor with Exposed on the backend, shared serialization models in a Kotlin Multiplatform module so the schema could not drift. Firebase Auth and FCM for identity and push.
Outcome. Thirteen weeks to a production app with clinician scheduling, chat, file uploads and a care-team dashboard. When they later hired their first full-time Android engineer, he merged his first PR in six days because the module boundaries were clean.
Scenario C — the Spring Java monolith nobody wanted to touch
Context. European logistics group. Spring Boot 2 monolith in Java, 450,000 lines, twelve internal engineers, and a story about someone who once tried to run mvn clean install on a Friday. The CTO wanted Kotlin and coroutines, the CFO wanted no downtime.
What we did. Four-person squad over six months. Split the monolith’s hottest bounded contexts (pricing, dispatch, invoicing) into Kotlin modules, introduced suspending controllers, replaced a bespoke thread-pool with structured concurrency, and taught the internal team to hold the line in code review.
Outcome. p99 latency on the pricing endpoint dropped 41%. Lines of code in those three contexts fell by roughly a third. The Java modules that stayed Java did so on purpose, and the team can finally tell you why.
Scenario D — the KMP proof of concept that needed an honest answer
Context. Media company with two native mobile teams and the same recommendation logic implemented slightly differently in each app. Leadership wanted Kotlin Multiplatform; the mobile leads were sceptical.
What we did. Two senior engineers for eight weeks. Moved the recommendation, analytics and feature-flag layers into a shared KMP module, kept UI native on both sides, and ran the module on iOS via a CocoaPod. Build time impact and binary size changes measured weekly.
Outcome. The shared module replaced roughly 14,000 duplicated lines. Feature parity bugs between iOS and Android dropped from four a month to roughly one a quarter. We recommended against pushing KMP into the UI layer for another twelve months — and put that in the final report.
Mini case study
How a logistics platform cut Android crash rate by 63% with a Kotlin modernization squad
Client. A Nordic logistics company running a driver-facing Android app (route planning, pickup confirmation, proof of delivery) in mostly-Kotlin since 2019. Around 180,000 lines, a five-person internal Android team, and a crash-free sessions metric that had been stuck at 97.8% for eighteen months.
Brief. Get the app onto Jetpack Compose and coroutines without pausing the quarterly roadmap, and leave the internal team able to continue the work on their own.
What we did. Three-person migration and hardening squad: one tech lead, two senior Android engineers. Week 1 was the audit — a risk map ranking 38 screens by conversion cost and crash frequency. Weeks 2 to 10, we converted eleven screens (login, home, route, pickup, delivery, proof-of-delivery, settings, and four admin screens), replacing RxJava with Flow and StateFlow as we went. Weeks 6 to 12 overlapped with background work cleanup: replacing three bespoke Service subclasses with WorkManager, moving a fragile JobScheduler pipeline onto coroutines with structured cancellation, and adding Turbine-based assertions for the background sync flows that had been the source of most Friday incidents. The internal team kept shipping features throughout; in the weekly ops review we watched crash-free sessions climb from 97.8% in week 1 to 99.3% by week 14.
Result after six months. Android crashes attributed to background work or state loss (the “why did the app forget my delivery” class) fell 63% year-over-year. CI time dropped from 28 minutes to 11. Onboarding for a new hire moved from “three weeks to feel safe” to “first PR in the second week”. The internal team took over the remaining screens at month six; we stayed on for one day a week in code review for another quarter.
Honest caveat. The first month felt slow. The audit does not produce demo-able features, and the client’s head of mobile had to hold the line internally when the product manager asked why there was nothing in the release notes. If you compare velocity in month one, we look worse than a freelancer. By month three the compounding started to show, and by month six nobody wanted to go back.
At a glance
Industry: Logistics / driver app
Engagement: 3-person squad, 6 months + review tail
Stack: Jetpack Compose, Coroutines, Hilt, Room, WorkManager, Ktor client
Crash-related incidents: −63%
CI time: 28 min → 11 min
Onboarding time: 3 weeks → 1 week
The risks of outsourcing Kotlin work, and how we handle them
Any vendor telling you outsourcing Kotlin is risk-free is either inexperienced or selling. Here are the four failure modes we see most often, and the specific controls we use against each.
Risk: the engineer looks strong on paper and stalls in week three
How we handle it. Vetting ends in a live pair session on a real Kotlin bug — a coroutine leak that only shows up under configuration change, a Compose recomposition loop, a suspend function misused in a Java call site — not a Leetcode puzzle. Two-week free replacement window. The account lead checks in with you on day 14 with one question: “if this were a full-time hire, would you keep them?” In the last 18 months we have swapped two engineers, both within the free window.
Risk: coroutines quietly leak scopes and flows stack up
How we handle it. Detekt rules for GlobalScope usage, missing cancellation points and blocking calls on dispatchers. Turbine-based assertions on every non-trivial flow. Structured concurrency is a review topic, not an afterthought, and we run a quarterly coroutine audit on any codebase we own end-to-end.
Risk: knowledge walks out when the engagement ends
How we handle it. Documentation is a line item, not a favour. Architecture Decision Records for non-obvious module boundaries, READMEs for every non-trivial Gradle setup, runbooks for production incidents, Compose previews as living documentation. If you end the engagement tomorrow, the internal team has a map, not a scavenger hunt.
Risk: the migration eats velocity and loses political air cover
How we handle it. A weekly scorecard with four numbers: modules on Kotlin, crash-free sessions or error rate for the services touched, CI time, and coroutine leak count from LeakCanary or equivalent. Those four numbers sit in the weekly ops review so that engineering progress is visible to people who do not read pull requests.
Why Siblings Software specifically
Decide based on facts, not slogans.
11+
Years staffing Kotlin teams
Founded 2014 in Córdoba, Argentina
60+
Kotlin engagements shipped
Android, server-side, KMP, fintech, health, logistics, retail
GMT-3
Argentina timezone
Full same-day overlap with US Eastern
We are deliberately small. There is no sales organisation chasing headcount. The founders — Javier Uanini still takes most discovery calls personally — review every engagement. Our engineers talk to clients directly from week one. That is the actual reason onboarding is fast: there is nobody in the middle translating requirements.
Things buyers usually get wrong when shopping for a Kotlin vendor: asking for an hourly rate before explaining the work (you will be quoted the lowest possible number, and the real cost will arrive as change orders later), assuming any Android developer who lists Kotlin on their CV knows coroutines and Compose to production depth (most do not), and believing that a bigger agency means more reliable delivery (in Kotlin product work, small and senior beats large and generic almost every time).
For context, the official Kotlin website is the baseline we teach against, and the Android developers Compose guide is the first reference we pin in any new repository. We attend KotlinConf when we can, we read the KEEP proposals, and we do not treat Kotlin as a nicer syntax on top of Java.
Frequently asked questions from buyers
Our standards
Kotlin treated like the main thing, not a nicer syntax on top of Java.
- Structured concurrency as the default. No
GlobalScope. Every coroutine lives under a scope that knows when to cancel. Flows are cold by default, state is aStateFlow. - Null-safety taken seriously at interop seams. Platform types (
String!) get pinned to nullable or non-nullable at the Java boundary, not left as a surprise for a future bug report. - Compose over XML for new screens, XML left alone when it is fine. We do not religiously rewrite working UI. We convert when there is a product reason.
- CI gates that bite. Detekt and ktlint block merges. Gradle remote build cache keeps the pipeline under ten minutes. Flaky tests get triaged, not retried.
- Written artefacts. ADRs for architectural choices. READMEs per module. Runbooks for production incidents. The handover is a file tree, not a call.
- Honest escalation. If the migration scoreboard slips, it says so in the weekly update, not three sprints later.
Talk to Siblings Software
Tell us about the codebase, the team and what you need. We reply within one business day, or say so if we are the wrong fit.