Servicios de desarrollo Kotlin
Ingeniería Kotlin para Android, el servidor y todo lo que hay en el medio
· Tiempo promedio hasta el primer PR mergeado: 12 a 15 días
La mayoría de las páginas de proveedores Kotlin parecen un folleto de producto y dejan al comprador con las mismas tres preguntas: qué van a hacer mis ingenieros un martes cualquiera, cuánto cuesta y cómo sé que no se va a convertir en otro error de compras. Esta página es la respuesta.
Siblings Software es una firma chica con base en Córdoba, Argentina, que viene armando equipos Kotlin desde el post de JetBrains anunciando Kotlin 1.0. Construimos apps Android, servicios server-side y módulos de Kotlin Multiplatform, y migramos código Java viejo a algo que las personas disfrutan leer de vuelta. Sin dashboards con métricas de vitrina ni promesas de rewrite que no te podés pagar.
Quién nos contrata para Kotlin
Cuatro perfiles de comprador cubren la mayor parte de los engagements.
Equipos con una app Android que envejeció mal
Empezó en Java por 2016, pasó a Kotlin por partes, todavía tiene un Fragment que nadie quiere tocar. RxJava en todos lados, Compose en ninguno, AsyncTask en algún rincón. Querés Jetpack Compose, corrutinas y un CI que no tarde veinticuatro minutos, y lo querés sin un rewrite de seis meses.
Startups que arrancan un producto Android desde cero
Seed o Serie A. Una diseñadora con flujos en Figma, un fundador que ya se quemó con nativo versus híbrido, y una fecha marcada por el board y no por el backlog. Querés una escuadra que entregue una app en Jetpack Compose con back-end en Ktor y una costura clara para sumar un cliente iOS con Kotlin Multiplatform más adelante.
Scale-ups modernizando un backend Java sobre Spring
Un monolito Spring Boot de mediados de la década pasada, escrito en Java, con quince microservicios agregados por afuera. El liderazgo quiere menos boilerplate, concurrencia más sana y onboarding más rápido, sin parar todo. Querés ingenieros Kotlin que puedan introducir corrutinas y código idiomático un bounded context por vez.
Equipos que evalúan Kotlin Multiplatform antes de comprometerse
Dos apps nativas, dos equipos distintos, dos bugs diferentes para la misma regla. Tu CTO leyó los casos de KMP y quiere una prueba de concepto honesta, no una presentación de marketing. Querés ingenieros que hayan puesto KMP en producción y que el día 20 te digan si vale la pena expandirlo o si el dominio no está listo todavía.
Si ninguno de esos perfiles te describe, igual tomamos la llamada, y te lo decimos en los primeros quince minutos si no somos el encaje correcto.
Qué hacen los ingenieros Kotlin en el día a día
La mayoría de las páginas de servicio se queda en “hacemos Android y Spring”. Eso no alcanza para decidir si contratar un equipo. El scope de abajo es lo que hace un ingeniero Kotlin típico en un sprint cualquiera. La mezcla cambia por engagement, pero rara vez son menos de cuatro de estas áreas.
Apps Android nativas con Jetpack Compose
UI primero en Compose, MVVM con StateFlow, navegación con argumentos tipados, DI con Hilt, persistencia con Room y DataStore. Offline-first cuando el producto lo necesita, no porque alguien leyó un Medium. Play Billing, push con Firebase, App Links, uso correcto de WorkManager para tareas en background. Accesibilidad probada con TalkBack, no con un checklist.
Back-end Kotlin que los equipos Java pueden leer
Spring Boot, Ktor o Micronaut, según lo que ya corre en la organización. Exposed, jOOQ o R2DBC para acceso tipado a la base. Controllers suspend cuando WebFlux volvía el código reactivo ilegible. DSLs idiomáticos para routing y JSON. Tests con Kotest o JUnit 5 en lugar de heredar una clase base de 2014.
Kotlin Multiplatform donde paga
Dominio, serialización, networking y storage compartidos entre Android, iOS, back-end y a veces web. Kotlin Multiplatform no es una bala de plata. A los clientes les recomendamos empezar por la capa de lógica de negocio, quedarse en UI nativa hasta que Compose Multiplatform sea claramente más barato, y medir los build times en serio en lugar de asumir que se mantendrán bajos.
Corrutinas y Flow sin scopes filtrados
Concurrencia estructurada como modelo mental por defecto, no como detalle técnico a último momento. Flows fríos para streams de datos, StateFlow para estado de UI, SharedFlow para eventos, y cancelaciones que sobreviven a cambios de configuración. Usamos la guía oficial de corrutinas como referencia en las revisiones, no una respuesta de Stack Overflow de 2019.
Testing y CI con puertas que muerden
JUnit 5 o Kotest para unit, MockK para doubles, Turbine para flows, Roborazzi o Paparazzi para regresiones visuales, Espresso o Compose Test para UI. Detekt y ktlint bloqueando merges. Caché remota de Gradle para que el pipeline no sea la parte más lenta del día. Los tests flakys se triagean, no se reintentan hasta que pase.
Migración desde Java sin frenar el roadmap
No vendemos rewrites. Activamos Kotlin al lado de Java, aprovechamos el interop bidireccional que funciona en serio y convertimos módulos por orden de riesgo-vs-valor. Los callbacks se vuelven funciones suspend cuando el call site está listo, no porque corrió un script. Para cuando la migración está “lista”, la mayoría del equipo ya se olvidó de que ocurría. El detalle está más abajo.
Cada senior que ponemos ya subió al menos un codebase Kotlin a producción y migró al menos un módulo Java a Kotlin idiomático. La mayoría hizo ambas, en fintech, salud, retail, logística y medios.
Modelos de engagement y cuánto cuestan
Publicamos rangos porque los precios escondidos hacen perder tiempo a todos. El número final depende de la mezcla de seniorities, fluidez en inglés (algunos compradores pagan un plus por ingenieros cómodos defendiendo su trabajo directamente con los stakeholders), y de si necesitás especialistas como un arquitecto Android staff-level o un ingeniero KMP con targets iOS ya en producción.
Especialista Kotlin
Un ingeniero senior embebido en tu equipo. Sirve cuando la organización de ingeniería está sólida y necesitás un par de manos más que ya conozca Kotlin idiomático. Hace pair en las partes difíciles, se hace cargo de una porción del código — el módulo Android o un servicio backend — y entra a tus stand-ups.
Precio: USD 7.500 a 11.500 por mes. Mínimo: 3 meses.
Escuadra de producto
De 3 a 5 ingenieros (mezcla senior y semi-senior) con tech lead, QA automation y DevOps part-time. Entrega features, se hace cargo del design system o del backend, mantiene el CI sano. Se combina bien con nuestra página de equipo dedicado Kotlin, o con los servicios de desarrollo Android o desarrollo Java cuando el stack pide una mezcla.
Precio: USD 22.000 a 40.000 por mes. Mínimo: 4 meses.
Escuadra de migración y hardening
De 2 a 4 ingenieros con un objetivo acotado: convertir un backend Java a Kotlin, modernizar una app Android a Compose o retirar una clase puntual de bugs de producción. Suele correr en paralelo con tu equipo de feature, no en su lugar. Cierra cuando el scoreboard está en verde.
Precio: USD 15.000 a 28.000 por mes. Mínimo: 3 meses.
Los números asumen semanas de 40 horas e incluyen recruiting, beneficios, laptops e impuestos locales. Servicios de terceros — Firebase, Sentry, Datadog, Play Console, App Store Connect — siguen en tus cuentas para que mantengas control de los datos y la facturación.
El camino de migración Java a Kotlin que usamos en la práctica
Los rewrites completos se venden en una presentación y rara vez sobreviven al contacto con un roadmap. Lo que funciona es incremental: el codebase queda en verde, el equipo de producto sigue entregando features y Kotlin se propaga módulo por módulo hasta que la última clase Java queda como un wrapper fino alrededor de una librería de terceros.
- Auditoría inicial (semana 1). Catalogamos hotspots, dependencias circulares, costuras entre Rx y corrutinas y bordes que filtran platform types. El resultado es un mapa de riesgo por módulo: qué convertir primero, qué aislar detrás de una interfaz y qué dejar para el final.
- Toolchain y interop (semana 1–2). Setup unificado de Gradle con el plugin de Kotlin, kapt o ksp donde vivan las anotaciones, configs compartidas de Detekt y ktlint, y una caché remota de build que mantiene el CI debajo de diez minutos. Todavía no hay migración a nivel de lenguaje — el objetivo es que los dos lenguajes convivan sin fricción.
- Conversión módulo por módulo (semana 2–10). Utilidades primero, después dominio, después UI. Cada módulo tiene un PR que convierte el código, no renombra nada externo y mantiene la API pública estable. Los tests se convierten con el módulo. El conversor de IntelliJ es el punto de partida, no el final.
- Corrutinas y null-safety (semana 8–12). Los callbacks pasan a funciones
suspend. Las cadenas Rx se vuelven flows cuando el consumidor se beneficia. Los platform types (String!) se pinean como nullable o non-nullable en los bordes de interop. En esta etapa aparecen bugs latentes; es esperable, no una regresión. - Retiro de lo legacy (semana 10–14). Las clases Java que quedan son o wrappers de librerías externas, o código generado, o módulos que nadie debería tocar. Documentamos cuál es cuál, retiramos lo que se puede retirar, y dejamos un mapa claro de qué queda en Java a propósito.
Los tiempos son para un codebase de 30.000 a 100.000 líneas. Ecosistemas multi-repo más grandes extienden la etapa 3. Las apps Android siguen la misma forma, con la adopción de Compose reemplazando la conversión de UI. No vimos migraciones que hayan requerido parar la entrega de features, y empujaríamos para atrás si un cliente lo pidiera.
Nosotros vs freelancer, in-house u offshore genérico
La mayoría de los prospects ya probó al menos una alternativa. Acá va la comparación honesta. Si alguna fila no coincide con lo que viviste, decínoslo en la primera llamada y ajustamos.
Dónde gana un freelance Kotlin
Tareas acotadas. Una animación de Compose que nadie saca bien. Un script de conversión puntual. Una integración con Play Billing o App Check con especificación clara. Si el trabajo son menos de 80 horas y el borde está bien definido, un freelance especialista suele ser más barato y rápido.
Dónde duele un freelance
Continuidad. Hacen malabares con tres clientes, se toman vacaciones sin aviso, y casi nunca hacen el trabajo aburrido que mantiene sano un código Kotlin: upgrades de Gradle, auditorías de estabilidad de Compose, caza de leaks de corrutinas, tuneo de reglas de Detekt. Podés entregar tickets rápido mientras la plataforma se pudre en paralelo.
Dónde gana un hire in-house
Propiedad de largo plazo. Si Kotlin es central a tu producto los próximos cinco años y podés bancarte una búsqueda de cuatro meses, un senior full-time es irremplazable. Muchos clientes empiezan con nosotros, ven cómo luce “bien” y después contratan in-house. Es un desenlace sano.
Dónde duele in-house
Riesgo de funnel y costo de arrepentimiento. Un senior Kotlin en mercados de Estados Unidos o Reino Unido lleva de tres a cuatro meses cerrar, con alta tasa de rechazo. Si el hire no funciona al sexto mes, lo que mirás es severance, no preaviso. Mientras tanto el roadmap se cae y la app Android llega con un banner placeholder.
Dónde ganan las agencias offshore grandes
Cuerpos disponibles a tarifa baja cuando el trabajo es realmente genérico: herramientas internas, skins de CMS, apps Android de carga de datos para equipo de campo. Si el brief es “dame diez devs Kotlin y asignáles tickets”, están hechas para eso.
Dónde duelen
El ingeniero que vi ste en la entrevista rara vez es el que escribe los commits. El solape horario con Estados Unidos suele ser de dos a cuatro horas. Compose, corrutinas y KMP se tratan como scope extra y no como defaults. Los preavisos de 30 a 90 días hacen dolorosa la salida.
Dónde entramos nosotros
En el medio. Chica, senior, empleados full-time en una zona horaria que se superpone con un día laboral completo en Estados Unidos. Entrevistás al ingeniero exacto que va a escribir tu código. Compose, corrutinas, Detekt, higiene de CI y accesibilidad son parte del scope por defecto, no un upsell. Los mínimos son de tres a cuatro meses, no un año.
Para huecos más chicos, nuestro servicio de refuerzo de equipo con desarrolladores Kotlin suele ser el mejor encaje — mismos ingenieros, distinta estructura comercial.
Escenarios Kotlin reales que vemos seguido
Son composiciones de engagements recientes. Detalles anonimizados y números redondeados, pero las formas son reales. Están acá porque los compradores suelen querer saber si su situación es algo que ya enfrentamos.
Escenario A — app Android atascada en RxJava y Fragments
Contexto. App de retail estadounidense, 220.000 líneas mayoritariamente en Kotlin, con RxJava en todos lados, un navigation graph en el que nadie confía y una suite de tests que tardaba 38 minutos. Crash-free sessions en 98,1% y cayendo trimestre a trimestre.
Qué hicimos. Escuadra de modernización de tres personas en paralelo al equipo interno. Reemplazamos home y checkout por Compose, migramos cadenas Rx a Flow y StateFlow feature por feature, incorporamos Turbine para assertions de flows y Roborazzi para tests de pantalla. No se pararon features.
Resultado. En trece semanas subimos Compose en las tres pantallas de mayor ingreso. Crash-free sessions trepó a 99,4%, el CI bajó de 38 a 14 minutos y el onboarding de un nuevo Android pasó de cinco semanas a ocho días.
Escenario B — startup que necesitaba Android y back-end juntos
Contexto. Healthtech Serie A en Londres. Figma listo, sin ingenieros mobile, un schema Postgres que la CTO había bosquejado. Los inversores esperaban un producto funcionando en un trimestre, cubriendo agenda de clínicos y chat de pacientes.
Qué hicimos. Dos Android y un backend. Jetpack Compose para la app, Ktor con Exposed en back, modelos de serialización compartidos en un módulo Kotlin Multiplatform para que el schema no se desincronizara. Firebase Auth y FCM para identidad y push.
Resultado. Trece semanas a un producto en producción con agenda, chat, subida de archivos y un dashboard para el equipo de cuidado. Cuando contrataron su primer Android interno, metió su primer PR en seis días porque los bordes de módulo estaban limpios.
Escenario C — el monolito Spring Java que nadie quería tocar
Contexto. Grupo logístico europeo. Monolito Spring Boot 2 en Java, 450.000 líneas, doce ingenieros internos y una historia sobre alguien que intentó correr mvn clean install un viernes. La CTO quería Kotlin y corrutinas, la CFO quería cero downtime.
Qué hicimos. Escuadra de cuatro durante seis meses. Sacamos los bounded contexts más calientes del monolito (pricing, dispatch, facturación) a módulos Kotlin, incorporamos controllers suspend, reemplazamos un thread-pool casero por concurrencia estructurada y entrenamos al equipo interno para sostenerlo en code review.
Resultado. La latencia p99 del endpoint de pricing cayó 41%. Las líneas de código en esos tres contextos bajaron cerca de un tercio. Los módulos que se quedaron en Java lo hicieron a propósito, y el equipo por fin podía explicar por qué.
Escenario D — la prueba de KMP que necesitaba una respuesta honesta
Contexto. Empresa de medios con dos equipos mobile nativos y la misma lógica de recomendaciones implementada de manera levemente distinta en cada app. El liderazgo quería Kotlin Multiplatform; los leads mobile estaban escépticos.
Qué hicimos. Dos seniors durante ocho semanas. Movimos las capas de recomendaciones, analítica y feature flags a un módulo KMP compartido, dejamos UI nativa en ambos lados y corrimos el módulo en iOS vía CocoaPod. Medimos impacto en build time y tamaño de binario semana a semana.
Resultado. El módulo compartido reemplazó unas 14.000 líneas duplicadas. Los bugs de paridad entre iOS y Android bajaron de cuatro por mes a uno por trimestre. Recomendamos no empujar KMP a la capa de UI durante los próximos doce meses — y lo pusimos en el reporte final.
Mini caso de estudio
Cómo una plataforma logística bajó un 63% la tasa de crashes de su app Android con una escuadra de modernización Kotlin
Cliente. Una logística nórdica con una app Android para choferes (planificación de rutas, confirmación de pickup, prueba de entrega) escrita mayormente en Kotlin desde 2019. Unas 180.000 líneas, equipo interno de cinco Android, y crash-free sessions estancado en 97,8% hacía dieciocho meses.
Brief. Llevar la app a Jetpack Compose y corrutinas sin pausar el roadmap trimestral, y dejar al equipo interno en condiciones de seguir la obra por su cuenta.
Qué hicimos. Escuadra de migración y hardening de tres personas: un tech lead y dos Android senior. La semana 1 fue la auditoría — un mapa de riesgo que ordenó 38 pantallas por costo de conversión y frecuencia de crashes. De la semana 2 a la 10 convertimos once pantallas (login, home, ruta, pickup, entrega, prueba de entrega, ajustes y cuatro pantallas de admin), reemplazando RxJava por Flow y StateFlow en el camino. De la semana 6 a la 12 hubo cruce con limpieza de background: tres Service personalizados pasaron a WorkManager, un pipeline frágil de JobScheduler se movió a corrutinas con cancelación estructurada, y agregamos assertions con Turbine en los flows de sync que eran la fuente de los incidentes del viernes. El equipo interno siguió entregando features; en la revisión semanal mirábamos crash-free sessions trepar de 97,8% a 99,3% para la semana 14.
Resultado a los seis meses. Los crashes atribuibles a background o pérdida de estado (la clase “por qué la app se olvidó de mi entrega”) cayeron 63% año contra año. El CI bajó de 28 a 11 minutos. El onboarding pasó de “tres semanas para sentirme seguro” a “primer PR en la segunda semana”. El equipo interno tomó los módulos restantes al sexto mes; nos quedamos un día por semana revisando código durante otro trimestre.
Caveat honesto. El primer mes se sintió lento. La auditoría no produce features para demo, y el jefe de mobile tuvo que sostener internamente al product manager cuando preguntaba por qué no había nada para el release note. Comparada mes 1 contra mes 1, nuestra velocidad parece peor que un freelance. En el mes tres empezó a notarse el interés compuesto y para el sexto nadie quería volver atrás.
De un vistazo
Industria: Logística / app para choferes
Engagement: 3 personas, 6 meses + cola de review
Stack: Jetpack Compose, Corrutinas, Hilt, Room, WorkManager, cliente Ktor
Incidentes de crash: −63%
Tiempo de CI: 28 min → 11 min
Tiempo de onboarding: 3 semanas → 1 semana
Los riesgos de tercerizar Kotlin y cómo los manejamos
Cualquier proveedor que te diga que tercerizar Kotlin no tiene riesgos es inexperto o está vendiendo. Estas son las cuatro formas de falla que vemos más seguido y los controles concretos que usamos contra cada una.
Riesgo: el ingeniero parece fuerte en papel y se frena en la semana tres
Cómo lo manejamos. El vetting termina en una pair session real sobre un bug Kotlin — un leak de corrutina que solo aparece en un cambio de configuración, un loop de recomposición en Compose, una suspend usada mal desde un call site Java — no con un acertijo de Leetcode. Ventana de reemplazo gratis de dos semanas. El account lead te consulta el día 14 con una pregunta: “si fuera un hire full-time, ¿te lo quedarías?” En los últimos 18 meses reemplazamos dos ingenieros, los dos dentro de la ventana gratis.
Riesgo: las corrutinas filtran scopes y los flows se apilan
Cómo lo manejamos. Reglas de Detekt para GlobalScope, puntos de cancelación faltantes y llamadas bloqueantes en dispatchers. Assertions con Turbine en cada flow no trivial. La concurrencia estructurada es un tema de code review, no una ocurrencia posterior, y corremos una auditoría trimestral de corrutinas en los codebases que tenemos end-to-end.
Riesgo: el conocimiento se va cuando termina el engagement
Cómo lo manejamos. La documentación es un ítem de trabajo, no un favor. ADRs para bordes de módulo no obvios, READMEs para todo Gradle no trivial, runbooks para incidentes y previews de Compose como documentación viva. Si cerrás el engagement mañana, el equipo interno recibe un mapa, no una búsqueda del tesoro.
Riesgo: la migración se come la velocidad y pierde el respaldo político
Cómo lo manejamos. Scoreboard semanal con cuatro números: módulos en Kotlin, crash-free sessions o tasa de errores de los servicios tocados, tiempo de CI y cantidad de leaks de corrutinas detectadas por LeakCanary o equivalente. Esos cuatro números viven en la revisión semanal de operaciones para que el avance sea visible para gente que no lee pull requests.
Por qué Siblings Software en particular
Decidí con hechos, no con slogans.
11+
años armando equipos Kotlin
Fundada en 2014 en Córdoba, Argentina
60+
engagements Kotlin entregados
Android, server-side, KMP, fintech, salud, logística, retail
GMT-3
Zona horaria Argentina
Superposición completa con la costa este de Estados Unidos
Somos chicos a propósito. No hay una organización de ventas persiguiendo headcount. Los fundadores — Javier Uanini todavía toma la mayoría de las discovery calls en persona — revisan cada engagement. Nuestros ingenieros hablan con los clientes directamente desde la semana uno. Esa es la razón real de que el onboarding sea rápido: no hay nadie en el medio traduciendo requerimientos.
Lo que los compradores suelen equivocarse eligiendo proveedor Kotlin: pedir una tarifa por hora antes de explicar el trabajo (te van a cotizar el número más bajo y el costo real llega como change orders más tarde), asumir que cualquier dev que lista Kotlin en el CV domina corrutinas y Compose a profundidad de producción (la mayoría no), y creer que más tamaño de agencia significa más entrega confiable (en producto Kotlin, chico y senior le gana a grande y genérico casi siempre).
Para contexto, el sitio oficial de Kotlin es la base con la que enseñamos, y la guía de Jetpack Compose es la primera referencia que fijamos en cualquier repo nuevo. Vamos a KotlinConf cuando podemos, leemos las KEEP y no tratamos a Kotlin como azucar sintáctica sobre Java.
Preguntas frecuentes de los compradores
Nuestros estándares
Kotlin tratado como lo central, no como azucar sintáctica sobre Java.
- Concurrencia estructurada como default. Nada de
GlobalScope. Toda corrutina vive bajo un scope que sabe cuándo cancelarse. Los flows son fríos por defecto y el estado vive en unStateFlow. - Null-safety en serio en los bordes de interop. Los platform types (
String!) se pinean como nullable o non-nullable en la frontera con Java, no se dejan como sorpresa para un bug report futuro. - Compose sobre XML para pantallas nuevas, XML tranquilo cuando ya funciona. No reescribimos por religión. Convertimos cuando hay una razón de producto.
- Puertas de CI que muerden. Detekt y ktlint bloquean merges. La caché remota de Gradle mantiene el pipeline debajo de diez minutos. Los tests flakys se triagean, no se reintentan.
- Artefactos escritos. ADRs para decisiones arquitectónicas. READMEs por módulo. Runbooks para incidentes. El traspaso es un árbol de archivos, no una llamada.
- Escalamiento honesto. Si el scoreboard de migración se desliza, lo decimos en el update semanal, no tres sprints después.
Contactanos
Contanos sobre el codebase, el equipo y lo que necesitás. Respondemos en menos de un día hábil, o te decimos si somos el encaje equivocado.