Software a medida, integraciones y soporte parecen tres servicios distintos. No lo son.
Son tres momentos de la misma tarea: hacer que un negocio funcione con menos fricción.
Casi siempre, el problema que llega como "necesitamos un sistema nuevo" en realidad es otra cosa. A veces es un sistema viejo que nadie mantiene. A veces son dos herramientas que no se hablan. A veces es un proceso que nunca se escribió y vive en la cabeza de una sola persona.
Mi trabajo empieza ahí: entender cuál de esas cosas es, antes de proponer construir algo.
Construir software desde cero es caro y lento. Por eso casi nunca debería ser la primera respuesta.
La primera pregunta siempre es si el problema ya tiene solución. Si existe una herramienta que resuelve el 80% de lo que necesitas, úsala. Vas a ahorrar dinero, tiempo y dolores de cabeza que no sabías que existían.
El software a medida tiene sentido cuando la operación del negocio tiene una lógica que ninguna herramienta genérica entiende. Reglas específicas. Flujos que no encajan en las plantillas. Datos que se mueven entre áreas de una forma que sólo tu negocio usa.
En esos casos, forzar una herramienta genérica sale más caro que construirla. Terminas con procesos rotos, trabajo manual duplicado y un equipo peleando contra el sistema en vez de usarlo.
Eso es software a medida: resolver el problema específico con la estructura mínima que funcione. Ni más, ni menos.
La mayoría de los negocios no necesitan más herramientas. Necesitan que las que ya tienen se hablen entre sí.
Una integración bien hecha es invisible. Los datos pasan de un lugar a otro sin que nadie tenga que copiarlos a mano, sin hojas de Excel intermedias, sin esa persona del equipo que se la pasa "actualizando el sistema" en lugar de hacer su trabajo real.
Esto suena obvio. En la práctica casi nadie lo hace bien. Las integraciones fallan por razones aburridas: un campo que cambia de nombre, una API que se actualiza sin avisar, un error que nadie ve durante tres semanas hasta que un cliente reclama. Una integración seria contempla esos casos desde el principio. Una integración mal hecha los descubre cuando ya hay daño.
Integrar bien es hacer que las herramientas existentes se comporten como un solo sistema.
Una solución que depende del entusiasmo inicial no es una solución seria.
El software no se termina cuando se entrega. Se entrega cuando empieza a vivir. Después del lanzamiento aparecen las cosas que ningún plan contempla: un caso que nadie había visto, un usuario que usa el sistema de una forma inesperada, una actualización del sistema operativo que rompe algo, un dato corrupto que entra por una puerta que parecía cerrada.
El soporte serio no es estar disponible para apagar incendios. Es diseñar el sistema desde el principio para que los incendios sean raros, y para que cuando ocurran se puedan resolver sin re-escribir nada.
Eso significa cosas concretas: documentación que un humano puede leer, errores que dicen lo que pasó en lugar de un código numérico, registros que permiten reconstruir qué hizo el sistema y por qué, y una responsabilidad bien definida para cada parte del sistema. Sin eso, el soporte se convierte en arqueología.
Diseñadores, estudios y agencias casi siempre tienen el mismo problema: la idea está clara, el diseño está terminado, y entre eso y algo que funcione en producción hay un hueco que nadie quiere cruzar.
Ese hueco no es técnico nada más. Es de traducción. Un Figma no es una instrucción de implementación. Una animación bonita en After Effects no dice cómo se comporta en un navegador real con conexión lenta. Un moodboard no resuelve qué pasa cuando el cliente sube una imagen de 12 megas.
Mi trabajo con creativos es ser la parte que cruza ese hueco sin romper lo que ya estaba bien pensado. No vengo a rediseñar. Vengo a hacer que lo diseñado exista, funcione, y siga funcionando cuando el proyecto se entregue.
En la práctica eso significa cosas como: tomar un diseño y convertirlo en HTML y CSS que respetan el sistema visual hasta el detalle; montar el backend mínimo para que un sitio editorial sea editable sin tocar código; conectar una tienda con un inventario real; o resolver la parte técnica de una campaña que el estudio ya vendió pero no sabe cómo ejecutar.
No firmo el trabajo. No compito por el cliente. El estudio o el creativo mantiene la relación, yo entrego la parte técnica con la calidad que el proyecto merece, y todos quedamos bien.
Antes de escribir código, entiendo la lógica del negocio. No la versión que está en el organigrama. La versión real, la que pasa cuando el cliente llama a las cinco de la tarde de un viernes.
Esa parte casi siempre toma más tiempo de lo que la gente espera, y casi siempre es la que decide si el proyecto va a funcionar. Un sistema construido sobre una lógica mal entendida no se arregla con más código. Se reescribe.
Después de eso, el trabajo es ordenado y aburrido en el buen sentido: estructura simple, datos limpios, responsabilidades definidas para cada cosa, y entregas que funcionan en producción, no en una demo.
No prometo magia. Prometo que el sistema va a hacer lo que dijimos que iba a hacer, que va a seguir funcionando cuando yo no esté mirando, y que cuando algo cambie en el negocio, el sistema se va a poder cambiar también.
La herramienta cambia. La lógica no.
Si tienes un problema que parece de software pero sospechas que es otra cosa, probablemente tienes razón. Hablemos.