Un cliente me llamó en 2021 — pánico real en su voz. Había gastado £140,000 durante 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, había descubierto que Invoice Ninja existía, era de código abierto, e hizo el 90% de lo que necesitaba de la caja. Gratis.Invoice Ninjaexisted, was open-source, and did 90% of what he needed out of the box. For free.
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 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 preguntas es: ¿dónde vive la diferenciación en mi producto? Si lo que estás considerando construir es fundamental para tu ventaja competitiva —la razón por la que los clientes te elegirán sobre la siguiente pestaña en su navegador—, entonces probablemente tenga sentido construirlo. Si es infraestructura, administración o funcionalidad de commodity, comprar es casi con certeza más barato en términos reales.reasoncustomers 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.
Les hago una pregunta a los fundadores primero: ¿Verán tus usuarios esto alguna vez? Si la respuesta es sí y moldea su experiencia de una manera significativa, podría valer la pena construirlo. Si es back-office, operativo o interno, el estándar para construirlo 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 hosting. No es un pago único. Estás comprometido para siempre a menos que discontinúes la cosa.Not a one-off. You're on the hook forever unless you sunset the thing.
- Parches de seguridad. Un proveedor SaaS lo maneja por ti. Tú lo construyes, tú lo posees, incluyendo las alertas a 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 principal se va, la siguiente persona necesita aprender tu codebase. Eso son semanas de tiempo facturable.If your lead engineer leaves, the next person needs to learn your codebase. That's weeks of billable time.
- Creep de funcionalidades. Los stakeholders ven una herramienta personalizada y asumen que puede hacer de 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 superan sus presupuestos a una tasa alarmante. El número ronda el 45-50% de proyectos siendo "desafiantes" o directamente fracasando. Eso no es razón para nunca construir — es razón para entrar con los ojos bien abiertos.Standish Group's CHAOS Reporthas 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 de convertirse en £490/mes hacia el año tres — una vez que estás en un tier superior, has añadido asientos, y el proveedor ha hecho una "reestructuración de precios" (léase: aumento). He visto esto suceder a clientes en Salesforce, Intercom y Mixpanel. No es malicioso. Es solo cómo funcionan la economía de SaaS.
Las tres trampas de SaaS en las que caen los fundadores
- Bloqueo del proveedor. Tus datos están en su formato, su esquema, su flujo de exportación. Irse 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 Franken-stack. Cinco herramientas que se integran medio bien vía Zapier no es un sistema. Es un pasivo. Una deprecación de API y las cosas empiezan 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.
- Creeping de suscripciones. Nadie audita su stack de herramientas anualmente. Deberían hacerlo. Hace un año realicé una auditoría para una agencia de 12 personas y encontré £3,200/mes en SaaS que ya no usaban o que usaban por una sola función.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 genéricas, SaaS casi siempre es la opción correcta. ¿Entrega 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.Postmarkor 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 es así — si esto es lo que hace que tu producto sea genuinamente diferente — construir merece seria consideración. 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 de SaaS antes de recomendar nunca una construcción personalizada. Product Hunt y G2 son genuinamente útiles aquí — no como evangelio sino como inventario inicial.Product Huntand 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. Una construcción personalizada 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.
En 2022, Seahawk trabajó con una startup de logística que quería un panel de control de optimización de rutas personalizado. Los convencimos de usar una capa de API con marca blanca primero (usaron Route4Me como punto de partida). Seis meses después, sabían exactamente cuáles eran las tres funciones que sus clientes realmente valoraban. La construcción personalizada que eventualmente encargaron tenía la mitad del alcance —y era el doble de buena— porque habían aprendido en producción en lugar de en un documento de especificaciones.Route4Meas 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 romperá. La pregunta es quién lo arregla y qué tan rápido. Con SaaS, presents 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 contratado, 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 propiedad intelectual central es el software en sí. Si estás vendiendo un producto SaaS, no puedes externalizar lo que estás vendiendo.If you're selling a SaaS product, you can't outsource the thing you're selling.
- Los requisitos regulatorios hacen que lo estándar no sea suficiente. Ciertas aplicaciones de fintech, salud y legal tienen restricciones de cumplimiento que la mayoría de las 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 un desarrollo personalizado.This is the best possible position to be in before commissioning a custom build.
- El precio de SaaS a escala es genuinamente más caro que la propiedad. Haz las cuentas con tu uso proyectado en el Año 3. A veces el desarrollo personalizado 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 estándar — email, pagos, autenticación, almacenamiento, analytics.
- 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 empresarial más difícil, eso merece examen. Los desarrollos personalizados pueden ser una forma muy costosa de procrastinar.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 agresivamente las piezas básicas, 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 custom, no seis meses.
En Seahawk, hemos construido cientos de sitios en WordPress — una plataforma comprada — con plugins personalizados que hacen cosas genuinamente innovadoras. La plataforma maneja el 80%. Construimos el 20% que importa. Es un consejo aburrido. También es el consejo que ha funcionado más a menudo.
---
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 dedicando 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 central, pregúntate si ese requisito es realmente necesario ahora o si es un agradable tenerlo que has elevado a un bloqueador. Si es verdaderamente necesario y verdaderamente no atendido, esa es una señal que vale la pena tomar en serio.necessary right nowor 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 comprenda profundamente el código base, y un segundo desarrollador o una agencia que pueda cubrirlo cuando no esté disponible. Ser dueño de software personalizado con un solo freelancer y sin respaldo es una posición frágil. He visto causar 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 de construcción inicial significativamente menor. La trampa: aún estás siendo dueño de la infraestructura y aún necesitas a alguien técnico para administrarla. No es gratis — simplemente es más barato para comenzar.Metabasefor 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.youranswer, 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 principio? Eventualmente construyó algo genuinamente personalizado — pero solo después de dieciocho meses de usar Invoice Ninja que le enseñó exactamente lo que sus clientes realmente necesitaban. La construcción fue mejor por la espera.
Comienza con la opción aburrida. Gánate el derecho de construir algo nuevo.