Pasamos siete meses escribiendo nuestro propio Intercom. Levantad la mano los que lo habéis hecho
Sobre una de esas historias — y sobre cómo hablo ahora con mis clientes cuando empiezan a explicarme por qué en su caso 'escribir es mejor que comprar'.
En 2022 tenía un cliente — un equipo de producto, unas quince personas, haciendo SaaS para RRHH. Negocio normal, ingresos normales, equipo normal. Y tenían un proyecto: escribir su propio chat de soporte.
Me enteré en la segunda semana del contrato. El CTO me enseñó con orgullo un Kanban donde entre otras tareas colgaba un épico. El épico se llamaba "Customer Chat Platform". Tenía veintitrés tickets, cuatro cerrados, diecinueve en marcha en distintos grados de "empezado".
— Vale, — dije. — ¿Por qué?
— Bueno, — dijo el CTO. — No queremos depender de Intercom. Es caro, tiene límites de customización, hay vendor lock-in.
— ¿Cuánto os va a llevar?
— Un par de meses. Luego iteramos.
El proyecto duró siete meses. En ese tiempo se escribió aproximadamente el 60% de la funcionalidad del Intercom de 2019. Por subestimación (siempre) y otras prioridades (siempre), el proyecto iba arrancando y parando. En cierto momento apareció un bug en el que los mensajes se perdían — sólo en Safari móvil de iOS 15.3.1 y sólo cuando el mensaje superaba 400 caracteres. Ese bug llevó dos semanas arreglarlo.
Mes siete — compraron Intercom. El CFO se sentó con el CTO, hicieron la cuenta: en tiempo de desarrollo el equipo había gastado unos 4,5 millones de rublos en salario (sin contar café). Intercom les costaba al año unos 700 000 rublos. En siete meses — 410 000.
Diferencia — 4,1 millones. Con eso se contratan dos senior fuertes. Que, por cierto, no contrataron "porque no hay presupuesto".
No cuento esto para atacar al CTO. El CTO era normal. Quería hacer bien. Simplemente cayó en la trampa clásica — confusión entre core y no-core.
Core es aquello por lo que tu cliente te paga. Aquello en lo que eres diferente a la competencia. Para este cliente — core era analítica de RRHH. No chat. El chat era no-core.
Core nunca es SaaS. Si compras una "plataforma LMS" y montas una escuela online encima — no eres usuario de la plataforma, eres su competidor. Al año topas su techo.
No-core siempre es SaaS. Si escribes tu propio Stripe, tu propio Slack, tu propio Intercom — te metes en deuda. Porque Stripe gasta en ingeniería en un año más que tu presupuesto entero al año. Y aun así encuentran bugs que tú no tendrás tiempo de encontrar.
Esa es la pregunta que hay que responder antes de cualquier debate "build vs buy". Si "core" — deja de leer, construye (o monta con bloques). Si "no-core" — sigue leyendo, pero con sesgo a favor del SaaS.
Luego aplico otras seis preguntas, porque no todo no-core merece comprarse, y no todo core merece escribirse desde cero.
Pregunta dos — coste de una "hora de duda del usuario".
El SaaS funciona hoy. Menos la suscripción. El build funciona en N semanas, menos el salario del equipo durante N semanas.
Fórmula simple: si SaaS_anual < 2 × salario_anual_del_dev y la funcionalidad cubre el 80% — gana el SaaS.
Pregunta tres — ¿el SaaS tiene la API que necesitas?
Comprar Shopify — vale. Pero si el almacén está en un sistema, el TPV en otro SaaS, el repartidor en un stack propio — tu trabajo es coserlo todo por API. Comprueba la API antes de comprar. Si el endpoint que necesitas no está, pagarás el SaaS y el build de un proxy entre él y todo lo demás. Lo peor de todos los mundos.
Pregunta cuatro — ¿sobrevive el vendor más que tú?
SaaS startup de diez personas prometiendo resolverlo todo — riesgo. Si mueren en dos años, pierdes datos, lógica, proceso.
Comprobación: ¿la empresa tiene más de 5 años? ¿Series B+? ¿Hay documentación de migración al competidor? Si no — es SaaS de vida corta, y la migración va a doler.
Pregunta cinco — datos.
En sectores regulados (fintech, salud, sector público) esta suele ser la única pregunta decisiva. Si el SaaS no está en la jurisdicción correcta — build. Fin.
En no regulados — piénsalo también. Si analítica crítica vive en un SaaS y no hay export, eres rehén del vendor. Una subida del 40% en precio no se negocia.
Pregunta seis — qué tan custom es tu proceso.
SaaS es bueno cuando tu proceso encaja en el 80% de lo que el producto soporta. Cuanto más lejos de la media, más customizaciones, plugins, workarounds. En algún momento gastas en customizar el SaaS más de lo que el build habría costado.
Regla: tres customizaciones — normal, cinco — bandera roja, diez — toca migrar.
Pregunta siete — quizá no hay que elegir.
2026 cambia las reglas. Antes era "escribir desde cero o comprar hecho". Ahora hay una tercera opción: montar con bloques de bajo nivel.
— Backend API — Hono / FastAPI en 30 líneas.
— BBDD — PostgreSQL en cualquier proveedor.
— Auth — Clerk / Supabase en una hora.
— Queue — Temporal / Inngest.
— LLM — OpenAI / Anthropic API.
Lo que hace tres años era seis meses de dev hoy sale en tres semanas. Tu build deja de oponerse al SaaS — está hecho de trozos de SaaS. 20% custom + 80% prestado. El default ahora.
Volviendo a ese CTO. Un año después de la historia del chat nos cruzamos en una conferencia. Le pregunté qué estaban haciendo ahora. Respondió que habían devuelto todo el trabajo no-core a SaaS (Intercom, HubSpot, ClickUp) y habían enfocado al equipo en una sola cosa — analítica de RRHH. Ingresos +60% interanual.
"Yo," dijo, "pasé aquel año aprendiendo una lección: el trabajo de ingeniería no siempre es escribir código. A veces es decidir no escribirlo."
No hay respuesta universal. Hay siete preguntas que en quince minutos convierten una discusión filosófica en decisión con argumentos.
La próxima vez que oigas "lo escribimos nosotros / lo compramos" — abre este checklist. Te ahorrará semanas y decenas de miles.