Un cliente me llamó en 2021 -- pánico de verdad en su 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 directamente. Gratis.Invoice Ninja existed, was open-source, and did 90% of what he needed out of the box. For free.
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.Buy SaaS until the subscription tax, data ownership, or workflow mismatch genuinely bites; build custom when the tool is core to how the business wins.
Esa llamada me persigue un poco. Porque la respuesta honesta es: he cometido el error opuesto también. Seahawk tuvo un proyecto en 2019 donde pasamos ocho meses cosiendo cinco herramientas SaaS diferentes -- Airtable, Zapier, Typeform, HubSpot, y un CMS Webflow personalizado -- para manejar un flujo de trabajo de cliente que, en retrospectiva, 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 durante tres años.
Ninguno de los extremos es automáticamente correcto. Y cualquiera que te venda una regla limpia -- "siempre construye", "nunca construyas" -- está vendiendo algo. Así que aquí está el marco real 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 dices "¿debería construir o comprar?", lo que realmente estás preguntando es: ¿dónde vive la diferenciación en mi producto? Si la cosa que estás considerando construir es central para 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 de commodities, comprar es casi seguramente más barato en términos reales.reason customers will choose you over the next tab in their browser -- then building probably makes sense. If it's infrastructure, admin, or commodity functionality, buying is almost certainly cheaper in real terms.
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.Will your users ever see this thing?If the answer is yes and it shapes their experience in a meaningful way, it might be worth building. If it's back-office, operational, or internal, the bar for building should be very high.
---
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.Not a one-off. You're on the hook forever unless you sunset the thing.
- 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.A SaaS vendor handles this for you. You build it, you own it, including the 2am alerts.
- 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.If your lead engineer leaves, the next person needs to learn your codebase. That's weeks of billable time.
- Aumento de alcance. Los interesados ven una herramienta personalizada y asumen que puede hacer todo. El alcance se expande. Los costos siguen.Stakeholders see a custom tool and assume it can do everything. Scope expands. Costs follow.
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 se salen del presupuesto a una tasa alarmante. El número ronda el 45-50% de los proyectos siendo "retados" o fracasando directamente. Eso no es una razón para nunca construir -- es una razón para entrar con los ojos abiertos.Standish Group's CHAOS Report has been showing for decades that software projects overrun their budgets at an alarming rate. The number sits around 45-50% of projects being "challenged" or outright failing. That's not a reason to never build -- it's a reason to go in clear-eyed.
---
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 costumbre divertida de convertirse en £490/mes hacia 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" (lee: aumento). He visto esto suceder a clientes en Salesforce, Intercom, y Mixpanel. No es malicioso. Es simplemente cómo funciona la economía de 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.Your data is in their format, their schema, their export flow. Leaving is painful and sometimes effectively impossible without significant data engineering work.
- 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.Five tools that sort-of integrate via Zapier is not a system. It's a liability. One API deprecation and things start falling apart.
- 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.Nobody audits their tool stack annually. They should. I ran an audit for a 12-person agency last year and found £3,200/month in SaaS they'd either stopped using or were using for one feature each.
Dicho esto -- para funciones de commodities, SaaS es casi siempre la llamada correcta. ¿Entrega de correo? Postmark o SendGrid. ¿Pagos? Stripe, obviamente. ¿Autenticación? Auth0 o Clerk. Nadie debería estar construyendo su propio procesador de pagos en 2024.Postmark or SendGrid. Payments? Stripe, obviously. Auth? Auth0 or Clerk. Nobody should be building their own payment processor in 2024.
---
Un Marco que Realmente Funciona
Bien. Así es como lo pienso. Cuatro preguntas, en orden.
Pregunta 1: ¿Es esto un diferenciador competitivo?
Si la respuesta es sí -- si esta es la cosa que hace tu producto genuinamente diferente -- la construcción vale la pena consideración seria. Si es 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."
Dedico al menos dos horas investigando el mercado de SaaS antes de recomendar una construcción personalizada. Product Hunt y G2 son genuinamente útiles aquí -- no como evangelio sino como un inventario inicial.Product Hunt and G2 are genuinely useful here -- not as gospel but as a starting inventory.
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 white-labelled (usaron Route4Me como punto de partida). Seis meses después, sabían exactamente cuáles eran las tres funciones que sus clientes realmente cuidaban. El desarrollo personalizado que eventualmente encargaron fue la mitad del alcance — y el doble de bueno — porque habían aprendido en producción en lugar de en un documento de especificaciones.Route4Me as a starting point). Six months later, they knew exactly which three features their customers actually cared about. The custom build they eventually commissioned was half the scope -- and twice as good -- because they'd learned in production rather than in a spec document.
Pregunta 4: ¿Qué sucede cuando esto se rompe?
Porque se va a romper. La pregunta es quién lo arregla 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 desarrollo. Si no tienes un equipo de desarrollo 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.If you're selling a SaaS product, you can't outsource the thing you're selling.
- 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.Certain fintech, healthcare, and legal applications have compliance constraints that most SaaS tools aren't built to satisfy.
- 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.This is the best possible position to be in before commissioning a custom build.
- 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.Do the maths at your projected Year 3 usage. Sometimes custom wins on pure economics.
---
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 commodity — email, pagos, autenticación, almacenamiento, análisis.
- 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.to avoid making a harder business decision, that's worth examining. Custom builds can be a very expensive form of procrastination.
---
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 las piezas de commodity agresivamente, y construye la capa delgada de lógica diferenciada encima. Tu CRM es HubSpot. Tu escritorio 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 consejo aburrido. También es el consejo que ha funcionado más a menudo.WordPress -- a bought platform -- with custom plugins that do genuinely novel things. The platform handles the 80%. We build the 20% that matters. It's boring advice. It's also the advice that's worked most often.
---
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 es. Comienza pasando una tarde seria — me refiero a cuatro o cinco horas, no veinte minutos — mapeando cada producto SaaS en tu categoría. Si has hecho eso y nada cubre tu requisito principal, pregúntate si ese requisito es realmente necesario ahora o si es un nice-to-have que has elevado a un bloqueador. Si es verdaderamente necesario y verdaderamente sin servir, esa es una señal que vale la pena tomar en serio.necessary right now or whether it's a nice-to-have you've elevated into a blocker. If it's truly necessary and truly unserved, that's a signal worth taking seriously.
¿Cuál es el equipo mínimo que necesitas para ser responsable dueño del software personalizado?
Como mínimo: un desarrollador que entienda profundamente la base de código, 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 oferta de trabajo mejor.
¿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 está subutilizado. Herramientas como Metabase para análisis, Directus para CMS sin cabeza, o ERPNext para operaciones te dan la flexibilidad del software personalizado con un costo inicial de construcción significativamente menor. La trampa: aún estás poseyendo infraestructura y aún necesitas a alguien técnico para administrarla. No es gratis — solo es más barato para comenzar.Metabase for analytics, Directus for headless CMS, or ERPNext for operations give you the flexibility of custom software with significantly lower initial build cost. The catch: you're still owning infrastructure and you still need someone technical to manage it. It's not free -- it's just cheaper to start.
---
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.your answer, specific to your stage, your team, your competitive position, and what you've actually validated so far.
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 de SaaS bien configurado. El fundador de facturación que mencioné al inicio? Eventualmente construyó algo genuinamente personalizado — pero solo después de dieciocho meses usando Invoice Ninja que le enseñó exactamente qué era lo que sus clientes realmente necesitaban. El desarrollo fue mejor por la espera.
Comienza con la opción aburrida. Gánate el derecho de construir algo nuevo.