Build vs buy: el framework de decisión para founders no técnicos

Build vs buy rara vez es la pregunta correcta. Aquí tienes un checklist de cuatro preguntas que un founder de etapa temprana puede correr en quince minutos antes de firmar un contrato SaaS, contratar a un dev, o abrir un doc en Notion llamado “spec del MVP.”

El founder en la call conmigo tenía una pregunta limpia y una respuesta confusa. Había levantado una ronda seed ocho meses antes, había cerrado dos pilotos enterprise, y ahora estaba mirando una planilla con once suscripciones SaaS encima. “Creo que tenemos que construir el nuestro propio,” dijo. “O quizás consolidar. No sé cuál de los dos. Honestamente, ni sé cómo decidir.”

Hablamos una hora. En realidad, no había planteado la pregunta correcta. Pensaba que estaba decidiendo entre software a medida y SaaS. El árbol de decisión real era más amplio, sus restricciones más apretadas de lo que él notaba, y la respuesta a “build o buy” dependía casi por completo de tres variables que aún no había nombrado en voz alta. Salió de la call con un checklist de cuatro preguntas. Dos semanas después canceló cuatro de las once herramientas, contrató dos más, y puso exactamente un workflow en la lista de build.

Esa conversación, en alguna forma, ocurre en Pixel Breeders casi todas las semanas. La pregunta de build vs buy es la decisión más común que un founder no técnico nos plantea. También es la que más consistentemente se formula mal.

Este es el framework que usamos.

Qué significa “build vs buy” de verdad

Build vs buy es la decisión entre construir software a medida para un workflow y comprar un producto pronto que resuelve un problema parecido. El planteamiento clásico es binario: escribir el código vos mismo (build), o pagarle a un proveedor por software terminado (buy).

En 2026, el planteamiento ya está mal antes incluso de empezar. Existe una tercera opción que, en silencio, cubre la mayoría de los workflows en empresas de etapa temprana: coser unas cuantas herramientas SaaS con pegamento no-code (Zapier, Make, n8n, Airtable, un Retool por encima). No es build puro ni buy puro. Es la realidad por defecto de casi toda startup pre-Serie A con la que trabajamos, y ignorarla produce malas decisiones.

Entonces la pregunta real es:

• Build: software a medida escrito para tu workflow específico.
• Buy: un producto pronto que se hace cargo del workflow de punta a punta.
• Stitch: ensamblar dos o más productos existentes con pegamento liviano (automatizaciones, formularios internos, un dashboard).

La mayoría de los founders cae en buy por defecto, a veces gasta de más en stitch, y subestima lo poco que build es la respuesta correcta en su etapa. Las cuatro preguntas de abajo están diseñadas para hacer aflorar cuál de las tres realmente encaja.

Las cuatro preguntas

Corré en orden. Cada una es una puerta. Si una pregunta mata la opción de build, parate ahí. No hace falta hacer la siguiente.

1. ¿Este workflow es central para cómo ganamos plata?

La primera puerta es si el workflow es estructural para los ingresos.

Un workflow es central si es alguno de los siguientes:

• Una superficie de producto que tus clientes pagantes tocan directamente.
• Un workflow que tu equipo ejecuta miles de veces por mes y que tiene efecto medible sobre conversión, retención, o unit economics.
• Un workflow regulatorio o de confianza crítica (KYC, custodia, siniestros) donde una caída o limitación del proveedor lastimaría al negocio de forma significativa.

Un workflow no es central si es coordinación interna (gestión de proyecto, agenda, gastos), comunicación temprana con el cliente (CRM, email), o cualquier cosa donde “lo bastante bueno” le gana a “exactamente como yo lo quiero.”

Si el workflow no es central: buy o stitch. No deberías estar construyendo software para problemas que se resuelven adecuadamente con un producto de $40 por usuario que están usando 50.000 empresas más. La ventaja que sacás de una herramienta genérica es real, el tiempo ahorrado es real, y el costo de mantenimiento de una versión a medida se acumula en tu contra por años.

Si el workflow es central, pasá a la pregunta dos.

2. ¿Algún producto de góndola realmente encaja en nuestro workflow?

La mayoría de los founders se saltea este paso o lo hace a medias. Mira dos competidores, encuentra uno que odia, y concluye que “no encaja nada.”

La versión honesta de esta pregunta es: dedicale una tarde de verdad a mapear tu workflow como existe hoy, llevá ese mapa a tres productos reales, y correlo dentro. No la demo. El workflow real, con tus edge cases reales.

Estás buscando el gap entre lo que el producto hace y lo que necesitás. Un gap del 10% es aceptable; vas a aprender a convivir, y el producto probablemente entregue el 10% que falta en dos trimestres. Un gap del 40% es fatal. Vas a pasar el próximo año haciendo trabajo manual alrededor de las limitaciones, entrenando gente en workarounds, y explicándole al equipo por qué “así funciona la herramienta.”

La trampa acá es el gap de la demo. Las demos de ventas están afinadas para que el producto parezca que se la banca en todo caso. No se la banca. El mapa del workflow es la única forma de ver dónde el producto realmente se rompe.

Si un producto encaja con un gap tolerable: buy. Pará el análisis. Seguí. No hay medalla por construir lo que otro ya construyó.

Si ningún producto encaja, pasá a la pregunta tres.

3. ¿Llegamos cosiendo lo que ya existe?

Esta es la pregunta que más cambió desde 2022, porque la superficie del SaaS se duplicó y la capa de integración maduró.

Coser significa: agarrá dos o tres productos donde cada uno cubre una parte de tu workflow, conectalos con automatizaciones, y agregá la capa fina de lógica custom que cierra la última milla. Un workflow stitched típico en etapa temprana se ve así hoy:

• HubSpot es dueño del registro del contacto.
• Un Typeform o un formulario de intake custom empuja nuevos leads a HubSpot.
• Una automatización en n8n o Make rutea los leads de alto valor a un canal de Slack y a un dashboard Retool.
• El dashboard Retool toma el contacto y le muestra al SDR una vista custom, llama un par de APIs internas, y escribe de vuelta un estado.

Eso es software stitched. No es código a medida puro ni producto de góndola puro. Es el patrón caballito-de-batalla del stack moderno de etapa temprana.

Stitch gana cuando:

• El workflow es central, pero las piezas ya existen como productos.
• La capa custom que falta es poco profunda (un formulario, un dashboard, algunas automatizaciones).
• Esperás que el workflow cambie cada trimestre durante el próximo año. Las capas stitched son baratas de tirar. El código a medida no.

Stitch pierde cuando:

• La capa custom creció a media docena de automatizaciones y tres Retools y nadie puede describir cómo funciona.
• Empieza a importar la performance (colas de n8n acumulando, rate limit de Zapier pegando, view de Airtable cargando lento).
• Los propios puntos de integración se convierten en una carga de mantenimiento mayor de lo que costaría ser dueño del código.

Este es el modo de falla que vale la pena nombrar explícitamente: la trampa del stitch. Los sistemas stitched son baratos para empezar y caros para heredar. El founder que lo armó sabe dónde vive cada pieza; el siguiente empleado abre el canvas de Make, ve cuarenta y siete nodos conectando once productos, y renuncia en menos de un mes. Vimos este patrón las veces suficientes como para tratar “tenemos un sistema stitched que nadie más puede leer” como un pasivo activo de contratación.

Si coser funciona los próximos doce meses: stitch, y revisá en ese horizonte.

Si coser ya está rompiendo, o si el sistema llegó al umbral de complejidad, pasá a la pregunta cuatro.

4. ¿El workflow está lo bastante estable como para codificar?

La última puerta es si el workflow dejó de cambiar todas las semanas.

El software a medida es más valioso cuando lo escribís para un workflow que entendés. Si todavía estás iterando sobre cómo es el workflow (qué pasos existen, quién los hace, cuáles son los inputs), construir software para eso es un seguro caro contra tu propia indecisión. Vas a construir la cosa equivocada, tirarla, construir una segunda versión, y descubrir que la tercera versión es la que realmente querías. Eso es un costo real.

La señal de que un workflow está lo bastante estable como para codificar es operativa, no filosófica. Podés describir el workflow a un nuevo ingreso en quince minutos sin decir “bueno, depende.” Las excepciones tienen regla. Los edge cases tienen nombre.

Si el workflow todavía está en flujo: stitch un trimestre más. No construyas todavía.

Si el workflow está estable, las herramientas existentes no encajan, el gap es demasiado ancho para coser, y el workflow es central para los ingresos: build.

Ese es el único camino al “build.” Es más estrecho de lo que la mayoría de los founders imagina.

Cuánto cuesta “build” de verdad a escala startup

La razón por la que esta decisión importa es la diferencia de costo, y los números que la mayoría de los founders se citan a sí mismos están equivocados por un orden de magnitud.

Para una startup en etapa temprana, construir software a medida con un estudio chico o partner (no una agencia offshore genérica, no un equipo in-house que todavía no tenés) típicamente cae así:

• Una herramienta interna chica que reemplaza un workflow stitched: $20K–$60K, cuatro a diez semanas. Pensá en un dashboard custom con algunas escrituras a tu base, una integración externa, y una UI prolija.
• Un v1 de una superficie de producto central que los clientes van a ver: $80K–$250K, tres a seis meses. Frontend de verdad, usuarios autenticados, modelo de datos pensado, un admin interno, pipeline de deploy.
• Un v1 de un workflow regulado (KYC, pagos, siniestros): $150K–$500K, seis a doce meses. Lo mismo de arriba más trail de auditoría, flujos de compliance, y la parte lenta de hacer seguridad bien.

Estos son números de 2026 para un estudio chico partner, trabajando en TypeScript, React, Postgres, deployando a una nube administrada. Los números suben si el equipo es más grande, bajan si el equipo es más afilado. Suben más rápido de lo que los founders esperan cuando el alcance crece sin que nadie lo nombre. Escribimos más sobre cuánto cuesta de verdad desarrollar una app y sobre cómo la estructura del contrato cambia la matemática.

Los mismos números en términos de SaaS: $20K de desarrollo a medida valen aproximadamente dos años de una herramienta de $100 por usuario para un equipo de diez. $250K se acerca a una década de lo mismo. Esa cuenta es lo que debería empujar al buy por defecto.

La versión honesta de “cuánto deberíamos gastar en esto”: si el workflow es central, la matemática cierra, y el gap es real, $80K–$250K por un v1 que es dueño de un workflow que tus competidores no pueden copiar en un trimestre no es caro. Es el resto del espectro el que mete en problemas al founder.

Cuándo gana buy (la respuesta por defecto)

En las conversaciones que tenemos con founders, buy gana ocho de cada diez veces. Las razones son aburridas y correctas.

Las herramientas genéricas están maduras. HubSpot, Notion, Linear, Stripe, Mercury, Ramp, Pylon, Vanta: cada uno tiene un equipo de producto de decenas a cientos de personas, construyendo exactamente la feature que vos estarías construyendo. Embarcan más rápido de lo que vos podés. Su postura de seguridad es mejor que la tuya. Sus integraciones son más profundas. Su precio, incluso en los tiers más altos, suele ser menor que el costo total de un ingeniero por un trimestre.

El error del founder es darle peso excesivo al 10% específico que la herramienta no hace. El 90% que sí hace es la victoria. La mayoría de los workflows que pensás que son únicos no lo son. Podemos decirle a un founder en quince minutos si su workflow “custom” es realmente custom o si es un workflow de góndola que todavía no reconoció. La Aggregation Theory de Ben Thompson es la lectura más limpia de por qué esto es estructural, no accidental.

Si un producto cubre el 70% o más de tu workflow real, buy. Convivís con el gap del 30%. Lo revisás en un año.

Cuándo gana build (las excepciones estructurales)

Build gana en un número chico de casos bien definidos.

El primero es superficie de producto. Si el software en cuestión es lo que tus clientes efectivamente te compran, construirlo no es opcional. Nadie compró una suscripción SaaS a una versión genérica de tu producto, porque no existe. Existís vos. El software a medida es la empresa.

El segundo es workflows operativos que componen ventaja. Algunos workflows no son tu producto pero generan ventaja medible a escala. Un motor de matching a medida para un marketplace. Una automatización de siniestros para una aseguradora. Un sistema de conciliación para una fintech. Son workflows donde un 10% de mejora en throughput se convierte en un cambio relevante de unit economics. Los proveedores de góndola no pueden afinar. Vos sí.

El tercero es profundidad de integración. Si el workflow necesita leer y escribir en cinco sistemas internos con reglas que son únicas de tu negocio, y el producto de góndola igual requeriría un proyecto de integración de seis meses para hacer la mitad de lo que necesitás, el costo de build converge con el costo de buy y la versión build es tuya para evolucionar. Vimos este patrón con más frecuencia en empresas en late-seed y Serie A que ya salieron de un setup stitched.

El cuarto es responsabilidad regulatoria. Cuando vos sos la entidad responsable del trail de auditoría, del cifrado, de la residencia de datos, y del flujo de consentimiento, el costo de estar equivocado sobre la postura de compliance de un proveedor a veces es mayor que el costo de ser dueño del código. Esto es más común en fintech, healthtech, y legaltech de lo que los founders perciben.

Fuera de esos cuatro casos, la respuesta usualmente no es build.

La trampa del stitch, y por qué es el modo de falla de 2026

El debate de build vs buy de 2015 no es el debate de hoy. En 2015 la elección era real: había menos productos SaaS, menos plataformas de integración, y la pregunta de escribir código pesaba. En 2026, casi todos los workflows de etapa temprana se pueden coser a partir de herramientas existentes, y la pregunta cambió.

El nuevo modo de falla es el sistema stitched que nadie puede leer. Un founder compra ocho herramientas, contrata a un ops part-time para conectar todo con Zapier, le pone dos dashboards en Retool encima, y dieciocho meses después descubre que nadie en el equipo entiende cómo funciona el workflow de onboarding del cliente. No hay documentación. El flujograma en su cabeza es el único flujograma. Cuando el ops se va, el sistema se vuelve un single point of failure que nadie se anima a tocar.

Hoy advertimos a los founders activamente contra esto. Tres señales:

• Tu sistema stitched tiene más de diez puntos de integración, y el mapa de dependencias existe solo en la cabeza de alguien.
• Más de un workflow crítico queda en silencio por un día porque una automatización de Make pegó rate limit y nadie notó.
• La contratación demora más porque los nuevos no pueden ser onboardeados en tu stack sin un tour de la persona que armó todo.

Cuando alguna de esas señales está prendida, la respuesta correcta usualmente no es “construir todo.” Es “codificar la columna del workflow y dejar las hojas como SaaS.” Un estudio chico puede hacerlo en una engagement de seis a diez semanas. El resultado es un sistema que el equipo puede leer, que sobrevive al turnover, y que mantiene vivas las inversiones en SaaS en las partes del workflow donde todavía tienen sentido.

Qué hacer esta semana

Si estás mirando esta decisión hoy, el trabajo no es filosófico. Es una tarde.

Escribí el workflow. Listá las herramientas que lo tocan. Corré las cuatro preguntas, en orden. Si el workflow no es central, pará y comprá algo. Si un producto encaja, pará y comprá ese. Si una capa stitched funciona los próximos doce meses, pará y coselo, y poné un recordatorio en el calendario para revisarlo. Si nada de eso aplica y el workflow es estable, build.

Los founders que aciertan esta decisión no son los que agonizan sobre ella. Son los que plantean la pregunta correcta, deciden rápido, y revisan la decisión cuando el negocio cambia. Ahí está la mayor parte del valor.

FAQ

¿Cuál es la diferencia entre build y buy?
Build significa escribir software a medida para tu workflow específico. Buy significa comprar un producto pronto que resuelve un problema parecido para muchas empresas. En la práctica existe una tercera opción, coser varios productos SaaS con automatizaciones y una fina capa custom, y es la respuesta correcta con más frecuencia de la que los founders perciben en etapas tempranas.

¿Es mejor construir o comprar?
Para un founder no técnico en etapa temprana, buy es la respuesta correcta la mayor parte de las veces. Build solo es la respuesta correcta cuando el workflow es central para los ingresos, ningún producto de góndola encaja, coser no es viable, y el workflow es lo bastante estable como para codificar. Fuera de esas condiciones, el software a medida es más caro y más lento que las alternativas.

¿Cuánto cuesta build vs buy?
Una herramienta interna a medida chica suele costar $20K–$60K y corre de cuatro a diez semanas con un estudio chico partner. Un v1 de una superficie de producto orientada al cliente cae en $80K–$250K. El gasto equivalente en SaaS para el mismo workflow suele ser $5K–$30K por año. La matemática favorece a buy, salvo que el workflow sea central y duradero.

¿Cuándo una startup debe construir su propio software?
Cuando el software es el producto, cuando un workflow operativo genera ventaja compuesta a escala, cuando la profundidad de integración entre sistemas internos es única del negocio, o cuando la responsabilidad regulatoria hace que el riesgo del proveedor sea inaceptable. Esos son los cuatro casos en los que build gana. Fuera de ellos, buy o stitch.