Antes de escribir una línea de código revisamos el sistema que ya tienes, quién lo usa y qué pasa cuando falla. De ahí sale un plan de trabajo por etapas, con entregas parciales y un canal directo para consultas durante todo el proceso.
En cada incorporación repetimos las mismas aclaraciones porque evitan malentendidos más adelante. No son condiciones legales ni letra pequeña: son criterios de trabajo que conviene dejar por escrito desde el primer día.
No hablamos solo de software antiguo. Un sistema es legacy cuando nadie del equipo actual quiere tocarlo, cuando no hay pruebas y cuando cada cambio genera miedo. Puede tener cinco años o quince. Lo que define el trabajo es el estado del código y la documentación, no la fecha del último commit.
El soporte continuo cubre incidencias, ajustes menores y consultas técnicas dentro del horario acordado. Las funcionalidades nuevas se planifican como trabajo aparte. Si una incidencia requiere rediseñar un módulo completo, lo decimos en el momento y se decide si entra en el ciclo o se agenda como proyecto.
Necesitamos acceso a un entorno de pruebas o a una copia de la base de datos antes de tocar producción. Si no existe, la primera tarea suele ser montarlo. Trabajar directamente sobre datos reales sin red de seguridad es algo que evitamos salvo urgencias puntuales y con respaldo previo.
Trabajamos con Python, Node, PostgreSQL y despliegues en Docker, ya sea en servidores propios o en cloud. Si tu proyecto está en otro stack, lo evaluamos caso por caso y te decimos con franqueza si podemos aportar o si conviene buscar otro perfil.
Todo lo que escribimos queda en tu repositorio y es tuyo. No usamos licencias propias ni dependencias cerradas que te aten a nosotros. Si en algún momento decides continuar con otro equipo, la documentación y el historial de decisiones quedan disponibles.
No aceptamos proyectos donde el objetivo sea solo una demo presentable sin intención de mantenerla. Tampoco trabajamos con plazos imposibles ni prometemos fechas que dependan de terceros que no controlamos. Si algo no encaja, lo decimos antes de firmar nada.
El soporte mensual no arranca con una llamada improvisada. Antes de tocar producción necesitamos saber qué sistema es, quién lo usa y qué se rompió. Por eso el primer contacto siempre pasa por un canal escrito: ahí queda el rastro y podemos asignar prioridad sin depender de la memoria de nadie.
Adjunta logs, captura del error y los pasos que lo reproducen. Si el sistema está caído, indícalo en el asunto.
info@softwaresoldier.comReservado a caídas que bloquean la operación. Para dudas de uso o cambios pequeños, mejor por escrito.
+34 995-240815No empezamos escribiendo código. Primero entendemos qué sistema tienes, quién lo usa y qué duele. Estos son los pasos que seguimos desde tu primer mensaje hasta que algo funciona en producción.
Nos escribes contando qué tienes: un sistema que arrastra años, una integración que falla, o tareas manuales que consumen horas. Respondemos con preguntas concretas antes de proponer nada.
Accedemos al repositorio o a un entorno de pruebas. Revisamos estructura, dependencias, cobertura de tests y puntos frágiles. Si no podemos ayudar, lo decimos en esta fase, no después.
Definimos qué se toca, qué se deja intacto y en qué orden. Sin alcances abiertos ni promesas vagas: fases concretas con entregables verificables y criterios de aceptación.
Entregamos en bloques cortos: refactorización de un módulo, una integración nueva, un script de automatización. Cada bloque pasa por revisión antes de tocar producción.
Publicamos con Docker sobre tu servidor o cloud, con logs claros y plan de reversión. Verificamos en producción antes de dar el bloque por cerrado.
Si el sistema queda bajo nuestro mantenimiento, acordamos tiempos de respuesta y ventanas de intervención. Documentamos cada cambio para que tu equipo no dependa de nosotros.
Antes de empezar puedes revisar qué hacemos en capacidades técnicas o ver cómo trabajamos en el estudio.