Servicios de desarrollo TypeScript
Desarrollo TypeScript que trata al sistema de tipos como arquitectura, no como decoración
· Tiempo promedio hasta el primer PR mergeado: 12 a 15 días
Muchos equipos tienen TypeScript en el repo. Pocos lo usan. Lo que solés heredar es una pared de any, un tsconfig con modo estricto apagado “por ahora” y tres devs discutiendo en silencio si la validación en runtime va en el handler o en el schema.
Siblings Software es una firma chica con base en Córdoba, Argentina, que viene armando equipos TypeScript desde que el lenguaje dejó de ser una curiosidad. Esta página está escrita para la persona que está comparando proveedores: qué trabajo se hace realmente, cuánto cuesta, qué hacemos bien y en qué casos te diríamos que contrates a otro.
Quién nos contrata para TypeScript
Cuatro perfiles de comprador cubren la mayor parte de los engagements.
Equipos cuyo código JavaScript se quedó chico
Dos o tres años adentro, la app funciona pero nadie quiere tocar el checkout. Refactorizar rompe en producción. Sumar a un ingeniero nuevo lleva seis semanas porque las formas de los datos viven en la cabeza de alguien. Querés TypeScript, y lo querés sin congelar el roadmap un trimestre.
Startups que quieren arrancar en TypeScript estricto
Seed o Serie A. Un diseñador, una API apenas esbozada, una fundadora que leyó suficientes post-mortems como para saber que “después tipamos” es mentira. Querés una escuadra que entregue un Next.js con Zod en los bordes, IDs branded y un Storybook que se mantenga al día. No querés discutir cómo debería estar seteado el modo estricto.
Scale-ups reemplazando un framework interno riesgoso
Un framework Node casero de 2019 que entienden tres personas. Un front-end atado a una versión vieja de Angular. Management quiere frenar el sangrado sin hacer un rewrite. Querés ingenieros TypeScript que puedan meter NestJS o Fastify en los bordes, generar clientes tipados contra la API vieja, y dejar que el código nuevo sea estricto mientras el legacy sigue facturando.
Empresas consolidando un patrimonio JavaScript disperso
Cuatro aplicaciones internas, tres en JavaScript, una en CoffeeScript por alguna razón. Un platform team que quiere una única fuente de verdad para tipos, tokens y clientes de API. Querés una escuadra TypeScript que pueda armar un monorepo Turbo o Nx, publicar paquetes de tipos compartidos y darle a los otros equipos una razón para adoptarlos, no un memo obligándolos.
Si ninguno de estos perfiles te describe, igual hacemos la llamada, y te decimos en los primeros quince minutos si no somos el proveedor correcto.
Qué hacen los ingenieros TypeScript día a día
La mayoría de las páginas de servicios se quedan en “hacemos React y Node”. Eso no sirve si estás decidiendo si contratar un equipo. El scope de abajo es en lo que trabaja un ingeniero TypeScript típico en un sprint. El mix cambia por engagement, pero rara vez son menos de cuatro de estas áreas.
Superficies de producto en React, Next.js, Angular o Vue
Dashboards, onboarding, consolas de admin, flujos de facturación. Server components donde mejoran el modelo de costo, no porque lo dijo una charla. Forms tipados con React Hook Form más resolvers Zod, routing tipado, suspense boundaries en serio. La biblioteca de componentes está tipada para que las combinaciones de props equivocadas dejen de ser una sorpresa en runtime.
Back-end Node.js con tipos que sobreviven al borde JSON
NestJS, Fastify, Hono o Express pelado, según lo que el equipo ya corra. Zod o Valibot en cada borde. Acceso tipado a base de datos con Prisma o Drizzle. Consumidores de colas con tipos en uniones discriminadas para que el compilador no te deje olvidar un caso. El objetivo: si los tipos compilan, podés confiar en el runtime.
Arquitectura de tipos que modela el dominio, no la base de datos
Branded types para IDs, uniones discriminadas para estado, enums como uniones de literales en lugar del otro tipo, genéricos con restricciones y usados con mesura. Usamos el handbook oficial de TypeScript como terreno común en las reviews, y dejamos la arquitectura escrita para que el próximo ingeniero no tenga que hacer ingeniería inversa desde el call site.
Design system y biblioteca de componentes tipados
Tokens de diseño como paquete tipado, variantes de componentes con uniones de literales, stories de Storybook que hacen las veces de tests de regresión de tipos, y codemods para los cambios que rompen. La parte aburrida de la gobernanza — avisos de deprecación, guías de migración, reglas de lint de accesibilidad — se hace en el tiempo previsto, no cuando alguien se queja.
Testing y CI con chequeos de tipos en el mismo rango
Vitest o Jest para unit, Playwright para end-to-end, tsc --noEmit como gate de CI de primera clase. ESLint con reglas estrictas de typescript-eslint, no-any configurado, y Turbo con caché remota para que el pipeline no sea un castigo. Los tests conocen los tipos; los tipos conocen las fixtures.
Migración desde JavaScript sin frenar el roadmap
No vendemos rewrites. Dejamos el tsconfig con allowJs y checkJs, prendemos modo estricto paquete por paquete y empujamos features en paralelo. Para cuando la migración está “lista”, la mayoría del equipo de producto se olvidó de que estaba pasando. El detalle está más abajo, en la sección de migración.
Cada senior que ubicamos entregó al menos una base TypeScript desde cero y migró al menos un proyecto JavaScript a modo estricto. La mayoría hizo las dos cosas, en SaaS, fintech, salud y retail.
Modelos de engagement y cuánto cuestan
Publicamos rangos porque los precios escondidos hacen perder tiempo a todos. El número final depende del mix de seniority, nivel de inglés (algunos compradores pagan un plus por ingenieros que se manejan directo con sus stakeholders) y si necesitás especialistas como un arquitecto de tipos staff-level o un ingeniero de performance.
Especialista TypeScript
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 sepa TypeScript estricto. Hace pair en lo difícil, se encarga de una porción del código y asiste a tu daily.
Precio: USD 7.500 a 12.000 por mes. Mínimo: 3 meses.
Escuadra de producto
De tres a cinco ingenieros (mix senior y mid) con tech lead, QA automation y DevOps part-time. Entrega features, es dueña del design system y mantiene el CI honesto. Funciona junto a nuestra página de equipo dedicado TypeScript, o combinada con los equipos React y Node.js.
Precio: USD 22.000 a 42.000 por mes. Mínimo: 4 meses.
Escuadra de migración y hardening
De dos a cuatro ingenieros con un objetivo acotado: pasar la base JavaScript a TypeScript estricto, o retirar una clase específica de bug de runtime. Suele correr en paralelo con el equipo de features, no en su lugar. Se retira cuando el scoreboard está en verde.
Precio: USD 16.000 a 32.000 por mes. Mínimo: 3 meses.
Los números asumen semanas de 40 horas e incluyen recruiting, beneficios, laptops e impuestos locales. Los servicios de terceros — Vercel, Sentry, Datadog, Auth0, Stripe — quedan en tus cuentas, así mantenemos afuera los datos y la facturación.
El camino de JavaScript a TypeScript que usamos en serio
Los rewrites completos se venden bien en pitch decks y sobreviven poco al contacto con el roadmap. Lo que funciona es incremental: la base se mantiene verde, el equipo de producto sigue entregando features, y TypeScript se expande paquete por paquete hasta que sale el último ts-ignore.
- Auditoría de base (semana 1). Catalogamos hotspots, dependencias circulares, clusters de
anyimplícito y bordes por donde entra data sin tipar. El resultado es un mapa de riesgo por paquete: qué convertir primero, qué poner en cuarentena y qué dejar para el final. - tsconfig con allowJs (semana 1–2). Un solo
tsconfig.json(o base config en un monorepo) conallowJs,checkJsy path aliases. Nada de modo estricto todavía. Pipelines en Turbo o Nx para que el type checker corra sobre lo que cambió, no sobre todo el tree. - Conversión paquete por paquete (semana 2–10). Los paquetes se migran por riesgo y valor: primero las libs compartidas, después el back-end, y al final los módulos de front-end más activos. El modo estricto se prende por paquete apenas queda limpio, no globalmente al final.
- Contratos y reglas de lint (semana 8–12). Zod en los bordes HTTP y de colas, tRPC o tipos generados desde OpenAPI entre servicios, y reglas de
@typescript-eslintendurecidas (no-unsafe-*, no-explicit-any, consistent-type-imports). Acá suelen aparecer bugs latentes; es lo esperado, no una regresión. - Salida de los escape hatches (semana 10–14). Los
ts-ignoreyas anyque quedan se publican en un scoreboard visible. Los genéricos se ajustan con constraints. Se publican los mapas de tipos a las apps consumidoras. Cuando el scoreboard llega a cero (o a cero honesto, con una lista de excepciones documentada), la migración está terminada.
Los tiempos son para una base de 30.000 a 80.000 líneas. Los monorepos grandes extienden el paso 3, no la forma general. No vimos una migración que obligue a frenar features, y si un cliente nos pide eso, lo cuestionamos.
TypeScript con nosotros vs freelance, in-house u offshore genérico
La mayoría de los prospects ya probó al menos una alternativa. Esta es una comparación honesta. Si alguna línea no coincide con tu experiencia, contanos en la primera llamada y la ajustamos.
Dónde gana un freelance TypeScript
Tareas acotadas. Un componente genérico que nadie termina de cerrar. Un script de migración único. Una integración con Stripe o Auth0 con especificación clara. Para menos de 80 horas de trabajo, un freelance especializado suele ser más barato y más rápido.
Dónde el freelance te complica
Continuidad. Maneja otros tres clientes, se toma vacaciones sin aviso, y rara vez hace el trabajo no glamoroso que mantiene sano un codebase TypeScript: higiene de Storybook, refactors genéricos, upgrades de ESLint, codemods. Entregás tickets rápido y la plataforma se pudre en paralelo.
Dónde gana un hire in-house
Propiedad a largo plazo. Si TypeScript es central en tu producto los próximos cinco años y podés bancar una búsqueda de cuatro meses, un senior full-time es irreemplazable. Muchos clientes empiezan con nosotros, ven cómo se ve “bien”, y después contratan internamente. Es un buen final.
Dónde in-house te complica
Riesgo de funnel y costo de arrepentimiento. Los senior TypeScript en mercados de Estados Unidos y Reino Unido tardan tres a cuatro meses en cerrar, con alta tasa de rechazo de ofertas. Si el hire sale mal en el mes seis, estás mirando severance, no preaviso. Mientras tanto el roadmap se frena.
Dónde ganan las agencias offshore grandes
Cuerpos disponibles a tarifas bajas cuando el trabajo es genérico: herramientas internas, CMS skins, UIs de data-entry. Si el brief es “dame diez desarrolladores TypeScript y asignáles tickets”, están hechas para eso.
Dónde las agencias offshore te complican
El ingeniero de la entrevista rara vez es el de los commits. La superposición horaria con Estados Unidos suele ser de dos a cuatro horas. Arquitectura de tipos y design system son scope extra, no defaults. El preaviso es de 30 a 90 días, lo que hace doloroso el ramp-down.
Dónde calzamos nosotros
En el medio. Chicos, senior, empleados full-time, en una zona horaria que superpone un día laboral pleno con Estados Unidos. Entrevistás al ingeniero exacto que va a escribir tu código. Arquitectura de tipos, design system, testing y CI son parte del scope por defecto, no upsell. Los mínimos son tres o cuatro meses, no un año.
Para brechas más chicas, nuestro servicio de staff augmentation TypeScript suele ser mejor encaje — los mismos ingenieros, otro modelo comercial.
Escenarios TypeScript que vemos seguido
Estos son composites de engagements recientes. Detalles anonimizados, 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 manejamos.
Escenario A — el SaaS que creció más allá de sus tipos
Contexto. SaaS B2B en Estados Unidos, 180.000 líneas de JavaScript y TypeScript mal tipado mezclado. Equipo de cinco, dos personas sosteniendo la base. El churn subía porque cada release traía al menos un incidente de “undefined is not a function”.
Qué hicimos. Escuadra de tres personas de migración junto al equipo interno. Modo estricto por paquete, Zod en el borde HTTP, un event bus tipado reemplazando los emit sin tipo. Sin frenar features.
Resultado. En once semanas llegamos a modo estricto en los tres paquetes críticos. Los incidentes de tipo en producción pasaron de semanales a uno por trimestre. Sumar a un ingeniero nuevo bajó de seis semanas a diez días.
Escenario B — la startup que quiso estricto desde día uno
Contexto. Serie A en healthtech en Toronto. Cero front-end engineers, Figma listo, un Postgres a medio armar. Los inversores esperaban un producto vivo en un trimestre.
Qué hicimos. Escuadra TypeScript de dos ingenieros más un tech lead part-time. Next.js App Router, tRPC contra el Postgres vía Drizzle, esquemas Zod compartidos front a back, Storybook desde la semana dos, Playwright desde la semana cuatro. Modo estricto desde el primer commit.
Resultado. Trece semanas hasta una app en producción con auth, billing, onboarding y un dashboard para el equipo de salud. Cuando después sumaron a su primera senior interna, ella mergeo su primer PR en cuatro días porque los tipos eran la documentación.
Escenario C — la empresa con cuatro apps sin contrato común
Contexto. Grupo asegurador europeo. Cuatro aplicaciones internas, tres en JavaScript, todas consumiendo el mismo back-end con su propia idea de qué era una “póliza”. Los bugs de integración eran rutina semanal.
Qué hicimos. Escuadra de cuatro personas para armar un monorepo Turbo con un paquete @company/contracts compartido: esquemas Zod, IDs branded, clientes OpenAPI generados. Dos apps migraron al monorepo; las otras dos consumieron los tipos publicados desde un registry privado.
Resultado. Los bugs de integración (medidos por tickets de soporte) bajaron 64% en seis meses. Dos de los cuatro equipos adoptaron los contratos voluntariamente; los otros dos entraron cuando una regulación nueva forzó el cambio.
Escenario D — el design system que necesitaba tipos, no un rewrite
Contexto. Empresa de medios con un design system React usado por doce escuadras de producto. Tipado parcial, variantes de componentes en strings, y cambios que rompían anunciados por mail.
Qué hicimos. Dos ingenieros senior por cuatro meses. Pasamos las variantes a uniones de literales, publicamos un paquete @design/tokens tipado, escribimos codemods para los renombres que rompían, y agregamos coverage de Storybook como gate de CI.
Resultado. El tiempo medio para adoptar un componente nuevo bajó de tres semanas a cuatro días. “¿Viste mi mail?” dejó de ser el protocolo de release.
Mini caso de éxito
Cómo una plataforma logística bajó los errores de tipo en producción un 81%
Cliente. Una logística nórdica con un portal para comerciantes (cotización, reserva, facturación) en JavaScript vanilla desde 2017. Alrededor de 120.000 líneas, un equipo interno de seis, y la costumbre de shipear un hotfix cada viernes a la tarde.
Brief. Llevar la base a TypeScript estricto sin frenar el roadmap trimestral, y dejar al equipo interno en condiciones de seguir el trabajo por su cuenta.
Qué hicimos. Escuadra de tres personas de migración y hardening: un tech lead y dos senior TypeScript. La semana 1 fue la auditoría — mapa de riesgo rankeando 43 paquetes por costo de conversión y frecuencia de bugs en runtime. Semanas 2 a 10: convertimos siete paquetes (utilidades compartidas, dos clientes de API, el motor de pricing y los handlers de back-end), prendiendo modo estricto por paquete. Semanas 6 a 12 se solaparon con el hardening de contratos: Zod en cada borde HTTP, OrderId y MerchantId como branded types en lugar de string en todos lados, y un tipo de unión discriminada para el consumidor de colas que era la fuente de la mayoría de los incidentes del viernes. El equipo interno siguió entregando features; en la review de ops semanal vimos bajar los reportes de error de tipo de doce por semana en la semana 1 a dos por semana en la semana 14.
Resultado a seis meses. Los incidentes de producción clasificados como “de tipo” (argumento con forma equivocada, acceso a undefined, asunción mala sobre un JSON) cayeron 81% interanual. La cadencia de release se duplicó. El onboarding pasó de “tres semanas para sentirme seguro” a “primer PR en la segunda semana”. El equipo interno tomó los paquetes restantes en el mes seis; nos quedamos un día a la semana haciendo code review por otro trimestre.
Salvedad honesta. El primer mes se sintió lento. La auditoría no produce features demostrables, y el COO tuvo que bancar la discusión interna cuando el CEO preguntó por qué no había nada para mostrar. Si comparás velocidad de mes uno, un freelance parece más productivo. Desde el mes tres empezó a compensar, y en el seis nadie quería volver atrás.
De un vistazo
Industria: logística / portal de comerciantes
Engagement: escuadra de 3, 6 meses + cola de review
Stack: Node.js, NestJS, React, Zod, Drizzle, Turbo
Incidentes de tipo: −81%
Cadencia de release: 2×
Onboarding: 3 semanas → 1 semana
Los riesgos de tercerizar TypeScript y cómo los manejamos
Cualquier proveedor que te diga que tercerizar TypeScript es libre de riesgo te está vendiendo algo. Estos son los cuatro modos de falla más comunes, y los controles puntuales que usamos contra cada uno.
Riesgo: el ingeniero brilla en papel y se frena en la tercera semana
Cómo lo manejamos. El vetting termina en una pair session real con un bug TypeScript — un genérico que no compila, un caso de infer por desarmar —, no en un Leetcode. Ventana de reemplazo gratuito de dos semanas. El account lead te pregunta en el día 14: “si fuera un hire full-time, ¿lo mantendrías?”. En los últimos 18 meses cambiamos a dos ingenieros, ambos dentro de la ventana libre.
Riesgo: los tipos se aflojan y “un any cortito” se cuela en los PRs
Cómo lo manejamos. no-explicit-any, no-unsafe-* y consistent-type-imports son reglas que bloquean el merge. Las excepciones requieren un comentario explicando por qué, que se revisa en la siguiente sesión de tech debt. Un scoreboard público rastrea los escape hatches restantes para que nadie haya que hacer arqueología de deuda seis meses después.
Riesgo: el conocimiento se va cuando termina el engagement
Cómo lo manejamos. La documentación es una línea de trabajo, no un favor. Architecture Decision Records para las decisiones de tipo no obvias, READMEs por paquete no trivial, runbooks para incidentes de producción, entradas de Storybook para componentes. Si termina el engagement mañana, el equipo interno tiene un mapa, no una caza del tesoro.
Riesgo: la migración se come la velocidad y pierde aire político
Cómo lo manejamos. Un scoreboard semanal con cuatro números: paquetes en modo estricto, ts-ignore restantes, coverage de validación en los bordes, incidentes de tipo en producción. Esos cuatro números van al ops review semanal para que el progreso sea visible a quien no lee pull requests.
Por qué Siblings Software
Decidí por hechos, no por consignas.
11+
años armando equipos TypeScript
Fundada en 2014 en Córdoba, Argentina
80+
engagements TypeScript entregados
SaaS, fintech, salud, retail, logística
GMT-3
zona horaria argentina
Superposición plena con la costa este de EE.UU.
Somos chicos a propósito. No hay una organización de ventas empujando headcount. Los fundadores — Javier Uanini hace personalmente la mayoría de las discovery calls — revisan cada engagement. Nuestros ingenieros hablan directo con el cliente desde la semana uno. Esa es la razón real por la que el onboarding es rápido: no hay nadie en el medio traduciendo requerimientos.
Cosas que los compradores suelen hacer mal cuando buscan un proveedor TypeScript: pedir tarifa por 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 como change orders), asumir que cualquier dev que lista TypeScript en su CV sabe modo estricto (la mayoría no), y creer que una agencia más grande entrega más confiable (en producto TypeScript, chico y senior le gana a grande y genérico casi siempre).
Para referencia, el sitio oficial de TypeScript es el baseline con el que enseñamos, y el proyecto typescript-eslint es el ruleset que extendemos. Contribuimos cuando podemos, leemos los RFCs y no tratamos a TypeScript como un añadido de JavaScript.
Preguntas frecuentes
ts-ignore que quedaban. Los monorepos grandes extienden la fase media, no la forma general.Nuestros estándares
TypeScript como tema principal, no como un linter que olvidamos apagar.
- Modo estricto por defecto, siempre. Los proyectos nuevos arrancan con
"strict": true. Las migraciones llegan por paquete, no por repo. - Los bordes en runtime se validan. Zod o Valibot en cada borde HTTP, de cola o de servicio externo. La confianza del compilador termina en el JSON.
- Genéricos con constraints, o sin genéricos. Un
Tsin restricción huele mal. Los branded types protegen IDs. Las uniones discriminadas modelan estado. - Type checks como gates de CI.
tsc --noEmitbloquea merge. Las reglas estrictas detypescript-eslintbloquean merge. Nada de caer en silencio aany. - Artefactos escritos. ADRs para decisiones de tipo. READMEs por paquete. Runbooks para incidentes. El traspaso es un árbol de archivos, no una llamada.
- Escalación honesta. Si el scoreboard de migración se afloja, se dice en el update semanal, no tres sprints después.
Hablá con Siblings Software
Contanos sobre el código, el equipo y qué necesitás. Respondemos en un día hábil, o te decimos directo si no somos el encaje correcto.