Build vs. buy: com decidir què construeixes i què compres al teu stack tecnològic

Tota startup tecnològica es troba amb aquesta decisió desenes de vegades. Cada funcionalitat nova, cada peça nova de l'stack, cada integració obre la mateixa pregunta: ho construïm nosaltres o fem servir alguna cosa que ja existeix?

La resposta instintiva sol ser «construir», sobretot si tens un equip d'enginyeria motivat. Construir és més divertit. Comprar fa l'efecte de rendir-se. Però he vist massa startups cremar mesos de runway construint la seva pròpia autenticació, el seu propi sistema de pagaments o el seu propi framework d'analítica. I les he vist abandonar aquell codi a mig fer quan s'adonaven que no era allò que diferenciava el seu producte.

La decisió build vs. buy no és tècnica. És estratègica. I hi ha un marc clar per prendre-la.

La regla fonamental: construeix el que et diferencia, compra tota la resta

Si hagués de condensar tot aquest article en una sola frase, seria aquesta: construeix només allò que fa únic el teu producte. Compra, integra o tira d'open source per a tota la resta.

El teu avantatge competitiu no és el sistema de login. Ni el pipeline d'enviament de correus. Ni el dashboard de mètriques internes. És la lògica de negoci que resol el problema del teu usuari d'una manera que ningú més pot replicar fàcilment.

Tot el que envolta aquesta lògica central és infraestructura. I la infraestructura, es compra.

Què comprar (gairebé sempre)

Hi ha categories on la decisió és clara. Per a una startup, construir-les és gairebé sempre un error:

• Autenticació i autorització: Auth0, Clerk, Firebase Auth, Supabase Auth. Gestionar contrasenyes, MFA, OAuth, tokens de sessió, rols i permisos és un problema resolt. I cada bug en un sistema d'auth fet a casa és una vulnerabilitat de seguretat.

• Pagaments: Stripe, Paddle, Mollie. Processar pagaments té implicacions legals, de compliment normatiu (PCI DSS) i comptables que no vols gestionar internament. Punt.

• Correu transaccional: Resend, SendGrid, Postmark. Muntar infraestructura de correu amb bona deliverability és feina a temps complet per a un equip sencer.

• Analítica i observabilitat: Mixpanel, Amplitude, PostHog per a producte. Datadog, Sentry per a infraestructura. Tret que l'analítica sigui el teu producte, no la construeixis.

• Infraestructura i hosting: AWS, GCP, Vercel, Railway. El 2023 ja ningú no munta els seus propis servidors.

• Cerca: Algolia, Typesense, Meilisearch. Fer un bon motor de cerca és sorprenentment difícil.

En cadascun d'aquests casos hi ha empreses senceres dedicades a resoldre aquell problema concret. Equips de centenars d'enginyers que no fan res més. No els guanyaràs amb dues persones i un sprint.

Què construir (el teu moat)

Construeix quan es compleixi una o més d'aquestes condicions:

• És la teva proposta de valor central. Si el teu producte és una plataforma d'analítica, és evident que el motor d'analítica el construeixes tu. Si el teu producte és un processador de pagaments, construeixes la infraestructura de pagaments.

• Conté algorismes propis. Si tens lògica de negoci que és el teu avantatge competitiu real — un sistema de recomanació únic, un model de preus dinàmics, un pipeline de processament de dades diferencial — això es construeix a casa.

• La UX és el diferenciador. Si l'experiència d'usuari és el que et distingeix de la competència, necessites control total sobre com es construeix. No et pots diferenciar per UX si depens dels components d'un tercer.

• Cap solució existent encaixa amb el teu problema. De vegades ets en un nínxol tan específic que cap producte del mercat hi encaixa. En aquest cas, construir és l'única opció. Però comprova que de debò no existeix res: els fundadors tendim a subestimar el que ja hi ha.

Els costos ocults de construir

Construir té costos que no surten a la planificació de l'sprint:

Manteniment continu. Cada component que construeixes és codi que hauràs de mantenir indefinidament. Pedaços de seguretat, compatibilitat amb versions noves, bugs que afloren mesos més tard. Un sistema d'auth fet a casa no és un projecte de dues setmanes: és un compromís permanent.

Cost d'oportunitat. Cada hora que el teu equip dedica a construir infraestructura que ja és una commodity és una hora que no dedica al producte. Per a una startup amb 3-5 enginyers, això poden ser mesos de retard en funcionalitats que generen ingressos.

Contractació. Mantenir components interns complexos demana perfils especialitzats. Si l'enginyer de pagaments marxa, l'has de substituir per algú que entengui aquell sistema concret.

Qualitat inferior. Sona dur, però és així. Un equip de tres persones no construirà un sistema d'autenticació més robust que el d'Auth0, que hi té centenars d'enginyers dedicats en exclusiva.

Els costos ocults de comprar

Comprar tampoc no surt de franc. Aquests són els riscos reals:

Vendor lock-in. Com més a fons integres un servei, més difícil és migrar-ne. Stripe és fantàstic, però si al cap de tres anys decideixes canviar de processador de pagaments, tindràs un bon projecte de migració entre mans.

Deute d'integració. Cada servei extern és una API que pot canviar, un SDK que s'ha d'actualitzar, un punt de fallada que no controles. Amb 10-15 serveis externs, la complexitat d'integració comença a pesar.

Límits de personalització. Les solucions de tercers fan perfectament el 80% del que necessites. El 20% restant pot obligar-te a fer nyaps, o directament no ser possible.

Costos que escalen. Molts SaaS cobren per ús. El que costa 50 euros al mes amb 100 usuaris en pot costar 5.000 amb 100.000. Calcula el cost a 18-24 mesos vista, no només el del primer mes.

Un marc per decidir

Per a cada component que et faci dubtar, fes-te aquestes preguntes:

1. És central per a la teva proposta de valor? Si ho és: construeix. Si no: pregunta següent.

2. Hi ha cap solució al mercat que cobreixi més del 80% dels teus requisits? Si n'hi ha: compra. Si no: pregunta següent.

3. El teu equip té l'expertesa per construir-ho bé? Si no la té: millor una solució imperfecta comprada que una de dolenta feta a casa. Si la té: pregunta següent.

4. Et pots permetre el cost d'oportunitat? Estima quantes setmanes d'enginyer costa construir-ho. Multiplica-ho pel que aquelles setmanes podrien produir al teu producte. Si el cost d'oportunitat supera el cost del SaaS a dos anys vista: compra.

5. El vendor lock-in és acceptable? Valora el cost de migració futur. Si és assumible: compra. Si ets en un sector on dependre d'un proveïdor és un risc existencial: planteja't construir sobre estàndards oberts.

Quan cal repensar la decisió

La decisió build vs. buy no és estàtica. Canvia amb l'etapa de l'empresa:

Pre-product-market fit (0-50 clients): compra sense manies. L'únic objectiu és validar hipòtesis tan de pressa com puguis. Cada dia de més muntant infraestructura és un dia de menys provant el mercat.

Post-PMF, pre-escala (50-500 clients): comença a avaluar quins components comprats et limiten el creixement o la diferenciació. És el moment de començar a construir substituts per als serveis que generen més fricció.

Escala (500+ clients): ara ja tens equip i recursos per construir més. Identifica els components on el ROI de fer-ho a casa és clar: reducció de costos a escala, eliminació de límits tècnics, control total de l'experiència.

El que no hauries de fer mai és construir abans d'hora. L'error més car no és pagar 200 euros al mes per un SaaS que podries replicar. És cremar tres mesos d'equip construint una cosa que no calia construir mentre la competència anava traient funcionalitats.

Quan decideixes construir, l'equip ho és tot

Aquí és on la decisió build vs. buy topa amb una realitat pràctica: quan decideixes que una cosa val la pena construir-la a casa, la qualitat de l'equip que la construeix defineix el resultat.

Construir el teu core no és feina de juniors. Necessites enginyers sènior que ja hagin pres aquestes decisions abans, que entenguin les implicacions a llarg termini de cada elecció arquitectònica i que sàpiguen dissenyar sistemes que escalin sense reescriptures.

El problema és que aquests perfils són escassos i cars als mercats europeus. I contractar malament per a un component core és pitjor que no construir-lo.

A Conectia resolem exactament això. Connectem startups europees amb enginyers sènior de LATAM, validats tècnicament per CTOs, amb experiència construint els components core que diferencien un producte. No són perfils per mantenir un CRUD: són enginyers que han dissenyat sistemes propis, pipelines de dades complexos i arquitectures que aguanten escala real.

El procés és ràpid: defineixes el perfil, et presentem candidats prevalidats en 72 hores i el teu equip decideix. Ni mesos de sourcing ni recruiters que no distingeixen un enginyer de backend d'un desenvolupador de frontend.

La decisió correcta és la que et preserva el focus

Build vs. buy no és una qüestió d'orgull tècnic. És una qüestió de focus. Cada component que construeixes és un component que mantens, i cada component que compres és una dependència que gestiones.

La startup que guanya no és la que construeix més. És la que construeix les coses adequades — i les construeix bé.

---

Si has decidit que el teu pròxim component core val la pena construir-lo, parla amb un CTO sobre els enginyers sènior que te l'han de construir.