Staff augmentation React Native
Desarrolladores React Native que tratan lo móvil como disciplina propia, no como un efecto colateral de saber React
· Tiempo promedio al primer PR: 12 días
Casi ningún equipo necesita otro desarrollador JavaScript que tocó React Native en un side project un sábado. Necesita a alguien que publicó en la App Store un domingo a la noche, debuggeó un gradle que se rompió tres horas antes del release y sabe cómo se ve un bundle Hermes atorado en producción.
Ese es el perfil que colocamos. Siblings Software es una firma chica de Córdoba, Argentina, que viene armando equipos móviles para empresas de EE.UU., Canadá, Reino Unido y España desde 2014. Esta página está pensada para que evalúes si somos el proveedor correcto: responde las preguntas que los compradores realmente hacen — tarifas, proceso, tradeoffs y dónde honestamente no somos la mejor opción.
Quién contrata desarrolladores React Native con nosotros
Cuatro perfiles de comprador explican cerca del 90% de los contratos.
Empresas de producto con una app que crece y un único lead móvil saturado
Tu equipo web es de cinco a quince ingenieros, pero mobile es una sola persona que arrancó la app y ya no da abasto. No necesitás otro par de manos — necesitás un ingeniero mid o senior que haga pair con tu lead, se haga cargo de un área de features y no lo arrastre a code reviews todo el día.
Startups con ronda cerrada para construir un producto móvil y sin CTO con ganas de contratar gente mobile
Clásica situación de seed extendida o Serie A. Los founders conocen el dominio, no Swift. Querés una squad chica capaz de tomar un Figma y un backend y transformarlo en una app publicada — con tiendas incluidas — en menos de cinco meses, sin tener que entrevistar durante tres meses.
Agencias y consultoras que vendieron un proyecto móvil y no quieren tener gente en banco
Ganás un proyecto móvil de alcance cerrado dos veces al año. Contratar gente React Native in-house implica pagarla entre proyecto y proyecto. Somos tu capacidad flexible — vos mantenés la relación con el cliente, nosotros metemos uno a cuatro ingenieros en tu squad.
Empresas consolidadas migrando un stack nativo viejo de iOS y Android
Tenés una app escrita en Objective-C en 2016 y una Android aparte que nadie quiere tocar. La dirección ya decidió que la respuesta es React Native, y ahora alguien tiene que hacer el trabajo — usualmente en paralelo mientras las apps viejas se siguen manteniendo. Hicimos esta migración cuatro veces y sabemos de antemano qué va a salir mal.
Si ninguno de esos escenarios te suena, igual hacemos la llamada de descubrimiento, pero es justo que te lo digamos en los primeros quince minutos si somos el proveedor equivocado.
Qué hacen realmente estos ingenieros, día a día
La versión corta es "lo que diga tu roadmap móvil." La versión larga vale la pena porque la diferencia entre un desarrollador React que usó React Native y un ingeniero móvil de verdad aparece acá.
Módulos nativos y el bridge
Escribir Swift o Kotlin cuando JavaScript se queda corto. Tickets típicos: envolver una librería biométrica que solo viene nativa, exponer una API BLE, pasar un frame de cámara por ML Kit sin copiarlo tres veces. Entienden el bridge viejo, la nueva arquitectura de TurboModules y cuándo conviene migrar.
Release engineering
Pipelines con Fastlane o Expo Application Services (EAS), higiene de certificados y perfiles de aprovisionamiento, lanzamientos por etapas, grupos de TestFlight, tracks de Internal Testing, y las llamadas que hacés cuando Apple vuelve a marcar 4.3 (a) un viernes. Trabajo aburrido. Crítico.
Performance y memoria
Medir con Flipper, React DevTools Profiler, Xcode Instruments y Android Profiler. Arreglos habituales: cambiar FlatList por FlashList en listas densas, mover la decodificación de imágenes fuera del hilo JS, memoizar selectors, cazar memory leaks en módulos nativos y bajar el cold start a menos de dos segundos en Android de gama media.
Offline-first y sincronización
La mayoría de las apps serias tiene que funcionar en el subte. Eso significa almacenamiento local (MMKV, WatermelonDB, SQLite), resolución de conflictos cuando el usuario vuelve online y sincronización en segundo plano que sobreviva las restricciones del SO. Rara vez lo piensan los desarrolladores React que vienen de la web antes de la semana tres.
Diferencias de plataforma que muerden
Límites de payload de push, ventanas de background en iOS, Doze mode en Android, las tres maneras distintas en que funcionan los deep links, casos raros de WebView, manejo de teclado que es genuinamente distinto entre plataformas. Nada glamoroso, pero cada uno es media jornada de bug hunt si el ingeniero no lo vio antes.
OTA updates sin romper producción
Expo Updates, CodePush o EAS Update para mandar fixes de JS sin revisión de tienda. Los usamos, pero también sabemos cuándo Apple considera que un OTA equivale a una resubmission de la app bajo las App Store Review Guidelines. La línea es real.
Todo desarrollador que colocamos publicó al menos una app React Native de punta a punta en las dos tiendas. Esa es la vara mínima. La mayoría publicó tres o más, en fintech, salud, retail y medios.
Modelos de contratación y cuánto cuestan
Publicamos los rangos porque la tarifa secreta pierde el tiempo de todo el mundo. El número final depende de la seniority, del nivel de inglés (algunos clientes pagan premium por ingenieros realmente fluidos) y de si necesitás un especialista concreto en algún módulo nativo.
Ingeniero único, mes a mes
Un desarrollador React Native evaluado, integrado a tu equipo. Vos corrés standups, sprints y reviews. Nosotros llevamos contrato, equipamiento y reemplazos si hacen falta.
Preaviso: 15 días luego del primer mes.
Squad chica con QA
Dos ingenieros más un QA móvil que prueba en dispositivos reales. Funciona bien cuando estás lanzando o rescatando una app y querés salida coordinada en lugar de tres aportes separados.
Mínimo: 3 meses para amortizar el arranque.
Tech lead a cargo del mobile
Un lead senior más dos a cuatro ingenieros. El lead maneja arquitectura, cadencia de releases y decisiones de hiring. Ideal cuando no tenés capacidad móvil interna y no querés armarla ahora.
Mínimo: 4 meses.
Los números asumen semanas de 40 horas, mezcla senior y mid, e incluyen reclutamiento, notebooks, beneficios e impuestos locales. No incluyen servicios de terceros como Sentry, RevenueCat o el Apple Developer Program — esas cuentas quedan a tu nombre para que tengas control.
Cómo funciona el proceso de contratación, en la práctica
Del primer email a un pull request mergeado, unas dos semanas.
- Descubrimiento (día 1 a 2). Llamada de 45 minutos. Preguntamos por tu app (¿Expo o bare? ¿Arquitectura? ¿Módulos nativos?), la forma del equipo, seniority, husos horarios y qué significa éxito en 90 días. Si no cuadra, lo decimos acá.
- Shortlist (día 3 a 5). Recibís 2 a 3 perfiles con notas escritas y un Loom del ingeniero recorriendo un proyecto React Native reciente. Nada de CVs anónimos ni entrevistas al divino botón.
- Tu entrevista (día 5 a 8). La corrés como quieras — live coding, diseño de sistemas, charla cultural o las tres. Entramos a la primera si ayuda, si no nos corremos. Decisión en 48 horas.
- Onboarding (día 8 a 12). Notebook, acceso al repo, invitación a Apple Developer, claves de firma de Android, Sentry, Firebase y credenciales de CI. Tenemos un checklist para que no falte nada. El ingeniero hace pair con alguien de tu equipo en el primer ticket.
- Primer PR mergeado (día 12 a 15). Algo real: un bug fix, un feature chico, una mejora de infraestructura. El objetivo es validar el flujo, no impresionar.
- Ventana de reemplazo (primeros 14 días). Si el match no es el correcto, cambiamos sin costo y cubrimos el solapamiento. Luego, preaviso de 15 días para cualquiera de los dos lados. Los contratos son mes a mes más allá del mínimo acordado.
Siblings vs freelance vs in-house vs offshore genérico
La mayoría de nuestros prospects ya probó al menos una de las otras opciones. Acá va una comparación honesta. Si alguna fila no coincide con lo que ves en tu caso, decinos — la ajustamos.
Dónde gana el freelance
Tareas chicas y bien definidas. Un módulo nativo puntual, una animación tramposa, una auditoría de performance. Si sabés exactamente lo que necesitás y son menos de 80 horas, un freelance especialista suele ser más barato y rápido que cualquiera.
Dónde el freelance duele
Todo lo que requiera continuidad. Se toman vacaciones sin avisar, juegan con tres clientes en paralelo y rara vez hacen el trabajo invisible — pipelines, documentación, runbooks — porque no se factura de forma obvia.
Dónde gana el in-house
Propiedad del producto core. Si mobile es tu centro de gravedad permanente, un empleado full-time que esté en cinco años es irremplazable. Hay clientes que arrancan con nosotros y después contratan a su propio equipo una vez que saben cómo se ve "bueno." Está perfecto.
Dónde duele el in-house
Tiempo y arrepentimiento. En EE.UU., contratar un senior React Native es un proceso de tres a cuatro meses que muchas veces falla la primera vez. Mientras tanto, el roadmap se estanca. Y si el contratado no encaja, tenés una conversación de severance.
Escenarios reales de contratación que vemos una y otra vez
Estos son composiciones de contratos reales — datos anonimizados, números redondeados. Los ponemos porque los compradores suelen querer saber "¿mi situación es algo que ya vieron antes?"
Escenario A — la fintech que crashea
Contexto: App de préstamos al consumidor en EE.UU., 400k MAU, crash-free rate por debajo del 97% en Android. Dos devs in-house, uno de licencia por paternidad.
Qué hicimos: Colocamos un senior en 9 días. Primeros 30 días: modo lectura, instrumentación con Sentry y Firebase Performance, runbook escrito. Días 30 a 90: reescritura del flujo de préstamo inestable, fix de tres memory leaks en módulos nativos, manejo de imágenes fuera del hilo JS.
Resultado: Crash-free al 99,6% en Android, 99,9% en iOS, cold start p95 de 3,8s a 1,9s en un Pixel 6a.
Escenario B — el MVP que había que publicar
Contexto: Startup de logística con ronda seed, Figma listo, backend a medias, cero ingenieros móviles. Los inversores habían prometido app para el Q2.
Qué hicimos: Squad chica — un senior, un mid, un QA móvil — más 10% de un tech lead para revisiones de arquitectura. Expo bare, EAS para los builds.
Resultado: 19 semanas de kick-off a las dos tiendas publicadas. TestFlight beta en la semana 11. Pospublicación, la squad bajó a un solo ingeniero para mantenimiento.
Escenario C — la replataforma legacy
Contexto: Retailer europeo con app iOS en Objective-C de 2016 y una Android en Java que solo entendía una persona. La dirección quería una sola base de código.
Qué hicimos: Tech lead más tres ingenieros durante 10 meses. React Native brownfield embebido en las apps viejas, pantalla por pantalla, con RCTRootView. Las apps nativas siguieron publicando mientras los features nuevos se mudaban a RN.
Resultado: 82% de las pantallas sobre React Native al cierre, con su propio equipo continuando la migración. Dos de nuestros ingenieros pasaron a ser empleados directos del cliente al final — no firmamos non-competes.
Escenario D — la agencia con overflow
Contexto: Agencia digital estadounidense había vendido un proyecto React Native de 4 meses y su referente mobile acababa de renunciar.
Qué hicimos: Dos ingenieros bajo su delivery lead, con marca blanca del lado de la agencia (nuestro contrato con el cliente final nunca fue visible). Daily en el Slack de la agencia, PRs en su GitHub.
Resultado: El proyecto se entregó en la fecha original. La agencia nos volvió a llamar tres veces en los 18 meses siguientes.
Mini caso de estudio
Cómo un solo ingeniero cortó a la mitad el tiempo de inicio de videollamadas de una app de telemedicina
Cliente. Empresa de telemedicina Serie B con alrededor de 90.000 consultas mensuales en EE.UU. Su app React Native era estable pero los usuarios abandonaban las videollamadas en los primeros 15 segundos — cerca de 11% de caída en ese paso del funnel.
Brief. Contratar un ingeniero React Native senior que viva dentro del pod mobile durante seis meses, se haga cargo de la confiabilidad del video y no necesite acompañamiento constante en código nativo.
Qué hicimos. Colocamos un senior con experiencia previa en WebRTC. En las primeras dos semanas instrumentó el flujo de llamada de punta a punta con breadcrumbs custom de Sentry: descubrió que el 38% de los fallos venían de prompts de permiso de cámara en iOS disparados demasiado tarde y el 22% de conflictos de audio focus en Android. Reescribió el flujo pre-llamada de permisos como módulo nativo (Swift en iOS, Kotlin en Android), cacheó capacidades del dispositivo y movió la inicialización de WebRTC fuera del hilo JS.
Resultado en 90 días. El abandono en el paso de conexión de video pasó del 11% al 4,2%. La mediana de tiempo entre "iniciar llamada" y "primer frame de video" cayó de 6,3 segundos a 2,9 segundos. Los tickets de soporte con el tag “no funciona el video” bajaron cerca de un 60%.
Aclaración honesta. Buena parte de la ganancia vino de instrumentar bien — algo que su equipo podría haber hecho si tenía la capacidad. El valor que agregamos fue tener a un ingeniero que sabía dónde mirar al día tres.
En resumen
Industria: Telesalud
Contrato: 1 senior, 6 meses
Stack: React Native 0.73, Expo bare, WebRTC, Swift, Kotlin, Sentry
Abandono: 11% → 4,2%
Al primer frame: 6,3s → 2,9s
Tickets de soporte: -60% por video
Los riesgos de contratar desarrolladores React Native, y cómo los manejamos
Cualquier proveedor que te diga que el staff augmentation no tiene riesgo está mintiendo o es nuevo. Estas son las cuatro cosas que de verdad salen mal, y qué hacemos al respecto.
Riesgo: el ingeniero se ve genial en papel y se estanca en la semana tres
Cómo lo manejamos. Ventana de reemplazo sin costo de dos semanas. Nuestra evaluación incluye una pair session en vivo sobre un bug móvil real, no un problema de Leetcode. Y nuestro account lead te llama el día 14 específicamente para preguntar: "¿si fuera una contratación in-house, lo mantendrías?"
Riesgo: el conocimiento se va cuando termina el contrato
Cómo lo manejamos. La documentación no es un favor, es un item del acuerdo. Cada módulo nativo tiene README. Cada decisión difícil queda en un ADR. Los runbooks de los pipelines de release viven en tu repo. Si cortás mañana, tu equipo tiene el mapa.
Riesgo: la versión de React Native en la que estás deja de estar soportada
Cómo lo manejamos. Antes de firmar, cruzamos tu versión con la página oficial de versiones de React Native. Si estás más de dos versiones menores atrás, lo marcamos y proponemos un plan de upgrade — incremental, con el upgrade helper de la comunidad, no una reescritura de big-bang.
Riesgo: rechazo en App Store sobre un release crítico
Cómo lo manejamos. Release notes, privacy manifests y declaraciones de dominios de tracking se preparan un sprint antes de la submission, no la noche anterior. Nuestros seniors manejaron múltiples rechazos bajo las guidelines 2.1, 3.1.1 y 5.1.1 — las tres que más pegan a apps React Native — y saben qué suele aceptar Apple.
Por qué Siblings Software, puntualmente
Decidí con datos, no con slogans.
11+
Años armando equipos móviles
Fundada en 2014 en Córdoba, Argentina
40+
Apps publicadas en las dos tiendas
Fintech, salud, retail, logística
GMT-3
Huso horario de Argentina
Solapamiento total con el este de EE.UU.
Somos chicos a propósito. No hay un área de ventas empujando headcount. Los fundadores — uno de ellos, Javier Uanini, sigue tomando personalmente la mayoría de las discovery calls — revisan cada contrato. Nuestros ingenieros hablan con los clientes directo desde la semana uno. Esa es la razón real de que el onboarding sea rápido: no hay nadie en el medio traduciendo.
Cosas que los compradores suelen hacer mal al elegir proveedor: pedir tarifa hora antes de explicar el trabajo (te van a cotizar el número más bajo posible y el costo real va a llegar después), exigir CVs completos antes de cualquier llamada (no compartimos datos personales antes de un NDA básico, y vos tampoco deberías quererlo), y creer que una agencia más grande entrega más confiable (en mobile, chico y especializado le gana a grande y genérico casi siempre).
Preguntas frecuentes de compradores
Nuestros estándares
Mobile tratado como producto principal, no como tarea secundaria.
- Dispositivos reales, todos los sprints. Los simuladores mienten sobre la performance. Nuestros QAs tienen un rack chico de iPhones, Pixeles y un Android deliberadamente lento para cazar los problemas que los usuarios premium nunca ven.
- Instrumentación desde el día uno. Sentry, Firebase Performance o la herramienta que uses, configuradas antes del primer feature. No se arregla lo que no se mide.
- Releases como producto. Los pipelines, changelogs, lanzamientos por etapas y metadata de tiendas son de la squad, no "problema de otro."
- Artefactos escritos. ADRs para decisiones de arquitectura, README para cada módulo nativo, runbooks para incidentes productivos habituales. Eso es lo que hace que el handoff sea indoloro si algún día nos vamos.
- Escalamiento honesto. Si un plazo se está cayendo o una decisión técnica estuvo mal, lo decimos en la actualización semanal, no al final del sprint.
Contactá a Siblings Software
Contanos de tu app. Respondemos en un día hábil, o te decimos si no somos la opción correcta.