El diseño técnico va antes que la primera línea de código
Cada proyecto arranca con un documento de arquitectura: contratos de datos, presupuesto de rendimiento, modelo de despliegue y estándares de código. Se revisa con usted antes de que empiece a correr el reloj.
Escribimos el premortem al principio, no el postmortem al final
Damos el proyecto por fracasado y documentamos por qué: supuestos frágiles, dependencias del proveedor, capacidad real del equipo que va a operarlo. Los riesgos que aceptamos quedan por escrito, con el motivo.
Quien decide la arquitectura es quien la construye
No hay una capa de gestión traduciendo entre usted y el código. Habla con la persona que va a resolver el problema, en la primera reunión y en la última.
El control de despacho de concentrado vivía en tres hojas de cálculo que solo una persona sabía cerrar.
Sistema de pesaje y despacho con doble control, bitácora inmutable y cierre diario que no depende de quién esté de turno.
Banca
La originación de crédito se documentaba en papel y correo, sin trazabilidad de quién aprobó qué ni cuándo.
Flujo de aprobación con roles, expediente digital y registro de auditoría exportable para el regulador.
Logística
El inventario de bodega se contaba en planillas impresas y se digitaba al día siguiente, con el error ya propagado.
Aplicación Android sobre terminales rugerizados, conteo sin conexión y sincronización contra SAP Business One al recuperar señal.
Agroindustria
Cada planta reportaba producción en un formato distinto y consolidar el mes tomaba una semana de trabajo manual.
Captura estandarizada en planta e integración con el ERP existente, con reglas de validación en el punto de carga.
De la primera reunión a producción.
Blueprint
Arquitectura, contratos de datos, presupuesto de rendimiento y plan de despliegue. Por escrito y revisado con usted antes de construir nada.
Premortem
Los modos de fallo del proyecto, documentados al principio. Lo que no se puede mitigar se acepta de forma explícita y queda registrado con su motivo.
Construcción por fases
Cada fase termina en algo desplegado y usable. Nada queda esperando al final una integración que nunca se probó.
Entrega con evidencia
Documentación de operación, respaldos probados y una restauración ejecutada al menos una vez delante de su equipo, antes del cierre.
De dónde viene el nombre, y quién contesta el teléfono.
El nombre
Una maestranza es el taller donde se construye y se repara la maquinaria pesada. No fabrica el producto final: fabrica lo que hace posible fabricarlo. Nos pareció el lugar correcto desde donde mirar este oficio.
El equipo
Somos un equipo pequeño de ingenieros acostumbrados a entrar en sistemas que ya estaban en producción. No subcontratamos el desarrollo. La persona que diseña la arquitectura de su proyecto es la que escribe el código y la que contesta el teléfono cuando algo falla.
Con qué construimos.
Elegimos herramientas por cuánto tiempo llevan siendo aburridas. La lista es corta a propósito.
Servidor y datos
PostgreSQL
MySQL
Node.js
PHP 8.2
Python
Redis
Aplicaciones
TypeScript
React
Astro
Kotlin
Android SDK
Tailwind CSS
Integración y operación
SAP B1 Service Layer
SAP B1 DI API
Docker
GitHub Actions
Cloudflare
Grafana
Lo que nos preguntan antes de firmar.
¿Trabajan con alcance cerrado o por horas?
Las dos formas, según el proyecto. Lo que no hacemos es cerrar un alcance sin blueprint: un precio fijo sobre un alcance que nadie diseñó no es un acuerdo, es un conflicto aplazado.
¿De quién es el código cuando termina el proyecto?
Suyo. La entrega incluye el repositorio completo, la documentación de despliegue y las credenciales. No dejamos piezas atadas a nuestra infraestructura.
¿Qué pasa si el proyecto se detiene a mitad de camino?
Cada fase termina en algo desplegado y en uso. Si se detiene en la segunda, la primera ya está en producción y le sirve igual. Esa es la razón de construir por fases.
¿Por qué los casos no nombran al cliente?
Porque el contrato lo impide en casi todos, y donde no lo impide tampoco pedimos la excepción. Quien nos deja entrar en su operación necesita saber que no va a terminar en la página de nadie. Si necesita una referencia antes de firmar, la coordinamos con el cliente y se la damos por teléfono.
¿Por qué no publican métricas de impacto?
Porque no las hemos medido con el rigor que haría falta para publicarlas. Preferimos decirlo antes que inventar un porcentaje. Desde el próximo proyecto entregado, la medición es parte del alcance.
¿Pueden integrar con SAP sin poner en riesgo el ERP?
Trabajamos contra la capa de servicio, nunca contra las tablas. El núcleo de SAP no se toca y toda integración se prueba en un ambiente separado antes de llegar a producción.
¿Tiene un problema que no entra en un paquete?
Escríbanos con el problema, no con la solución. Si no somos la firma indicada para resolverlo, se lo decimos en la primera conversación.
Usamos Google Analytics para saber qué páginas se leen. Si acepta, se guarda una cookie que permite reconocer visitas recurrentes. Si rechaza, seguimos contando visitas de forma agregada, sin cookies y sin identificarlo. Política de privacidad