Que puedas construirlo no significa que debas construirlo

La puerta de Buy cuesta dinero. La del Build cuesta tiempo…y luego también dinero.

Estoy de vacaciones de LinkedIn, pero no de X. Y claro, en X no descansas: scrolleas sin filtro y te encuentras cosas que te hacen abrir las notas del móvil a las once de la noche.

Estos días me han saltado dos posts que tocaban el mismo tema desde ángulos opuestos. El primero, un periodista orgulloso de haberse programado con Claude Code tres herramientas internas para su empresa de tres personas: facturación, fichaje de empleados y consolidación contable. Todo con IA, todo en unos días. Y la gente aplaudiendo. “El futuro del software”, decían. El segundo, un Head of Development que se había montado su propio sistema de error tracking tipo Sentry, desde cero, también con IA.

Los dos construyeron. Los dos están contentos. Pero uno ha tomado una decisión probablemente cara, y el otro probablemente buena. Y la diferencia no está en la IA. Está en lo que construyeron, en quiénes son, y en por qué lo hicieron.

Lo primero que pensé con el caso del periodista fue: ¿cuántas personas tiene esa empresa? Porque si son tres, acaba de reinventar lo que Holded te da por 15€/mes o Factorial por 5,50€/mes por persona. Es decir, por entre 15 y 16,50€ al mes tenía facturación con Verifactu incluido, fichaje, contabilidad, y soporte de un equipo entero detrás.

Y esto me lleva a algo que llevo tiempo dándole vueltas: con la IA generativa, el coste de construir se ha desplomado. Pero el coste de mantener sigue exactamente donde estaba. Y confundir esas dos cosas es una de las trampas más caras que puedes cometer.

El problema: la ilusión del coste cero

Cuando alguien dice “me lo he construido yo”, mentalmente asigna coste cero al desarrollo. “Ya cobro mi sueldo”, piensa. O peor: “lo hice el finde, así que no costó nada”. Y con herramientas como Cursor, Copilot o Claude Code, es verdad que puedes tener un MVP funcional en horas.

Pero el software no es un mueble de IKEA. No lo montas una vez y ya está. El software es un ser vivo que necesita alimentación constante: actualizaciones de dependencias, cambios regulatorios (pregúntale al de la facturación cómo lleva lo de Verifactu), bugs que aparecen a las 3 de la mañana, onboarding de usuarios nuevos, backups, monitoring…

Desde mi experiencia hay cuatro capas que tienes que revisar antes de decidir si construyes o compras. Y la trampa es que la mayoría de la gente solo mira la primera.

Las cuatro capas del Build vs Buy

1. Coste total de propiedad (TCO real, no simplificado)

Aquí es donde se engaña todo el mundo. Déjame ponerte un ejemplo numérico sencillo, porque es donde se entiende todo.

Caso A: las tres apps caseras vs Holded

Y aquí viene el detalle que cambia todo: quien ha construido estas tres apps no es un developer senior. Es un periodista. Alguien sin background técnico que, con Claude o Cursor, ha sido capaz de montar facturación, fichaje y consolidación contable. Que la IA permita esto es impresionante. Pero que puedas no significa que debas.

¿Cuántas horas le ha costado? Seamos realistas. Un perfil no técnico usando IA para construir tres aplicaciones con lógica de negocio real (cumplimiento fiscal, cálculos de nómina, consolidación de asientos contables) no lo saca en un finde. Estamos hablando de unas 40-60 horas entre las tres apps: entender el dominio, prompt engineering, probar, corregir, desplegar. Usemos 50 horas como estimación razonable.

El coste/hora de un periodista ronda los 25€/hora. Esas 50 horas son 1.250€ solo en desarrollo inicial. “Pero si lo hizo en su tiempo libre”. Da igual. Ese tiempo tiene un valor, aunque no lo factures. Podrías haber estado escribiendo artículos, buscando clientes o descansando. El coste de oportunidad existe aunque decidas ignorarlo.

Ahora el mantenimiento. Y aquí es donde la cosa se pone fea para un perfil no técnico. Cuando algo se rompe (y se rompe, siempre se rompe), no tienes la intuición de un developer para diagnosticar rápido. Cada bug es una sesión nueva con la IA, probando cosas, rompiendo otras. Calcula 4-5 horas al mes siendo conservador. Eso son ~112€/mes en coste de oportunidad. Más el hosting, unos 15-20€/mes.

¿Ves la magnitud? El build es casi 16 veces más caro que el SaaS en el primer año. Y la brecha se agranda con el tiempo, no se reduce. Y eso sin contar que Holded te da CRM, gestión de proyectos, inventario y un equipo de soporte incluido en esos 15€.

“Pero yo esas horas al mes las hago igualmente porque estoy ahí”. Sí, pero esas horas podrían estar dedicadas a cosas que generan valor para tu negocio en lugar de a parchear tu sistema de fichaje casero. Y es que hay algo que se pierde en esta conversación: si eres periodista, tu ventaja competitiva es escribir, investigar, comunicar. Cada hora que dedicas a debuggear una app de facturación es una hora que no estás haciendo lo que mejor sabes hacer.

2. Impacto en negocio (ROI / value creation)

¿Qué pasa cuando tu herramienta casera de facturación no cumple con un cambio regulatorio y Hacienda te pide explicaciones? ¿Cuánto vale esa tranquilidad? ¿Cuánto vale que el equipo de Holded o Factorial tenga 50 ingenieros dedicados a que tu facturación cumpla con Verifactu, con el SII, con cada cambio del BOE?

Para una empresa de 3 personas, el impacto de un fallo en facturación no es solo técnico. Es fiscal, es legal, es reputacional con tus clientes. El SaaS te compra un seguro implícito: hay alguien más responsable de que las cosas funcionen.

3. Riesgo (incertidumbre, dependencia, ejecución)

Aquí hay una asimetría interesante. Cuando compras SaaS, el riesgo que todo el mundo menciona es el vendor lock-in y la dependencia. “¿Y si suben los precios? ¿Y si cierran?”

Es un riesgo real. Pero cuando construyes, los riesgos son más insidiosos porque nadie los enumera:

• Bus factor de 1: si la persona que construyó todo (un periodista, recuerda) se va o simplemente se cansa, ¿quién mantiene las tres apps?
• Deuda técnica invisible: código generado con IA por alguien que no puede evaluarlo a fondo
• Riesgo regulatorio: ¿quién se encarga de que tu facturación casera cumpla con el próximo cambio del reglamento de facturación?
• Coste de switching diferido: cuanto más datos metes en tu sistema casero, más difícil es migrar después

Con el SaaS, si Holded sube precios o cierra, migras a Factorial, a Quipu, a lo que sea. Los formatos son estándar. Con tu herramienta casera, la migración es un proyecto en sí mismo.

4. Opcionalidad (flexibilidad futura)

Esta es la capa que menos gente evalúa y probablemente la más importante. La pregunta no es solo “¿me sale a cuenta hoy?”, sino “¿qué opciones me abre o me cierra cada decisión?”

El SaaS te da opcionalidad barata: puedes probar, escalar, cambiar de proveedor. Si mañana pasas de 3 a 15 personas, tu Holded escala contigo. Tu app casera probablemente no.

El build casero te da opcionalidad cara: tienes control total, pero cada pivote requiere más desarrollo. Es como ser dueño de tu casa vs alquilar. Ser dueño te da control, pero también te ata.

Entonces, ¿cuándo SÍ tiene sentido construir?

Ahora viene lo interesante. Porque no todo es “compra SaaS y punto”. Hay un caso donde la ecuación se invierte completamente.

Caso B: el Sentry casero

Vamos con el segundo post de X, el del head of development que se montó su propio sistema de error tracking. “Otro loco”, pensarás. Pues no tan rápido.

Aquí el perfil es completamente distinto: un head of development. Alguien que cobra 60€/hora y que sabe exactamente lo que está construyendo. Para este perfil, montar un sistema de error tracking con IA (captura de eventos, almacenamiento, búsqueda, alerting básico) lleva unas 15-20 horas. Sabe qué preguntar, entiende la arquitectura, y el dominio es técnicamente limpio. Usemos 18 horas.

El plan Team de Sentry cuesta 26$/mes. Una instancia t3.small en AWS, donde ejecuta su alternativa, cuesta ~15€/mes. Es decir, el coste de hosting es menor que la suscripción SaaS.

Ahora, el mantenimiento aquí es radicalmente distinto al caso del periodista. Un head of dev diagnostica y resuelve rápido. Estamos hablando de 1 hora al mes como mucho, probablemente menos. El sistema es estable porque el dominio es estable.

“Espera, Rubén, aquí el build también es más caro”. Sí, en puro TCO, sigue siendo más caro. Pero la diferencia es mucho menor (7x vs 16x del caso anterior), y sobre todo: aquí hay un retorno que no aparece en la tabla.

Pero la clave no está solo en los números. La clave está en que:

1. El problema es técnicamente acotado: error tracking es capturar eventos, almacenarlos y buscarlos. No hay regulación cambiante, no hay Verifactu de los errores.
2. El developer lo necesita para aprender: construir un sistema de observabilidad te enseña sobre ingest pipelines, indexación, alerting… conocimiento que tiene valor real en el mercado.
3. La escala es contenida: cabe en una t3.small. No va a crecer 10x en 6 meses.
4. El switching cost es bajo: si mañana decides que no merece la pena, migras a Sentry en una tarde.

Aquí la ecuación se invierte no por el TCO (que sigue favoreciendo al SaaS), sino porque el build te da algo que el SaaS no puede: conocimiento profundo del dominio. Este head of dev ahora entiende ingest pipelines, indexación y alerting de una forma que ningún tutorial le habría dado. Y ese conocimiento tiene un valor de mercado real.

¿Ves la diferencia entre los dos casos? El periodista construye algo que no necesita entender, en un dominio regulado, y paga 16x el coste del SaaS. El head of dev construye algo que le hace mejor profesional, en un dominio estable, y paga 7x. Si le pones valor al aprendizaje, el caso B puede salir a cuenta. El caso A, nunca.

La regla que uso yo

Después de darle muchas vueltas, esto es lo que aplico:

Construye cuando se cumplen las cuatro:

• El coste de hosting/infra es comparable o menor al SaaS
• El dominio es técnicamente estable (sin regulación cambiante)
• Hay un retorno claro en aprendizaje o diferenciación 👈🏻
• El switching cost de volver al SaaS es bajo

Compra cuando se cumple cualquiera de estas:

• El dominio tiene complejidad regulatoria o legal (facturación, contabilidad, nóminas, compliance)
• El mantenimiento requiere conocimiento especializado que no es tu core
• Tu equipo es pequeño y el bus factor es un riesgo real
• El coste de oportunidad de tu tiempo supera ampliamente el coste del SaaS

Y es que… el hecho de que la IA haya reducido el coste de construir un MVP a casi cero no cambia la ecuación del mantenimiento. Es más, la empeora. Porque ahora es más fácil que nunca crear software que luego nadie quiere mantener.

La quinta capa: sé honesto contigo mismo

Hay una pregunta que debería ir antes de las cuatro capas, pero que nadie hace: ¿por qué quiero construirlo?

Si la respuesta honesta es “porque quiero aprender”, perfecto. Hazlo. Aprende. Pero llámalo por su nombre: es formación, no una decisión de negocio. Y no le pongas la etiqueta de “ahorro” a lo que en realidad es curiosidad disfrazada de pragmatismo.

No hay nada malo en construir por aprender. Lo malo es engañarte pensando que estás optimizando costes cuando en realidad estás satisfaciendo tu curiosidad técnica. Porque cuando esas dos motivaciones se mezclan sin admitirlo, acabas con tres apps internas que nadie más puede mantener y un Excel de costes que no cuadra.

Que puedas construirlo no significa que debas construirlo. A menos que lo que quieras sea aprender. Y en ese caso, constrúyelo. Pero con los ojos bien abiertos.