Encontrar qué se rompe primero, antes de que cueste un trimestre.
En dos semanas leemos el sistema, recorremos los caminos riesgosos y entregamos un informe escrito: qué está frágil, qué frena la entrega y qué corregir después.
Dos semanas · Alcance fijo · Informe escrito propio · En remoto desde Argentina
Revisión de arquitectura en 10 días hábiles
Para founders, CTOs y equipos de producto que ya tienen un sistema en producción y necesitan que un ingeniero externo diga qué es riesgoso, qué es solo feo y qué merece el próximo ciclo de ingeniería.
- Revisión de solo lectura del repositorio, infraestructura, tableros y flujos críticos.
- Riesgos ordenados por impacto de negocio: fiabilidad, velocidad de entrega, costo, consistencia de datos y fallas de IA.
- Un informe escrito con diagramas, evidencia, mejoras rápidas y trabajo estructural separados.
- Una llamada de traspaso con quienes van a actuar sobre el informe, para que no quede archivado.
Un producto ya tiene usuarios
Hay que seguir entregando, pero cada release se siente más caro que el anterior.
Una función de IA o backend está por llegar a producción
La demo funciona, pero nadie puede probar qué pasa con malos datos, reintentos, carga o bordes de permisos.
Un documento de decisión, no una presentación comercial
Conserve el informe y ejecútelo con su equipo, con nosotros o con quien prefiera.
Sirve en el momento anterior a una decisión técnica cara
La revisión es más útil cuando el sistema ya importa y el equipo necesita evidencia antes de decidir qué corregir, reescribir o publicar.
Cada release tarda más de lo esperado
El equipo sigue entregando, pero cada cambio cruza más zonas desconocidas y la revisión se convierte en arqueología.
La función de IA anda en demo pero nadie confía todavía
No hay set fijo de evaluación, no se guardan las fuentes recuperadas y no hay respuesta clara sobre permisos o fallas.
El sistema tiene usuarios, pero nadie sabe qué se rompe bajo carga
Los caminos críticos funcionan en días normales, mientras colas, reintentos, locks de base y proveedores casi no se probaron juntos.
Se discute una reescritura sin evidencia
El código duele, pero nadie separó deuda estética de las partes que realmente crean riesgo de negocio.
Qué necesitamos saber si pide una revisión
Un buen primer mensaje es corto. No necesitamos credenciales ni un brief largo para decir si la revisión encaja.
Cuándo esta oferta no es la indicada
- Solo necesita manos extra para cerrar tickets esta semana.
- El producto todavía no tiene usuarios ni un flujo crítico.
- Busca rediseño visual, marca o copy de landing.
- Ya sabe exactamente qué construir y solo necesita capacidad de implementación.
El sistema
Qué hace el producto, quién lo usa y qué flujo backend, cloud o IA preocupa.
La decisión
Qué hay que decidir después: publicar, reescribir, escalar, estabilizar, preparar una venta o destrabar al equipo.
El riesgo
Qué sería caro si falla: confianza de clientes, ingresos, exposición de datos, costo cloud, fecha de lanzamiento o velocidad de ingeniería.
La fecha
Por qué ahora: lanzamiento, cliente enterprise, ronda, incidente, hueco de contratación o debate interno de arquitectura.
El código dejó de ser el cuello de botella
La IA escribe código más rápido de lo que la mayoría de los equipos puede revisarlo. Lo que sigue siendo escaso es el criterio para decidir qué construir, en qué orden, y qué se va a romper en silencio dentro de seis meses. Eso no se genera. Se acumula, casi siempre de a un incidente en producción por vez.
La mayoría de los proyectos no fracasa por falta de desarrolladores. Fracasa porque nadie con suficientes cicatrices está sosteniendo la forma del sistema: qué concesiones vale la pena hacer, qué atajos se convierten en la reescritura del año que viene, y cuándo la opción aburrida es la correcta.
Esa es la parte que aportamos. Usamos IA todos los días y nos hace más rápidos, pero no decide la arquitectura ni carga con las consecuencias de equivocarse. Alguien tiene que hacerlo, y eso es lo que en realidad se contrata.
Qué podemos ejecutar después del diagnóstico
La revisión es la puerta de entrada. Si el próximo paso es implementar, estos son los trabajos que tomamos.
Backend y sistemas distribuidos
Servicios orientados a eventos, APIs REST y gRPC, workers asíncronos y colas en Go, Python y TypeScript, con idempotencia y reintentos diseñados de entrada en vez de agregados después del primer cobro duplicado.
Leer másIntegración de hardware e industria
Software que habla con máquinas: telemetría MQTT, control de dispositivos, sistemas embebidos y SIP. Equipos anteriores a la nube, protocolos en un PDF que nadie escaneó, y un entorno de prueba que es una operación andando.
Leer másSistemas de IA en producción
Todo el mundo tiene un prototipo de LLM que funciona en un buen día. Nosotros construimos el puente: recuperación que recupera, respuestas ancladas en sus fuentes, evaluación antes de publicar, y un costo predecible.
Leer másSistemas de IA auditables
Casi ningún equipo con un modelo frente a sus datos puede decir qué vio, por qué respondió eso, ni quién tenía permiso de verlo. Registros, versionado, recuperación con permisos y evaluación, como evidencia y no como documento de política.
Leer másSistemas para agentes de IA
Exponer una API para que un modelo la llame lleva una tarde. Permisos que siguen a la persona, idempotencia para un llamador que reintenta, radio de daño acotado y atribución después son las partes que se rompen.
Leer másRevisión de código generado con IA
Tu equipo escribe código más rápido de lo que alguien puede revisarlo. Leemos lo que se generó, ejercitamos el camino que recorre una persona real, y dejamos a tus desarrolladores con criterio propio para la próxima tanda.
Leer másLiderazgo técnico
Alguien con experiencia que decide cuál de los cinco caminos posibles se toma, escribe por qué, y sigue estando cuando llega la consecuencia. Por horas, para equipos que necesitan criterio más seguido que otro par de manos.
Leer másPlataforma cloud y DevOps
AWS y Kubernetes definidos en Terraform, pipelines que despliegan sin ceremonia, y permisos deliberados en lugar de heredados de quien lo configuró primero.
Leer másObservabilidad y fiabilidad
Trazas con OpenTelemetry, logs y métricas que se conectan, SLOs basados en lo que los usuarios notan, y alertas lo bastante pocas como para que la gente siga confiando en ellas. Suele ser la vía más rápida para bajar el tiempo de recuperación.
Leer másDesarrollo web y de producto
Productos, dashboards y paneles de administración en React y Next.js, hechos por gente que también construyó el backend que hay detrás. Más implementaciones y migraciones de e-commerce.
Leer másMantenimiento y modernización
El sistema que ya funciona y nadie quiere tocar. Actualizaciones, deuda de seguridad, migraciones y soporte continuo, incluso de código que no escribimos nosotros. Modernizado en pasos reversibles en lugar de reescrito.
Leer másRevisión de arquitectura
Dos semanas, precio fijo, un informe escrito: qué se rompe primero, qué cuesta de más, qué traba la entrega, y qué hacer con cada cosa. Autocontenida, y suya para actuar con quien quiera.
Leer másSoluciones que implementamos
Sistemas que ya resolvimos una vez y ahora adaptamos por cliente, para que no esté pagando por redescubrir los mismos problemas.
Asistente de documentos con citas
Haga preguntas sobre sus propios documentos y reciba respuestas que muestran sus fuentes. Recuperación híbrida vectorial y por palabra clave, fusión de rankings, filtrado por diversidad, y una suite de evaluación para que la calidad se mida en lugar de suponerse.
Leer más IA · CalidadSuite de evaluación para funciones de IA
Saber si un cambio de prompt, modelo o recuperación mejoró o empeoró las cosas, antes de que lo descubran sus usuarios. Medido contra un conjunto fijo de preguntas, con costo y latencia por cambio.
Leer más PlataformaPlataforma base para producción
El andamiaje que reutilizamos para llegar rápido a producción sin los atajos que se convierten en la reescritura del año que viene: autenticación y roles, pagos, workers, observabilidad desde el primer día, CI/CD e infraestructura como código.
Leer másElija la forma que encaje
Cuatro modalidades que cubren casi todos los proyectos. Si ninguna encaja, dígalo y buscamos una que sí.
Revisión de arquitectura
Dos semanas, un informe escrito que ordena qué se rompe primero según lo que va a costarle.
Cómo funcionaProyecto cerrado
Un trabajo definido a un precio definido: una integración, un servicio, una migración, un primer sistema en producción.
Contarnos el proyectoIngeniería integrada
Nos sumamos a su equipo una cantidad acordada de días por mes. Su repositorio, sus reuniones, su proceso de revisión.
Consultar disponibilidadRescate y estabilización
Algo se está incendiando o un lanzamiento está en riesgo. Primero estabilizar, después encontrar la causa real.
Qué implicaCómo se desarrolla un proyecto
Sin una fase de descubrimiento que factura tres semanas y produce una presentación.
Una conversación real
Treinta minutos sobre qué están construyendo o qué se está rompiendo. Si no somos los indicados, lo decimos.
Propuesta acotada
Qué vamos a hacer, qué no, cuánto lleva y cuánto cuesta. Por escrito, antes de que empiece nada.
Entregas parciales
Software funcionando en su entorno, temprano y seguido, en vez de una gran presentación al final.
Un traspaso que sostiene
Documentación, runbooks y una recorrida, para que no nos necesiten contratados para mantenerlo vivo.
El código que dejamos
Tiene que poder crecer sin nosotros. Fronteras explícitas entre dominio e infraestructura, dependencias que apuntan hacia adentro, y pruebas en los niveles que se ganan su lugar. Nada de eso es purismo: se trata de que la próxima función no cueste el triple que la anterior, y de que dentro de dos años el sistema todavía se pueda modificar por alguien que no estaba cuando se escribió. Donde un patrón no se paga solo, lo dejamos afuera y explicamos por qué.
Qué elegimos, y por qué
Lo interesante de un stack no es la lista. Es saber cuándo no usar algo. Estos son los valores por defecto que defendemos, y los casos en los que argumentamos en contra. Para que quede claro: esto describe lo que recomendamos, no con lo que trabajamos. Si su equipo ya usa otra cosa y la mantiene bien, trabajamos en eso.
Go para el camino caliente
Cuando un p99 importa más que la comodidad de quien programa: servicios sensibles a la latencia, mucha concurrencia, workers de larga duración. Comportamiento de memoria predecible y un despliegue que es un solo binario.
No para un panel de administración CRUD. Estaría pagando en verbosidad por un rendimiento que nadie pidió.
Python donde el ecosistema decide
Trabajo de IA y datos, donde cada librería que necesita ya existe y reimplementarla en otro lado es un mal negocio. FastAPI cuando tiene que ser un servicio y no un script.
No para un piso de latencia medido en milisegundos de un dígito con mucha concurrencia.
TypeScript para no alejarse del equipo
Cuando sus ingenieros ya viven en Node, o cuando frontend y backend deberían compartir los mismos tipos y dejar de discutir sobre la forma de una respuesta.
No como excusa para tener un solo lenguaje en todos lados. Ese argumento suele costar más de lo que ahorra.
PostgreSQL hasta que se demuestre lo contrario
El valor por defecto, y sigue siéndolo por más tiempo del que la mayoría espera. Hace JSON, búsqueda de texto completo, colas a volumen moderado y búsqueda vectorial con pgvector.
Buscar otra cosa cuando el patrón de acceso realmente lo exige, que es menos frecuente de lo que sugiere el diagrama de arquitectura.
Kubernetes solo cuando se paga solo
Vale su complejidad cuando se corren muchos servicios, hace falta escalado fino, y existe la madurez operativa para sostenerlo.
No para cinco servicios. Las plataformas de contenedores gestionadas son más baratas de operar y muchísimo más baratas de entender, y preferimos decirlo antes que venderle un cluster.
OpenTelemetry para que los datos sigan siendo suyos
Instrumentación neutral respecto del proveedor, para que su telemetría pueda pasar de Datadog a Grafana o a lo que venga sin reinstrumentar cada servicio.
Evitar instrumentar con el SDK propietario de un solo proveedor. Es la decisión que se lamenta cuando toca renovar el contrato.
También en uso habitual: Kafka, RabbitMQ y Amazon SQS · Redis · MySQL y MongoDB · PHP 8, Laravel, Symfony y Django · gRPC y WebSockets · AWS, EKS y GCP · Terraform, Docker y GitHub Actions · Prometheus, Grafana y Datadog · React, Next.js y Tailwind · APIs de OpenAI, LangChain y LangGraph · Asterisk, Kamailio y MQTT.
Prácticas, para quien las busca por su nombre: arquitectura hexagonal, diseño guiado por el dominio, CQRS y event sourcing donde el dominio lo justifica, principios SOLID aplicados con criterio y no como doctrina, inversión de dependencias, pruebas de contrato e integración, trunk-based development y revisión de código.
También hemos entregado trabajo en producción con Scala y Java. Lo que se contrata acá es criterio de arquitectura, no sintaxis: idempotencia, contrapresión, límites transaccionales y diseño de fallas son el mismo problema en cualquier lenguaje, y el lenguaje es el vehículo. Si su equipo usa algo que no figura en la lista, consúltenos igual. Si no somos los indicados, se lo decimos y le indicamos dónde buscar.
Rubros donde ya entregamos
Útil sobre todo porque significa empezar con el vocabulario y los casos límite ya conocidos.
Pagos y suscripciones
Integraciones con pasarelas, facturación recurrente, conciliación y flujos de pago a terceros.
E-commerce
Implementación y migración de plataformas en Magento, PrestaShop y WooCommerce.
Medios y streaming
Pipelines de video, transcodificación, entrega bajo demanda y generación de medios asistida por IA.
Educación
Administración escolar, pagos, cursada y plataformas de gestión.
Agro y ganadería
Gestión ganadera con IoT y software multiempresa de operaciones a campo.
VoIP y telefonía
Trabajo con Asterisk y Kamailio, manejo de tráfico SIP y sistemas de call center.
Integración con hardware
Aplicaciones que hablan con sistemas embebidos, telemetría MQTT y control de dispositivos.
Hotelería y gastronomía
Gestión de clientes, pagos y entregas para restaurantes y hoteles.
Preguntas frecuentes
¿Qué hace Devsitia IT exactamente?
Construimos y estabilizamos sistemas backend: APIs, servicios orientados a eventos, workers asíncronos y la infraestructura cloud sobre la que corren. En la práctica nos llaman por una de tres razones. Hay que construir algo y tiene que aguantar tráfico real. Algo ya existe y se sigue cayendo. O una función de IA anda en la demo y nadie sabe cómo llevarla a producción.
¿Trabajan con un equipo de ingeniería existente, o solo proyectos desde cero?
Ambos, y la mayor parte de nuestro trabajo es lo primero. Habitualmente nos integramos junto a un equipo interno, trabajando en su repositorio, su proceso de revisión y su pipeline de despliegue. El objetivo es que sus ingenieros puedan mantener lo que dejamos sin nosotros.
¿Cómo cobran?
Alcance y precio fijos cuando el problema está bien definido, como una revisión de arquitectura o una integración puntual. Mensual para trabajo de ingeniería continuo. Ponemos la cifra por escrito antes de empezar, y preferimos rechazar un trabajo antes que cotizar algo que no creemos.
¿Dónde están, y cómo funciona eso con las zonas horarias?
Devsitia IT está en Argentina y trabaja en remoto con clientes de todo el mundo. Nuestra jornada se superpone casi por completo con América del Norte y cubre la mañana en Europa, así que la mayoría de los equipos consigue colaboración en tiempo real en lugar de esperar de un día para el otro. Trabajamos en español e inglés.
Tenemos un prototipo de LLM que funciona a veces. ¿Pueden hacerlo confiable?
Es uno de los pedidos más comunes que recibimos, y rara vez es un problema del modelo. Casi siempre es la calidad de la recuperación, la falta de evaluación, la ausencia de guardrails, un costo sin techo, o una arquitectura que supone que el modelo siempre responde rápido y bien. Empezamos midiendo cuán seguido se equivoca, y después corregimos las partes que lo causan.
¿Con qué tamaño de empresa trabajan?
Mayormente startups y equipos de producto, desde empresas antes del lanzamiento que necesitan un primer sistema en producción hasta plataformas establecidas con problemas de escala o fiabilidad. Somos un equipo chico y senior, así que tomamos una cantidad limitada de proyectos a la vez.
¿En cuánto tiempo pueden empezar?
Una revisión de arquitectura suele poder empezar en una o dos semanas. Los proyectos más grandes dependen de los compromisos vigentes. La forma más rápida de saberlo es escribirnos con un par de frases sobre el problema.
Pedir una revisión de arquitectura
Envíe unas líneas sobre el sistema, el riesgo o la fecha límite. Va a recibir una respuesta directa de un ingeniero, no un libreto de ventas.