Soldier Dev Studio

Un estudio técnico pequeño, con nombres y apellidos detrás de cada proyecto

Soldier Dev Studio nació de años trabajando dentro de equipos de operaciones, viendo de cerca cómo un sistema mal documentado puede frenar a toda una empresa. No somos una agencia con departamentos separados: las mismas personas que auditan el código son las que escriben la refactorización y responden cuando algo falla un martes por la noche. Preferimos decir que no a un proyecto antes que aceptar algo que no vamos a poder sostener en el tiempo.

Quiénes somos

Un estudio técnico que prefiere el código aburrido y duradero

Soldier Dev Studio nació de una idea simple: la mayoría de las pymes no necesita una plataforma nueva cada dos años, necesita sistemas internos que sigan funcionando cuando el equipo cambia, cuando el proveedor desaparece y cuando el volumen crece. Trabajamos con equipos de operaciones que arrastran planillas, macros y aplicaciones que nadie quiere tocar.

No vendemos demos. Entramos en proyectos donde el código tiene que aguantar años de uso real, con mantenimiento, auditorías y soporte mensual. Si algo no encaja con lo que hacemos, lo decimos antes de firmar nada.

Para quién

Pymes tecnológicas, áreas de operaciones y equipos internos que sostienen procesos críticos sobre software heredado o integraciones frágiles.

Cómo trabajamos

Stacks concretos: Python, Node, PostgreSQL y Docker. Despliegues en servidor propio o cloud, sin capas innecesarias ni dependencias que no podamos mantener.

Soldier Dev Studio company

// principios del estudio

01. Si no podemos mantenerlo, no lo construimos.

02. Documentamos para que el equipo siga sin nosotros.

03. Preferimos decir no antes que entregar deuda técnica.

04. Los tiempos de respuesta se acuerdan por escrito.

Cómo llegamos hasta acá

Soldier Dev Studio no nació como una agencia ni como un producto. Empezó como un grupo chico de gente que arreglaba sistemas que otros habían abandonado, y fue creciendo a fuerza de quedarse en los proyectos cuando lo divertido ya había pasado.

  1. Etapa 01

    Trabajos sueltos

    Arreglar lo que nadie quería tocar

    Los primeros encargos llegaron por recomendación: scripts en Python que se caían de noche, planillas que se rompían al cambiar una columna, un ERP interno que solo entendía la persona que lo había escrito. Aprendimos ahí que el código real vive en servidores viejos, con datos sucios y sin documentación.

  2. Etapa 02

    Método propio

    Definir un stack y sostenerlo

    Dejamos de aceptar cualquier tecnología. Nos quedamos con Python, Node, PostgreSQL y Docker porque nos permiten auditar, refactorizar y desplegar sin depender de plataformas cerradas. Estandarizar el stack nos dio algo más valioso que la comodidad: poder volver a un proyecto dos años después y entenderlo.

  3. Etapa 03

    Soporte continuo

    Quedarnos después de la entrega

    Varios clientes nos pidieron lo mismo: alguien que responda cuando algo se rompe un martes a la mañana. Armamos acuerdos de soporte mensual con tiempos de respuesta explícitos y un canal directo, sin tickets que rebotan entre áreas. Eso cambió la relación: dejamos de ser un proveedor externo y pasamos a ser parte del equipo de operaciones.

  4. Etapa 04

    Hoy

    Menos proyectos, más profundidad

    Trabajamos con un número acotado de pymes y equipos internos. Preferimos decir que no a un proyecto antes que aceptarlo y dejarlo a medias. La mayoría de lo que hacemos hoy son integraciones de API, automatización de procesos repetitivos y mantenimiento de sistemas que ya llevan años en producción.

Configuracion de cookiesUsamos cookies para mantener el sitio estable, recordar opciones basicas y entender que paginas resultan utiles. Puedes aceptar, rechazar o revisar la configuracion antes de continuar.