Antes de invertir tiempo y dinero en lanzar un servicio de "dashboards/sistemas a la medida", hay que ver los problemas reales a futuro con los ojos abiertos. Este documento cuestiona la idea, expone los riesgos, y propone la ruta que sí funciona.
La oportunidad es real, pero el modelo "custom desde cero por cliente" es una trampa que nos convertiría en una fábrica de software esclava del mantenimiento. Solo gana si hacemos lo contrario: productizar nuestra base actual (no reconstruir por cliente) y enicharlo a un vertical donde esa base encaje en el 80-90% de fábrica. Y aun así, es otro negocio — hay que entrar con 1-2 clientes piloto antes de comprometer recursos, no a ciegas.
Tu intuición ya apuntaba al lugar correcto ("¿todo desde cero o partir de una base? ¿enicharlo para que la base encaje?"). Este informe confirma esa dirección y la aterriza — pero primero hay que mirar de frente por qué el camino "obvio" (vender software custom) es justo el que quiebra a la mayoría de las agencias que lo intentan.
No es humo. Hay tres cosas reales a favor:
"Tenemos algo valioso + hay demanda" NO significa "es fácil de vender como servicio". Entre el activo que tenemos y un negocio sano hay un campo minado. Vamos a los minas.
Ordenados por qué tan letales son para el negocio. Cada uno con su mitigación.
"100% a la medida por cliente" = un negocio de servicios que no escala. Cada cliente es un código nuevo. Los ingresos crecen solo si contratas más devs. Los márgenes se los come el mantenimiento. Terminas siendo un dev-shop, no una empresa de producto — el destino de casi toda agencia que intenta esto.
Cada cliente que entra es un pasivo permanente: bugs, integraciones que se rompen (las APIs de Meta/Shopify cambian sin avisar), uptime, seguridad, peticiones nuevas. 10 clientes = 10 sistemas que mantener vivos para siempre. Llega el punto en que el mantenimiento consume el 100% del tiempo y ya no puedes vender nada nuevo porque estás apagando incendios.
DAR es una agencia de performance que funciona. Un negocio de software-como-servicio tiene habilidades (producto, ingeniería, soporte 24/7), economía y ritmo distintos. Lanzarlo puede robarle foco, talento y energía al core. Dos negocios con media atención cada uno = dos negocios mediocres.
"Totalmente a la medida" suena increíble en la venta y es una pesadilla en la entrega. Cada cliente quiere su cosa especial. Estimar, cotizar y entregar scope custom sin reventar tiempos y márgenes es de lo más difícil que hay.
Venderle un sistema de $20-50k+ a un dueño de negocio en EE.UU. es una venta larga y de alto toque. Requiere casos de éxito... que aún no tenemos de este servicio (los de DAR son de marketing, no de software). El primer año se vende a pura credibilidad y fe.
Manejarías la data financiera y operativa de tus clientes + sus integraciones (Meta, Shopify, Stripe). Eso es responsabilidad seria. Una fuga o pérdida de datos es catastrófica y con implicaciones legales (contratos, seguros, privacidad EE.UU.).
Hoy esto lo construye Daniel + IA. Para soportar N clientes en producción necesitas un equipo real de dev/soporte. La ventaja de "lo hicimos barato con IA" se erosiona cuando necesitas humanos disponibles para mantener sistemas vivos. Y si todo depende de una persona, un día enfermo tumba a los clientes.
Si cobras solo un one-time por construir, heredas el mantenimiento gratis (fatal). Si cobras recurrente, tienes que justificar valor continuo. Elegir mal el modelo hunde la economía del negocio.
La pregunta que hiciste. Aquí está en una tabla.
| A · Custom desde cero | B · Base configurable | C · Vertical (nicho) 🏆 | |
|---|---|---|---|
| Escalabilidad | Mala (lineal con devs) | Buena | Excelente |
| Mantenimiento | O(N) — cada cliente su código | O(1) — base compartida | O(1) |
| Margen | Se erosiona | Sano | El mejor |
| Encaje con el prospecto | 100% pero carísimo | 70-90% + config | ~90% de fábrica |
| Defensibilidad | Baja | Media | Alta (expertise de nicho) |
| Velocidad de entrega | Lenta | Rápida | La más rápida |
| Riesgo dominante | Trampa de dev-shop | Manejable | El más bajo |
Enicharlo (Modelo C), entregado como base productizada (Modelo B), reutilizando el dashboard de DAR como esa base. Nunca desde cero (Modelo A). El nicho hace que la base encaje casi completa de fábrica; la base productizada hace que el mantenimiento no te mate; y reutilizar lo que ya tenemos nos da años de ventaja el día uno.
En cristiano: no vendemos "te construimos lo que quieras". Vendemos "el sistema operativo para [un tipo de negocio específico]" — y lo entregamos configurando una plataforma que ya existe.
No tiramos años de trabajo reconstruyendo por cliente. Convertimos el dashboard de DAR en una plataforma multi-tenant (un código, muchos clientes, cada uno aislado) + configuración por cliente. Módulos verdaderamente custom = cobrados aparte.
¿Por qué este nicho primero? Porque es el que DAR VIVE. Todas las agencias/marcas DTC operan parecido (campañas, creativos, clientes, cobranza, reportes). Eso significa:
Casi no hay que customizar: ya construimos exactamente para esta operación.
"Somos una agencia, construimos esto para nosotros" le pega directo a otra agencia.
Un generalista no puede competir con quien VIVE el nicho. El expertise es el foso.
Hablas su idioma. Los casos de un cliente sirven de prueba para el siguiente.
Más adelante se pueden abrir otros verticales (uno a la vez). Pero foco brutal en uno primero.
Por fases. Cada una valida antes de comprometer más.
Definir multi-tenancy y separar la "base del producto" del código interno de DAR. Sin esto, todo lo demás hereda la trampa de O(N). Es la decisión técnica más importante del proyecto.
Del mismo nicho. A mano, muy de cerca, precio de piloto a cambio de testimonios y aprendizaje. CERO promesa de escala todavía. El objetivo es aprender qué es realmente común vs. custom — no facturar.
Con lo aprendido en los pilotos, convertir lo repetido en una base configurable. Aquí nace el "producto" de verdad: onboarding replicable, no reconstrucción.
Antes de pasar de ~3-5 clientes: proceso de soporte, acuerdos de servicio, y una persona dedicada a dev/soporte. Documentar la base. Reducir el bus factor.
Con casos reales y base productizada, el motor de ventas se vuelve repetible. Cada cliente refuerza la credibilidad para el siguiente. Aquí sí se pisa el acelerador.
Solo cuando el primero esté sano y auto-sostenido. Nunca dos nichos a medio hacer.
Reglas honestas para no enamorarnos de un negocio que no está funcionando:
Si a los 2 pilotos el modelo se siente como "consultoría de software a la medida" (cada cliente un mundo, todo a mano, mantenimiento infinito) en lugar de "configurar una plataforma que ya existe" — el modelo está mal y hay que rediseñarlo antes de escalar, no empujarlo con fuerza bruta.
La idea vale la pena si y solo si resistimos la tentación de vender "custom" y en su lugar construimos disciplina de producto: base compartida, un nicho, precio recurrente, y pilotos antes de escalar.
Productizar la base · enicharlo (agencias/DTC) · 1-2 pilotos · setup + recurrente · menú fijo de módulos · foco brutal.
Vender "lo que quieras" · reconstruir por cliente · un código por cliente · escalar sin soporte · dos verticales a la vez · dejar que distraiga al agency.
Tenemos un activo raro (un SO de negocio ya probado) y una ventaja injusta (lo vivimos). Convertámoslo en un producto para un nicho, no en una fábrica de software para cualquiera. Empecemos con 2 pilotos: si se siente como producto, aceleramos; si se siente como consultoría infinita, rediseñamos antes de seguir.