Principio 01
Código que aguanta años
Escribimos pensando en quien va a mantener esto dentro de tres años, no en la próxima demo.
Somos un equipo pequeño de ingenieros que trabaja codo a codo con áreas de operaciones. Sin intermediarios comerciales: quien escribe el código es quien responde cuando algo falla en producción.
Soldier Dev Studio no nació como una agencia ni como una startup. Empezó como un grupo reducido de gente que arreglaba sistemas que otros habían abandonado, y fue creciendo a medida que esos mismos clientes nos pedían quedarnos.
Los primeros trabajos fueron auditorías de código en sistemas internos que llevaban años sin mantenimiento. Python 2.7, scripts sueltos, bases PostgreSQL sin índices. Aprendimos ahí que el problema casi nunca es el lenguaje, sino la falta de criterio al decidir qué tocar primero.
Con más proyectos encima, fijamos una base concreta: Python y Node para servicios, PostgreSQL como almacenamiento principal, Docker para empaquetar y desplegar. No es una elección dogmática, es la que nos permite entregar algo que otro equipo pueda retomar sin nosotros.
Varios clientes nos pidieron quedarnos después de la entrega. Así apareció el modelo de soporte mensual con tiempos de respuesta acordados por escrito. Dejamos de ser el equipo que aparece cuando algo se rompe y pasamos a revisar antes de que se rompa.
Con el tiempo notamos un patrón: los equipos de operaciones gastaban horas en tareas que un script resuelve en minutos. Empezamos a incluir automatizaciones en cada proyecto, con monitoreo y logs, para que el ahorro de tiempo sea verificable y no una promesa.
Seguimos siendo un equipo reducido y preferimos que así sea. Decimos que no a proyectos donde no aportamos valor, documentamos cada decisión en el repositorio del cliente y dejamos el código en un estado que su propio equipo pueda mantener.
No fue un plan trazado de antemano. Fue una sucesión de proyectos que nos enseñaron qué tipo de trabajo queremos hacer y cuál preferimos dejar pasar.
2016
Empezamos resolviendo scripts puntuales para equipos de logística: limpieza de datos, cruces entre planillas y reportes que nadie quería generar a mano. Todo en Python, casi todo en servidores que ya existían.
2018
Una pyme de distribución nos pidió reemplazar su aplicación interna de pedidos. La escribimos en Node con PostgreSQL, la pusimos en Docker y todavía sigue corriendo. Ahí entendimos que el código que sirve es el que se puede mantener sin nosotros.
2020
Varios clientes nos trajeron sistemas legacy que nadie del equipo interno quería tocar. Aprendimos a leer código ajeno, escribir pruebas de caracterización antes de mover una línea y refactorizar por fases sin detener la operación.
2022
Dejamos de aceptar encargos sueltos sin continuidad. Armamos acuerdos de soporte con tiempos de respuesta definidos, canal único de reporte y una persona de referencia por cliente. Menos urgencias inventadas, más trabajo previsible.
Hoy
Seguimos siendo pocos y preferimos que así sea. Tomamos proyectos donde el código tiene que durar, decimos que no cuando el encargo no encaja y documentamos cada decisión para que el equipo del cliente pueda seguir sin depender de nosotros.
Nuestra misión
Soldier Dev Studio nació de una frustración concreta: demasiados equipos de operaciones cargando con sistemas que nadie quiere tocar, planillas que se copian a mano y APIs que fallan sin dejar rastro. Nos juntamos para trabajar en lo contrario.
No vendemos demos. Entregamos código que tiene que seguir funcionando cuando nosotros ya no estemos en el proyecto.
Principio 01
Escribimos pensando en quien va a mantener esto dentro de tres años, no en la próxima demo.
Principio 02
Si un sistema legacy no vale la pena rescatar, lo decimos antes de firmar nada. Sin rodeos.
Principio 03
Python, Node, PostgreSQL y Docker. Lo que ya funciona en producción, no lo que suena bien en una charla.
Principio 04
Documentamos y explicamos cada decisión para que tu equipo pueda seguir sin depender de nosotros.
Efecto esperado
Que tu equipo recupere las horas que hoy pierde en procesos manuales, que los sistemas dejen de dar miedo y que la operación diaria no dependa de que alguien recuerde cómo se hacía algo. Ese es el resultado que perseguimos en cada proyecto.