--- title: "Pasamos siete meses escribiendo nuestro propio Intercom. Levantad la mano los que lo habéis hecho" url: "https://www.mikefluff.com/es/blog/build-vs-saas-7-questions" locale: "es" author: "Mike Fluff" updated: "2026-02-09" description: "Un equipo de producto pasó siete meses construyendo su propio Intercom. Las siete preguntas que hago ahora antes de que alguien escriba lo que podría comprar." tags: - "strategy" - "tech" - "ops" alternates: - locale: "en" url: "https://www.mikefluff.com/en/blog/build-vs-saas-7-questions" markdown: "https://www.mikefluff.com/en/blog/build-vs-saas-7-questions.md" - locale: "ru" url: "https://www.mikefluff.com/ru/blog/build-vs-saas-7-questions" markdown: "https://www.mikefluff.com/ru/blog/build-vs-saas-7-questions.md" - locale: "pt" url: "https://www.mikefluff.com/pt/blog/build-vs-saas-7-questions" markdown: "https://www.mikefluff.com/pt/blog/build-vs-saas-7-questions.md" - locale: "es" url: "https://www.mikefluff.com/es/blog/build-vs-saas-7-questions" markdown: "https://www.mikefluff.com/es/blog/build-vs-saas-7-questions.md" --- # Pasamos siete meses escribiendo nuestro propio Intercom. Levantad la mano los que lo habéis hecho > **En resumen:** Un equipo de quince personas gastó siete meses y unos 4,5 millones de rublos en salarios en su propio chat de soporte y acabó comprando Intercom, que costaba unos 700 000 rublos al año. Lo core se construye y lo no-core se compra. Después miro el coste frente al salario, la API, la vida del vendor, la jurisdicción de los datos, la customización y la opción de montar con bloques. 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*. > **Estimación rápida** > > SaaS a $500/mes = $6k/año. Dev mid-senior en ES/LatAm — $40–60k/año. Para > que el build compense, la tarea no puede ocupar más del **10% del tiempo > del dev durante 5 años**. Es raro. **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.** --- > **Cómo decido en 15 minutos** > > 1. **¿Es core?** Sí → build (o bloques). No → siguiente. > 2. **¿Existe un SaaS que cubra el 80%?** Sí → siguiente. No → build. > 3. **¿Tiene API? ¿El vendor está vivo? ¿Datos en la jurisdicción correcta?** > Tres "sí" → SaaS. Cualquier "no" → build. > 4. **¿Proceso muy custom?** Sí → build o bloques. No → SaaS. --- 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. **[Hablar sobre la decisión arquitectónica](https://www.mikefluff.com/es#contact)** — Si build vs SaaS lleva tres meses dando vueltas en tu equipo — ven, lo cerramos con argumentos. He visto ambos escenarios, incluido el cierre de un build fallido en fase avanzada.