Domínio Visual no es una startup. Es una empresa de rotulación visual (letras corpóreas, fachadas, paneles, señalización interior) que trabaja para clientes que necesitan el trabajo instalado en una fecha concreta, no en un sprint hipotético.
Esta pieza trata lo que ocurre cuando un negocio de servicios real decide dejar de gestionar órdenes en hojas de Excel, cuadernos y conversaciones de WhatsApp, y pasa a operar a través de una plataforma digital hecha a medida. Lo que se gana, lo que se pierde y lo que casi siempre sale mal en el primer intento.
Resumen ejecutivo
Un negocio de servicios arrastra tres problemas operativos crónicos: el estado real de cada trabajo está repartido en varias cabezas, el historial del cliente vive en conversaciones y la facturación depende de quien se acuerde de lo que se hizo. Un software genérico no resuelve nada de esto porque el vocabulario es equivocado. La solución es una plataforma pensada alrededor del flujo real de la empresa, con estados que corresponden a las fases físicas del trabajo y una interfaz que cualquier persona del equipo puede usar sin formación.
En el caso de Domínio Visual, esto significó modelar diez estados que van de «visita técnica» a «facturación», una base de datos MariaDB diseñada alrededor de órdenes de trabajo y un frontend que asume que el usuario está en mitad de una obra y no mirando un dashboard de métricas.
El problema de negocio
Una empresa de rotulación funciona por proyecto. Cada orden de trabajo pasa por varias etapas físicas: alguien va al sitio a medir, alguien dibuja el layout, el layout va a aprobación del cliente, se imprime o se corta el material, se monta la estructura metálica si es exterior, se arma en fábrica, se agenda la instalación, se entrega y solo después se factura.
Cada una de estas etapas involucra a personas distintas. El comercial que hizo la visita no es el diseñador que hace el layout. El diseñador no es quien opera la máquina de corte. Quien instala en el sitio rara vez es quien estuvo en la fábrica. Y el cliente llama preguntando «¿cómo va mi trabajo?» a cualquiera de ellos.
Sin plataforma, la respuesta a esa pregunta depende de quién atienda. Cada persona tiene una parte del puzle. La visión consolidada no existe en ningún sitio: está repartida.
Por qué esto importa más de lo que parece
Hay tres costes ocultos en este modelo y todos consumen margen sin aparecer en la cuenta de resultados.
Primero, el coste de coordinación. Cada trabajo genera diez o veinte microconversaciones por WhatsApp para confirmar estado. Multiplica eso por treinta o cuarenta obras en curso y tienes varias horas al día de gente cualificada haciendo el trabajo de un sistema.
Segundo, el coste de retrabajo. Sin historial centralizado, es frecuente rehacer trabajo porque la versión aprobada del layout está enterrada en un correo de hace tres semanas, o porque la medición se anotó a lápiz y nadie la lee.
Tercero, y este es el más caro, el coste de facturación perdida. Trabajos que se instalaron pero nunca se facturaron porque salieron del radar. Ampliaciones acordadas de palabra que nunca llegaron al presupuesto final. Un estudio de Aberdeen Group hace unos años apuntaba que empresas sin procesos digitales estructurados perdían entre un 1 % y un 3 % de los ingresos anuales en facturación no emitida o no cobrada. No es un número que aparezca en ningún sitio: desaparece en silencio.
Qué significa «plataforma digital» para un negocio así
No es un CRM. No es un ERP. No es un Trello con estados personalizados. Es todas esas cosas a la vez, pero con un vocabulario que corresponde exactamente a lo que la empresa hace.
La diferencia es sutil pero decisiva. Si el software llama a una orden de trabajo «deal», «opportunity» o «task», el equipo nunca lo usará con consistencia. Si la llama «OT» y tiene los estados que el equipo ya usa mentalmente (visita, layout, aprobación, impresión, corte, cerrajería, producción, montaje, expedición, facturación), la adopción es inmediata.
Este es el argumento central para software a medida en negocios de servicios: no va de features. Va de lenguaje.
Las decisiones técnicas que importan para el negocio
Cada decisión técnica aquí se tomó pensando en el impacto operativo, no en lo que resulta interesante para el programador.
La base de datos es MariaDB relacional, no una base NoSQL de moda. Porque una orden de trabajo tiene relaciones rígidas con cliente, items, historial y facturación, y cuando un contable necesita lanzar una query para el cierre de año, SQL es un lenguaje que mucha gente sabe leer.
La autenticación usa bcrypt para nuevos usuarios pero mantiene compatibilidad con MD5 heredado. No es elegante. Es pragmático: significa que los usuarios actuales no tienen que recuperar contraseña el día de la migración, y esa es la diferencia entre «todo el mundo lo usa» y «la mitad del equipo se rindió».
El frontend es una SPA rápida servida por Nginx, con una API Fastify en Node.js por detrás. Podría haber sido una aplicación Rails clásica con renderizado del lado del servidor. La elección de la SPA viene de un requisito concreto: quien está sobre el terreno haciendo instalaciones necesita actualizar estado desde el móvil, muchas veces con conexión de datos pobre. Una SPA con estado local y sincronización asíncrona funciona mejor en ese contexto que un sistema que exige round-trip completo en cada clic.
Esta es la única razón por la que la decisión tiene sentido. Si todo el mundo trabajara desde oficina con fibra, una app tradicional habría salido más barata de construir y mantener.
Modelar el flujo real: el problema de los estados
El error más común cuando se digitaliza un negocio así es traducir el flujo real a un modelo simplificado de tres o cuatro estados: pendiente, en curso, concluido. Queda limpio en el diagrama y es inútil sobre el terreno.
Domínio Visual opera con diez estados distintos. Cada uno corresponde a una fase física del trabajo y a un equipo o persona responsable:
- Cerrada (0): estado final, tras facturación
- Visita (1): el comercial va al sitio a medir
- Layout (2): el diseñador crea la propuesta visual
- Impresión (3): vinilo o material impreso
- Corte (4): corte de letras o material rígido
- Cerrajería (5): estructura metálica si aplica
- Producción (6): armado en fábrica
- Montaje (7): instalación en el cliente
- Expedición (8): logística de entrega
- Facturación (9): emisión de factura
- Aprobación de layout (10): el cliente valida antes de imprimir
Este nivel de granularidad no es sobreingeniería. Cada estado corresponde a una persona concreta que necesita saber «qué trabajos están ahora conmigo». Colapsar dos estados en uno significa que esa persona empieza a ver trabajos que no son para ella. La adopción cae de inmediato.
Historial: la feature invisible que resuelve más problemas que cualquier otra
Todas las órdenes de trabajo tienen una tabla asociada de historial. Cada cambio de estado, cada nota, cada adjunto queda registrado con timestamp y usuario que hizo la modificación.
Esta es la feature que nadie pide en la fase de levantamiento y que pasa a ser la más usada seis meses después. Porque resuelve tres problemas operativos que no parecían tener solución técnica:
Cuando el cliente llama a reclamar, cualquier persona puede reconstruir la cronología exacta del trabajo sin depender de la memoria de quien estuvo involucrado.
Cuando hay una discusión interna sobre «quién dijo qué a quién», existe un registro neutro que la zanja en segundos.
Cuando entra alguien nuevo al equipo, puede entender el contexto de trabajos antiguos sin tener que preguntar a cinco personas.
La regla práctica es: si algo puede generar una pregunta tipo «¿pero cuándo fue que...?» o «¿quién fue el que...?» tres meses después, tiene que estar en el historial. Siempre.
Qué casi siempre sale mal en el primer intento
Vale la pena ser específico sobre los errores que aparecen en casi todos los proyectos de este tipo, para que quien esté considerando avanzar sepa qué evitar.
Error uno: empezar por el módulo de facturación. Es intuitivo (la facturación es donde entra el dinero, así que parece prioritario). Es equivocado. Si el resto del sistema no se está usando, la facturación se seguirá haciendo fuera del sistema como antes. Empieza por el estado operativo de las órdenes; la facturación sigue de manera natural.
Error dos: pedir opinión a todo el equipo antes de construir. Cada persona quiere optimizar el software para su parte del flujo, lo que genera un Frankenstein de features contradictorias. Elige a una o dos personas con experiencia que vean el negocio de punta a punta e ignora al resto hasta que haya una versión funcional sobre la que reaccionar.
Error tres: no migrar datos históricos. Un sistema nuevo sin los últimos dos años de trabajos es un sistema vacío. El equipo sigue entrando al viejo para consultar el pasado. La migración de datos es tediosa, técnica y nada glamurosa, pero sin ella la adopción siempre queda a medias.
Error cuatro: dashboards antes de flujo. Los gráficos los mira la dirección una vez por semana. El flujo diario lo usa todo el mundo. Una plataforma sin dashboards pero con flujo funcional sirve desde el día uno. Al revés, no.
Buenas prácticas que valen para cualquier negocio de servicios
Domínio Visual es rotulación, pero el patrón aplica a cualquier empresa que venda proyectos: agencias creativas, construcción, arquitectura, talleres, imprentas, integradores de AV, empresas de eventos.
- Modela los estados que el equipo ya usa mentalmente, no los que parecen limpios en un diagrama
- El historial de cada trabajo es obligatorio, no opcional
- Autenticación híbrida durante la migración: no obligues a todo el mundo a recuperar contraseña el primer día
- Base de datos relacional para datos operativos; si necesitas análisis complejo después, exporta
- Interfaz pensada para uso en móvil con mala conexión, no para monitor de oficina
- La facturación llega después de que el flujo operativo esté consolidado, nunca antes
- Un responsable interno con poder de decisión para el proyecto, no un comité
Sobre la elección entre software genérico y a medida
La pregunta correcta no es «¿cuesta más hacerlo a medida?». Cuesta más. La pregunta es: cuánto vale que el equipo use el sistema cada día y no lo abandone al cabo de tres meses.
El software genérico (un Monday, un Asana, un HubSpot adaptado con campos personalizados) es más barato de comprar. También es sistemáticamente más caro de mantener, porque obliga al equipo a traducir mentalmente el vocabulario del software al vocabulario del negocio. Esa traducción falla precisamente en los momentos en que el sistema más necesita usarse: cuando hay presión, cliente enfadado, plazo apretado.
El software a medida con vocabulario propio elimina esa traducción. El coste inicial es mayor. El coste total de propiedad a cinco años es casi siempre menor. Y el valor de tener datos operativos estructurados en tu propio esquema (que puedes consultar, exportar y analizar sin depender de exports limitados de terceros) es difícil de sobreestimar.
Esta no es una regla universal. Un equipo pequeño que arranca debería usar Notion o una hoja de cálculo hasta que duela. Cuando empieza a doler, es la señal para construir.
Seguridad y continuidad
Una plataforma que gestiona órdenes de trabajo, datos de cliente e historial de facturación se vuelve rápidamente crítica para el negocio. Esto obliga a tres disciplinas que las empresas de servicios tradicionalmente subestiman.
Backups. No semanales. Diarios como mínimo, idealmente incrementales por hora. Probados. Un backup nunca probado es una esperanza, no una garantía. Haz una restauración completa en un entorno separado al menos dos veces al año.
HTTPS obligatorio y certificados renovados automáticamente con Let's Encrypt. Esto es estándar desde 2016 y todavía hoy aparecen empresas con el candado roto en el navegador. No hay justificación técnica en 2026 para servir una aplicación de gestión empresarial sobre HTTP.
Control de acceso por rol. No todo el mundo necesita verlo todo. Si el comercial no necesita ver márgenes, no los ve. Si el instalador solo necesita la dirección y el horario, es lo único que aparece. El principio del mínimo privilegio, como el OWASP describe desde hace décadas, no es paranoia: es higiene básica.
RGPD: qué cambia cuando el software es propio
Las empresas de servicios en España manejan datos personales de clientes: nombres, direcciones, contactos, muchas veces NIF o DNI. El RGPD, en su Artículo 6, exige base legal clara para el tratamiento de estos datos, y el Artículo 32 exige medidas técnicas apropiadas.
El software propio da ventajas concretas aquí: puedes implementar retención de datos adecuada, seudonimización donde tenga sentido, derecho al borrado sin depender de tickets de soporte a proveedores externos y logs auditables del quién-hizo-qué. El software SaaS genérico ofrece todo esto en teoría; en la práctica, cada una de estas capacidades depende del plan contratado y de la respuesta del soporte.
Coste real: lo que nadie dice en las propuestas
Un proyecto como este, hecho bien, tiene cuatro componentes de coste que la mayoría de las propuestas subestima.
El desarrollo inicial es la parte visible: la construcción de la aplicación, el diseño, las pruebas, la puesta en producción. Suele estar entre el 40 % y el 60 % del coste total en el primer año.
La migración de datos está siempre subestimada. Extraer datos de Excels, hojas de papel digitalizadas, sistemas antiguos, y transformarlos en algo consistente para importar consume más tiempo del que cualquier estimación razonable sugiere. Reserva al menos un 15 % del presupuesto.
Formación y acompañamiento en las primeras semanas. Las dos primeras semanas tras el arranque determinan si la adopción cuaja o no. Tener a alguien disponible para resolver dudas, corregir bugs pequeños rápido y ajustar detalles de UX es lo que separa «el equipo lo adoptó» de «el equipo volvió a WhatsApp».
Mantenimiento continuo. Servidor, backups, actualizaciones de seguridad, pequeñas mejoras mensuales. Un importe mensual previsible que muchas empresas prefieren fingir que no existe hasta que el sistema se rompe.
Señales de que es hora de hacerlo
Algunas señales concretas, de la más suave a la más grave, que indican que una empresa de servicios está llegando al límite del modelo de gestión manual:
- Recibes llamadas de clientes preguntando por trabajos y necesitas consultar a tres personas antes de responder
- La persona que gestiona el Excel principal se fue de vacaciones y el negocio se frenó
- Descubres trabajos terminados hace semanas que nunca se facturaron
- Las discusiones internas acaban con un «pensé que ibas a ocuparte tú»
- Los nuevos miembros tardan semanas en entender dónde está qué
- Cuando creces un 20 %, la coordinación empeora exponencialmente en vez de escalar linealmente
Si reconoces dos o tres de estas señales, probablemente es la hora. Si reconoces cuatro o más, era la hora hace dos años.
Key takeaways
Un negocio de servicios no necesita tecnología impresionante. Necesita un sistema que use el vocabulario correcto, capture el estado real del trabajo, mantenga historial auditable y funcione en el móvil de quien está sobre el terreno.
La decisión entre genérico y a medida es una decisión sobre coste total de propiedad y sobre la probabilidad real de adopción por parte del equipo. Lo genérico es más barato de arrancar; lo hecho a medida es más barato de mantener y usar. Para operaciones críticas, lo hecho a medida casi siempre gana a tres o cinco años.
La migración es una cuestión de gestión del cambio más que de ingeniería. Que el software esté listo es una condición necesaria pero no suficiente. Sin un responsable interno con autoridad y sin migración seria de datos históricos, incluso el mejor sistema queda a medio adoptar.
La próxima pieza editorial mira a lo contrario: cuándo tiene sentido mantenerlo todo en hojas de cálculo y resistir la tentación de digitalizar demasiado pronto. No toda empresa está lista, y a veces construir un sistema es otra forma de postergar decisiones operativas que hay que tomar antes.