Trabajo remoto en software con proyectos que tienen usuarios reales
Revisado por Javier Uanini, fundador e ingeniero en Siblings Software.
Si buscás empleo remoto para desarrolladores en Argentina, probablemente no alcanza con ver títulos en LinkedIn. Querés saber si hay proyectos serios, si el proceso es honesto, si la compensación se habla antes de perder dos semanas, y si el remoto acá significa confianza o solo una notebook en casa con interrupciones constantes.
Siblings Software es una empresa de desarrollo de software fundada en 2018 en Córdoba. Nuestros ingenieros trabajan con clientes en fintech, salud, logística, eCommerce, construcción y SaaS. Algunos roles son staff augmentation dentro del equipo del cliente. Otros son squads dedicados con backend, frontend, QA, DevOps, UX y liderazgo técnico. Esta página explica cómo funcionan las carreras acá antes de mandar tu CV.
Qué responde esta página (y qué no)
Más que un cartel de “estamos contratando”.
La intención es transaccional con capa de investigación: podés estar listo para aplicar, pero primero comparás Siblings con freelance, empleo directo, agencias locales y plataformas globales.
Un buen candidato quiere detalle: tipos de rol, realidad del proyecto, modelo de compensación, pasos de selección, stack, inglés y cuánta exposición al cliente habrá. No vamos a pretender que todo es glamoroso. Hay trabajo greenfield, modernización y mantenimiento cuidadoso de sistemas con usuarios y revenue. El hilo común: el trabajo es real y alguien depende de él.
En 2025–2026 vemos más proyectos con features asistidas por IA (evaluación, RAG, automatización interna). No llamamos “IA” a un chat pegado encima. Si te interesa ese perfil, mirá también desarrollo de IA y cómo encaja con roles de ingeniería.
Rutas actuales y futuras en Siblings
Roles que contratamos y el pipeline detrás.
Las vacantes cambian con la demanda de clientes, pero el pipeline es más amplio que lo publicado en una semana dada. Si tu perfil encaja en alguna de estas áreas, vale aplicar aunque el título exacto no esté listado.
Backend y plataforma
Java, Go, Python, Node.js, .NET, PostgreSQL, APIs, jobs distribuidos, integraciones y servicios cloud. Valoramos razonamiento sobre modelos de datos, modos de falla y soporte en producción, no solo sintaxis de frameworks.
Frontend y full-stack
React, Next.js, Angular, Vue, TypeScript, design systems, portales y aplicaciones web sensibles a performance. Un buen frontend entiende contratos de API y comportamiento de producto.
Ingeniería mobile
React Native, Flutter, Kotlin, Swift, comportamiento offline, releases en stores, push y QA por dispositivo. El mobile suele estar cerca de diseño y coordinación de release.
QA automation y release
Playwright, Cypress, testing de APIs, pipelines CI, smoke suites y estrategia de regresión acorde al riesgo. Acá el QA es parte de ingeniería, no un portón de último momento.
IA, datos y automatización
Ingenieros de IA, datos, evaluación de prompts, soporte MLOps, automatización de flujos internos y desarrolladores que conectan LLMs a sistemas productivos con criterio.
Seguridad, DevOps y especialistas
Seguridad cloud, revisión de IA, AppSec, DevOps, observabilidad, blockchain y smart contracts cuando el cliente lo necesita. Preferimos experiencia concreta sobre títulos de moda.
Para entender la empresa detrás de estos roles, leé sobre nuestro equipo de ingeniería y los servicios que contratan los clientes: staff augmentation, equipos dedicados y outsourcing por proyecto.
El trabajo está más cerca de producción que del portfolio
Sin teatro de bench.
Muchos candidatos preguntan si somos outsourcing, staff augmentation o estudio de producto. La respuesta honesta: la forma la define el cliente. Un ingeniero puede entrar al sprint de un equipo en EE.UU. Un squad puede llevar modernización de un marketplace. Un QA puede sumarse tarde para un launch más seguro.
Lo que evitamos es bench theater: gente esperando mientras ventas busca algo plausible. Si hablamos de un rol, debería haber contexto de proyecto real o pipeline creíble. Decimos si es urgente, exploratorio, o si el inglés y la comunicación con cliente son innegociables.
Usamos la Prueba del Bench Honesto antes de avanzar un proceso: (1) ¿Hay owner de producto del lado del cliente? (2) ¿El stack del rol coincide con lo que vas a tocar en las primeras cuatro semanas? (3) ¿La duración mínima del engagement está escrita, aunque sea aproximada? Si dos respuestas son “no”, frenamos o reencuadramos — no te hacemos perder tiempo.
Los stacks varían: React, Node.js, Java, Go, Python, .NET, cloud, datos o mobile. En roles activos suele haber revisión de CV en 3 a 5 días hábiles; con match claro, el proceso completo suele cerrar en 1 a 3 semanas.
Cómo decidimos si hay match
Un proceso que respeta tu tiempo.
No buscamos un examen universitario ni consultoría gratis. Queremos entender cómo pensás, qué trabajo hiciste de verdad y si el proyecto es justo para tu nivel.
En fundamentos nos importa el criterio en producción: cómo debuggeás, cómo comunicás riesgo, qué testeás y cuándo pedís ayuda. La documentación oficial sigue contando. Quienes leen recursos como la documentación de TypeScript, la documentación de Go o el OWASP Top Ten suelen traer mejores hábitos que quien solo memoriza respuestas de entrevista.
1. Revisión de CV y fit
Buscamos experiencia en producción, stack, nivel de comunicación, solapamiento horario y señales de que el rol sea un paso sano.
2. Screening corto
Disponibilidad, expectativas de compensación, inglés, setup remoto y si preferís trabajo con cliente o entrega más interna.
3. Charla técnica
Trabajo real: arquitectura, bugs que arreglaste, tradeoffs, tests, deploys y dónde querés crecer.
4. Ejercicio práctico, si suma
Algunos roles incluyen un desafío chico o revisión de código. Acotado y relacionado al trabajo, no un fin de semana sin pago.
5. Matching de proyecto
Explicamos contexto del cliente, stack, forma del equipo, cadencia, duración probable y riesgos antes de pedir compromiso.
6. Oferta y onboarding
Confirmamos compensación, fecha de inicio, accesos, expectativas de la primera semana y con quién vas a trabajar.
Cómo hablamos de plata y modelo de trabajo
Las expectativas de compensación aparecen temprano.
Muchas páginas de carreras evitan la plata porque cambia por seniority, rol, cliente, idioma y forma de contrato. No vamos a publicar una banda salarial universal que quede obsoleta en dos meses. Lo que sí decimos: las expectativas se discuten antes de un proceso técnico largo.
La mayoría de los roles son engagements remotos de largo plazo. Algunos son dedicación full-time, otros por proyecto, y un número menor puede ser part-time o especialista fractional. Ingenieros senior con inglés fuerte y ownership con cliente suelen estar en otro rango que perfiles técnicos sólidos que aún crecen en comunicación directa.
Error frecuente que vemos
Optimizar solo por el número mensual más alto e ignorar calidad del proyecto, estabilidad, soporte técnico y si el rol suma a tu carrera en seis meses. La plata importa. También el trabajo que la acompaña.
Rol dedicado largo
Para quien busca estabilidad, contexto profundo y ritmo de equipo que crece con el tiempo.
Trabajo por proyecto
Cuando el alcance es claro y el cliente necesita capacidad para un hito definido.
Soporte especialista
DevOps, seguridad, evaluación de IA, performance o revisiones de arquitectura.
Pipeline futuro
Perfil fuerte hoy, match cuando abra el rol correcto — sin urgencia inventada.
Siblings vs freelance, in-house y agencia grande
Trade-offs en lenguaje directo.
Plataformas freelance
Qué puede ir bien: control directo, clientes variados, a veces tarifas altas a corto plazo.
Dónde duele: venta sin pago, pipeline inestable, poco contexto de producto y poco respaldo cuando el proyecto se complica.
Cómo somos distintos: soporte de proyecto, contexto de recruiting, alineación con cliente y gente que ayuda en problemas técnicos o de comunicación.
Empleo in-house
Qué puede ir bien: ownership profundo de producto, beneficios e identidad con una empresa.
Dónde duele: crecimiento lento si el stack es angosto o el producto está maduro. A veces aparece política interna.
Cómo somos distintos: ves distintos dominios con el tiempo, en entornos de producción serios.
Agencia grande
Qué puede ir bien: cuentas grandes, procesos formales, logos conocidos.
Dónde duele: lejos de quien decide, movimientos entre proyectos sin contexto, proceso pesado.
Cómo somos distintos: equipo chico. Liderazgo, recruiting y delivery cerca de quien escribe código.
Siblings Software
Qué puede ir bien: remoto, clientes de largo plazo, stacks variados, cultura de ingeniería a escala humana.
Dónde duele: trabajo con cliente exige adaptabilidad. A veces hay que aprender un dominio rápido y comunicar incertidumbre con claridad.
Cómo somos distintos: somos directos sobre proyecto, riesgos, compensación y qué va a pedirte el rol de verdad.
Dónde suelen rendir bien los candidatos
El mejor fit no siempre es el CV más llamativo.
Rinden cuando combinan autonomía con comunicación y entienden que el trabajo con cliente igual necesita criterio de ingeniería.
Backend entra a mitad de una plataforma logística
El primer mes no es reescribir todo. Es leer reglas de dominio, estabilizar queries, entender eventos de depósito y shippear un cambio chico sin romper reporting.
QA suma confianza antes de un launch en salud
El valor no es solo escribir tests. Es decidir qué testear primero, dónde el manual sigue importando y cómo hacer útil la señal del CI.
Frontend hereda un dashboard desordenado
Es React o Angular, pero también producto: estados vacíos, permisos, endpoints lentos y explicar por qué un detalle de diseño se vuelve caro en código.
Ingeniero de IA conecta el modelo al flujo de negocio
El perfil útil piensa en evaluación, privacidad, revisión humana, fallos y costo. El débil solo demuestra un prompt que funciona una vez.
Cómo se siente un engagement real desde adentro
Mini caso de estudio.
Un ejemplo útil es Bari, plataforma B2B que conecta mayoristas y retailers. Siblings armó un equipo con backend, frontend y gestión de proyecto. El stack incluyó .NET Core, React y GraphQL. No era un marketplace de juguete: había distribuidores, pedidos y operaciones que no podían pausar mientras el software evolucionaba.
Para un desarrollador, lo interesante son los tradeoffs. GraphQL redujo churn de endpoints con frontend en movimiento. El backend respetó reglas comerciales reales. El equipo lanzó en meses y siguió con mantenimiento y evolución. Ese tipo de engagement premia quien trabaja con ambigüedad, hace preguntas precisas y deja código entendible para el siguiente.
Más detalle en el caso de estudio Bari — ejemplo del trabajo detrás de muchos roles de esta página.
Qué aprende el ingeniero
- Cómo construir features alrededor de flujos de compra reales.
- Cómo coordinar decisiones frontend y backend sin specs perfectas.
- Cómo mantener un sistema post-launch cuando los usuarios muestran edge cases.
- Cómo un equipo chico comunica riesgo al cliente sin drama.
Qué diríamos a un candidato de entrada
Este proyecto no es para quien solo quiere tickets aislados. Pide ownership, paciencia con dominio y humildad para cambiar cuando usuarios o datos demuestran que una suposición estaba mal.
Qué puede salir mal en trabajo remoto con cliente — y cómo lo reducimos
Riesgos nombrados sin eufemismos.
Ownership difuso
Definimos quién revisa código, quién responde producto y quién escala bloqueos. La ambigüedad al inicio es normal; el silencio es el problema.
Sobrecarga de reuniones
Remoto no debería ser meetings todo el día. Favorecemos updates escritos concisos, standups útiles y documentación async cuando protege foco.
Seniority mal calibrado
Un rol junior-friendly y uno de ownership senior son trabajos distintos. Matcheamos según la ambigüedad que podés manejar.
Cambio de contexto del cliente
Las prioridades se mueven. Cuando pasa, hablamos impacto en alcance, salud del equipo y expectativas en lugar de fingir que nada cambió.
Mismatch de tecnología
No te vendemos como experto en un stack que apenas conocés. Aprender está bien; el proyecto tiene que tolerar esa curva.
Burnout disfrazado de urgencia
La producción tiene presión. Un equipo sano distingue un incidente real de mala planificación repetida cada semana.
Cómo trabajamos día a día
Cultura de ingeniería a escala humana.
Siblings es un equipo de tamaño humano. La empresa la fundó Javier Uanini, ingeniero que empezó a construir sitios en 1999 y trabajó en procesamiento de pagos antes de volver a Argentina. Eso importa: las decisiones técnicas no son una caja negra de ventas.
Día a día: Git, pull requests, tickets, standups o updates async según el cliente, y comunicación directa cuando el rol lo pide. Algunos clientes son muy estructurados; otros necesitan ayuda para ordenarse. Un buen ingeniero de Siblings puede trabajar en ambos sin volverse cínico.
Valores simples que se notan en el trabajo: honestidad, profesionalismo, organización, curiosidad y cuidado por la gente alrededor del producto. No siempre acertamos. Cuando algo falla, preferimos una conversación directa temprano a una sorpresa educada después.
Preguntas Frecuentes
Depende del rol. Posiciones con cliente suelen requerir inglés avanzado porque podés entrar a planning, discutir tradeoffs o explicar bloqueos. Algunos roles con menos contacto pueden funcionar con inglés intermedio, pero la comunicación sigue importando.
La mayoría se arma alrededor de horario argentino y trabajo remoto desde Latinoamérica, especialmente Argentina y Uruguay. El requisito exacto de ubicación depende del contrato, solapamiento con el cliente y restricciones legales del engagement.
A veces, pero no en todos los proyectos. Muchos roles piden aporte rápido en producción. Juniors con fundamentos claros, disciplina con Git y buena comunicación deberían aplicar igual para oportunidades futuras.
A menudo, sí. Algunos roles incluyen llamadas y planning con el cliente. Otros pasan por tech lead o delivery manager. Lo aclaramos en el matching porque no todo desarrollador fuerte quiere la misma exposición.
CV, LinkedIn, GitHub o portfolio si aplica, stack principal, nivel de inglés, ubicación, disponibilidad y expectativas de compensación. Una nota corta sobre el tipo de trabajo que querés ayuda más que una carta genérica.
Sí, cuando el proyecto y tus fundamentos lo permiten. Vimos QA crecer hacia frontend y backend moverse a cloud o datos. La transición tiene que ser honesta sobre el tiempo de ramp-up.
Mandá una aplicación concreta
La especificidad ahorra tiempo a todos.
Si alguno de estos perfiles se acerca a tu background, enviá tu CV a camila@siblingssoftware.com. Mencioná el rol o stack que buscás, ubicación, disponibilidad, nivel de inglés y qué tipo de proyecto querés evitar además del que querés sumarte.
Quien dice “quiero backend con modelado de datos fuerte, no frontend pixel-perfect” es más fácil de matchear que quien dice “cualquier cosa”. Un QA que prefiere estrategia de release sobre scripts manuales repetitivos también nos dice algo útil.
Checklist rápido
- CV o LinkedIn con trabajo reciente en producción.
- Stack principal, secundario y qué querés aprender.
- Inglés y si estás cómodo en llamadas con cliente.
- Ubicación, zona horaria y fecha realista de inicio.
- Expectativas de compensación o rango, si compartís.
- GitHub, portfolio o notas que muestren tu trabajo.
NUESTROS ESTÁNDARES
Un proceso de carreras que gana la aplicación, no al revés.
Hablamos de compensación temprano, nombramos el contexto del proyecto antes de la charla técnica y decimos qué es incierto en lugar de fingir que todo engagement es igual. El tiempo del candidato debería comprar claridad, no pipelines vagos.
Matcheamos ingenieros a proyectos donde el cuello de botella coincide con su experiencia, con owner real del lado del cliente y reviewer senior nuestro. Los roles son remotos, la comunicación es honesta y el feedback después del proceso es accionable.