Un cliente me llamó en 2021, con pánico genuino en la voz. Había gastado £140.000 en catorce meses construyendo una plataforma de facturación personalizada. Su equipo de desarrollo había entregado quizás el 60% de la especificación. Y alrededor del mes once, descubrió que Invoice Ninja existía, era de código abierto, y hacía el 90% de lo que necesitaba desde el primer momento. Gratis.
Lo importante: Compra SaaS hasta que los impuestos de suscripción, la propiedad de datos o el desajuste de flujos de trabajo te causen problemas reales; construye soluciones personalizadas cuando la herramienta es central para cómo tu negocio gana.
Esa llamada me sigue un poco. Porque la respuesta honesta es: he cometido el error opuesto también. Seahawk tuvo un proyecto en 2019 donde pasamos ocho meses ensamblando cinco herramientas SaaS diferentes, Airtable, Zapier, Typeform, HubSpot, y un CMS Webflow personalizado, para gestionar un flujo de trabajo de cliente que, mirando atrás, una construcción personalizada de £15.000 habría resuelto limpia y permanentemente. Estábamos pagando aproximadamente £900/mes en suscripciones combinadas al final. Haz las cuentas en tres años.
Ninguno de los extremos es automáticamente correcto. Y cualquiera que te venda una regla limpia, "siempre construye", "nunca construyas", te está vendiendo algo. Así que aquí está el marco actual que uso cuando un fundador se sienta conmigo y me hace la pregunta.
---
Primero, Admite Lo Que Realmente Estás Decidiendo
Esta no es una decisión técnica. En realidad, no lo es. Es una decisión comercial disfrazada de ropa técnica.
Cuando preguntas "¿debería construir o comprar?", lo que realmente estás preguntando es: ¿dónde vive la diferenciación en mi producto? Si lo que estás considerando construir es central a tu ventaja competitiva, la razón por la que los clientes te elegirán sobre la siguiente pestaña en su navegador, entonces construir probablemente tiene sentido. Si es infraestructura, administración, o funcionalidad estándar, comprar es casi seguramente más barato en términos reales.
Hago a los fundadores una pregunta primero: ¿Verán tus usuarios esto? Si la respuesta es sí y moldea su experiencia de una manera significativa, podría valer la pena construir. Si es back-office, operacional, o interno, el estándar para construir debería ser muy alto.
---
El Costo Real de Construir (La Gente Subestima Esto Terriblemente)
Seré directo. El desarrollo personalizado cuesta más de lo que crees, toma más tiempo del que te dicen, y requiere mantenimiento continuo que nadie presupuesta.
Lo que los fundadores realmente olvidan contar en el precio
- Mantenimiento y alojamiento. No es un gasto único. Estás comprometido para siempre a menos que discontinúes la herramienta.
- Parches de seguridad. Un proveedor SaaS se encarga de esto por ti. Tú lo construyes, tú lo posees, incluyendo las alertas de las 2 de la mañana.
- Incorporación de nuevos desarrolladores. Si tu ingeniero líder se va, la próxima persona necesita aprender tu base de código. Son semanas de tiempo facturable.
- Aumento de alcance. Los interesados ven una herramienta personalizada y asumen que puede hacer todo. El alcance se expande. Los costos siguen.
Una regla aproximada que uso: toma tu estimación inicial de desarrollo, multiplícala por 1.6 para una entrega realista, luego suma el 20% de ese número anualmente para mantenimiento. Si esos números siguen justificando el caso de negocio, excelente. Si no, tienes tu respuesta.
Honestamente, el CHAOS Report del Standish Group ha estado mostrando durante décadas que los proyectos de software superan sus presupuestos a una tasa alarmante. El número se sitúa alrededor del 45-50% de los proyectos siendo "desafiantes" o directamente fallidos. Eso no es una razón para nunca construir, es una razón para entrar con los ojos abiertos.
---
El Costo Real de SaaS (También Subestimado, Solo que de Otra Manera)
SaaS parece barato hasta que deja de serlo.
El plan de £49/mes que parecía razonable al inicio del año tiene la curiosa costumbre de convertirse en £490/mes para el año tres, una vez que estás en un nivel superior, has añadido asientos, y el proveedor ha hecho una "reestructuración de precios" (léase: aumento). He visto esto ocurrir a clientes en Salesforce, Intercom, y Mixpanel. No es malicioso. Es solo cómo funcionan la economía del SaaS.
Las tres trampas de SaaS en las que caen los fundadores
- Dependencia del proveedor. Tus datos están en su formato, su esquema, su flujo de exportación. Irte es doloroso y a veces efectivamente imposible sin trabajo significativo de ingeniería de datos.
- Complejidad de pila Frankenstein. Cinco herramientas que más o menos se integran vía Zapier no es un sistema. Es un pasivo. Una deprecación de API y las cosas comienzan a desmoronarse.
- Aumento de suscripciones. Nadie audita su pila de herramientas anualmente. Deberían. Realicé una auditoría para una agencia de 12 personas el año pasado y encontré £3,200/mes en SaaS que habían dejado de usar o estaban usando por una sola característica cada una.
Dicho esto, para funciones estándar, SaaS es casi siempre la opción correcta. ¿Envío de email? Postmark o SendGrid. ¿Pagos? Stripe, obviamente. ¿Autenticación? Auth0 o Clerk. Nadie debería estar construyendo su propio procesador de pagos en 2024.
---
Un Marco que Realmente Funciona
Bien. Así es como lo pienso. Cuatro preguntas, en orden.
Pregunta 1: ¿Es esto un diferenciador competitivo?
Si sí, si esto es lo que hace que tu producto sea genuinamente diferente, construir merece consideración seria. Si no, detente aquí. Compra.
Pregunta 2: ¿Existe una alternativa SaaS lo suficientemente buena?
Lo suficientemente buena, no perfecta. Los founders rutinariamente construyen porque "no hay nada por ahí que haga exactamente lo que necesitamos." A veces es verdad. A menudo significa que no han buscado lo suficientemente bien, o están confundiendo "necesitamos configurar esto bien" con "necesitamos construir algo nuevo."
Paso al menos dos horas investigando el mercado SaaS antes de recomendar una construcción personalizada. Product Hunt y G2 son genuinamente útiles aquí, no como verdad absoluta sino como un inventario inicial.
Pregunta 3: ¿Cuál es tu tiempo realista para obtener valor?
Una herramienta SaaS puede estar en vivo hoy. Un desarrollo personalizado toma semanas como mínimo, generalmente meses. Si la velocidad importa, y en empresas en etapa temprana casi siempre importa, comprar te compra tiempo para aprender qué realmente necesitas antes de comprometerte a construirlo.
Allá por 2022, Seahawk trabajó con una startup de logística que quería un dashboard personalizado de optimización de rutas. Los convencimos de usar primero una capa de API de marca blanca (usaron Route4Me como punto de partida). Seis meses después, sabían exactamente cuáles eran las tres funcionalidades que sus clientes realmente valoraban. El desarrollo personalizado que eventualmente contrataron tenía la mitad del alcance, y era el doble de bueno, porque habían aprendido en producción en lugar de en un documento de especificaciones.
Pregunta 4: ¿Qué sucede cuando esto se rompe?
Porque se va a romper. La pregunta es quién lo repara y qué tan rápido. Con SaaS, abres un ticket de soporte y te quejas en Twitter. Con software personalizado, llamas a tu equipo de desarrolladores. Si no tienes un equipo de desarrolladores retenido, estás en problemas. No es hipotético, he visto a fundadores atrapados con software personalizado roto durante semanas porque su desarrollador freelance se fue de vacaciones.
---
Cuándo Construir Es Claramente la Opción Correcta
Hay situaciones donde lo personalizado es obviamente correcto. Déjame nombrarlas claramente.
- Tu IP principal es el software en sí. Si estás vendiendo un producto SaaS, no puedes externalizar la cosa que estás vendiendo.
- Los requisitos regulatorios significan que lo listo para usar no será suficiente. Ciertas aplicaciones de fintech, salud y legales tienen restricciones de cumplimiento que la mayoría de herramientas SaaS no están construidas para satisfacer.
- Ya has validado con una herramienta SaaS y sabes exactamente qué necesitas. Esta es la mejor posición posible antes de encargar una construcción personalizada.
- El precio de SaaS a escala es genuinamente más costoso que la propiedad. Haz las cuentas en tu uso proyectado del Año 3. A veces la construcción personalizada gana en pura economía.
---
Cuándo Comprar Es Claramente la Decisión Correcta
De igual manera, algunas situaciones hacen que comprar sea obvio:
- Estás pre-ingresos o sin product-market fit. Sin discusión.
- La función es infraestructura de commodidad, email, pagos, autenticación, almacenamiento, analítica.
- Lo necesitas funcionando este trimestre, no este año.
- Tu equipo no tiene capacidad de ingeniería interna y no puedes permitirte contratar adecuadamente.
También añadiría: si estás construyendo como founder para evitar tomar una decisión de negocio más difícil, eso vale la pena examinar. Las construcciones personalizadas pueden ser una forma muy costosa de procrastinación.
---
El Enfoque Híbrido (A Menudo la Mejor Decisión)
Aquí está lo que nadie habla lo suficiente: construir y comprar no son mutuamente excluyentes.
El enfoque más pragmático que he visto funcionar repetidamente es este: compra agresivamente las piezas de commodidad, y construye la capa delgada de lógica diferenciada encima. Tu CRM es HubSpot. Tu mesa de soporte es Intercom. Pero el motor de flujo de trabajo personalizado que los conecta y automatiza tu proceso específico, eso son dos semanas de desarrollo personalizado, no seis meses.
En Seahawk, hemos construido cientos de sitios en WordPress, una plataforma comprada, con plugins personalizados que hacen cosas genuinamente novedosas. La plataforma maneja el 80%. Nosotros construimos el 20% que importa. Es un consejo aburrido. También es el consejo que más veces ha funcionado.
---
FAQ
¿Cómo sé si mi caso de uso es realmente único como para justificar una construcción personalizada?
Respuesta honesta: la mayoría no lo son. Comienza pasando una tarde seria, hablo de cuatro o cinco horas, no veinte minutos, mapeando cada producto SaaS en tu categoría. Si hiciste eso y nada cubre tu requisito fundamental, pregúntate si ese requisito es realmente necesario ahora o si es algo que te gustaría tener y que elevaste a bloqueador. Si es verdaderamente necesario y verdaderamente no está cubierto, esa es una señal que vale la pena tomar en serio.
¿Cuál es el equipo mínimo que necesitas para ser responsable dueño del software personalizado?
Como mínimo: un desarrollador que entienda el código base profundamente, y ya sea un segundo desarrollador o una agencia retenida que pueda cubrirlo cuando no esté disponible. Poseer software personalizado con un único freelancer y sin respaldo es una posición frágil. He visto que cause daño operacional real cuando esa persona se vuelve no disponible, vacaciones, enfermedad, una mejor oferta de trabajo.
¿Debo construir internamente o contratar una agencia para construir algo personalizado?
Depende casi enteramente de si el software es tu negocio central. Si eres una empresa de software, casi con seguridad querrás un equipo interno eventualmente, incluso si usas una agencia para comenzar. Si el software es una herramienta que apoya tu negocio en lugar de ser el negocio en sí, una relación con una agencia con un SLA apropiado es generalmente más rentable que contratar ingenieros a tiempo completo.
¿Es el código abierto un camino intermedio entre construir y comprar?
Sí, y se subutiliza. Herramientas como Metabase para analítica, Directus para CMS headless, o ERPNext para operaciones te dan la flexibilidad del software personalizado con un costo inicial de construcción significativamente menor. La trampa: todavía posees infraestructura y aún necesitas a alguien técnico para administrarla. No es gratis, solo es más barato para empezar.
---
Un Pensamiento Final
La pregunta de construir versus comprar no tiene una respuesta. Tiene tu respuesta, específica a tu etapa, tu equipo, tu posición competitiva, y lo que realmente has validado hasta ahora.
Lo que cuestionaría es el romanticismo alrededor de construir. El software personalizado no es inherentemente más serio, más escalable o más impresionante que un stack SaaS bien configurado. El fundador de facturación del que mencioné al inicio, eventualmente construyó algo genuinamente personalizado, pero solo después de dieciocho meses usando Invoice Ninja que le enseñaron exactamente qué necesitaban sus clientes. La construcción fue mejor por la espera.
Comienza con la opción aburrida. Gánate el derecho de construir algo nuevo.
Lecturas relacionadas: Building a Real-Time Auction Site with Next.js & Supabase, desarrollo web personalizado, y Next.js.