Product-Market Fit Tècnic: Per Què la Teva Arquitectura Ha d'Evolucionar amb el Teu Producte
Product-market fit acapara tota l'atenció. Cada podcast de startups, cada fil de Twitter, cada pitch deck parla de trobar PMF. I té sentit: sense ell, no tens negoci.
Però hi ha un concepte paral·lel del qual gairebé ningú parla: el product-market fit tècnic. És el moment en què la teva arquitectura coincideix (o deixa de coincidir) amb el que el teu producte necessita lliurar. I quan hi ha un desajust entre tots dos, tot s'alenteix.
La teva arquitectura del dia 1 no hauria de ser la mateixa del dia 365. El que et va permetre llançar ràpid es converteix en el llast que t'impedeix escalar. I la diferència entre les startups que naveguen aquesta transició i les que s'estanquen és gairebé sempre la mateixa: tenir l'equip adequat per evolucionar l'arquitectura en el moment correcte.
Fase 1: Pre-PMF — La teva tecnologia hauria de ser rebutjable
Abans de trobar product-market fit, el teu treball tècnic té un únic objectiu: validar hipòtesis tan ràpid com sigui possible.
En aquesta fase, la velocitat importa més que la qualitat del codi. Sona a heretgia, però és la realitat. Si no saps si el teu producte existirà d'aquí a 6 mesos, optimitzar per escalabilitat és una pèrdua de temps i diners.
El que necessites en aquesta fase:
- Monòlit simple: un únic servei, un únic repositori, una base de dades. Res de microserveis. Res d'event-driven architecture. Complexitat mínima.
- Framework madur: Rails, Django, Next.js, Laravel. Alguna cosa que et doni velocitat de desenvolupament i un ecosistema de llibreries. No és moment d'experimentar amb tecnologia bleeding edge.
- Deploy bàsic: un PaaS com Heroku, Vercel, Railway o Fly.io. Si estàs configurant Kubernetes abans de tenir 100 usuaris, estàs sobreenginyeriant.
- Tests mínims: tests per a la lògica de negoci crítica. No cobertura del 90%. Només el que t'impedeix trencar el que importa.
La regla en aquesta fase: escriu codi que puguis llençar a les escombraries sense dolor. Perquè probablement ho faràs. Pivotaràs, canviaràs el model de dades, descobriràs que la feature que pensaves que era central és irrellevant.
L'error més comú aquí és contractar un enginyer senior que ve d'una empresa gran i vol implementar totes les "millors pràctiques" des del dia u. Kafka per a messaging. Microserveis. CI/CD amb 14 stages. Infraestructura com a codi per a 3 servidors. Tot això et frena quan hauries d'estar validant.
Fase 2: Early PMF — Tens usuaris que paguen. Ara necessites fiabilitat
Has trobat product-market fit. Tens usuaris reals, pagant diners reals, depenent del teu producte. El joc canvia.
En aquesta fase no et pots permetre que el sistema caigui sense que ningú se n'assabenti. No pots perdre dades d'usuaris. No pots tenir una vulnerabilitat de seguretat bàsica que algú exploti.
El que necessites implementar ara:
- Backups automatitzats i provats: no només configurar backups, sinó verificar regularment que pots restaurar des d'ells. Un backup que no pots restaurar no és un backup.
- Monitorització i alertes: error tracking (Sentry, Bugsnag), monitorització d'infraestructura (Datadog, Grafana), alertes quan alguna cosa es trenca. Si el teu usuari t'avisa abans que el teu sistema d'alertes, tens un problema.
- Seguretat bàsica: HTTPS a tot arreu, autenticació robusta, inputs sanititzats, dependències actualitzades. No necessites un pentest complet encara, però sí els fonaments.
- Refactoritzar el deute tècnic més perillós: no tot el deute tècnic. Només el que et frena o el que pot provocar un incident. Aquell endpoint que de vegades tarda 30 segons. Aquella consulta SQL que no té índex. Aquell component que ningú entén.
L'equilibri en aquesta fase és delicat. Necessites seguir movent-te ràpid (la teva competència no para) però amb una base més sòlida. És com canviar les rodes del cotxe mentre condueixes.
Fase 3: Growth — La teva arquitectura necessita suportar 10x
Has crescut. Més usuaris, més dades, més equip. I aquí és on les decisions tècniques primerenques et passen factura. O et donen avantatge.
La teva arquitectura necessita gestionar 10x tràfic, 10x dades i 10x equip respecte a la fase anterior. Cadascun d'aquests multiplicadors porta desafiaments diferents:
10x tràfic significa que el que funcionava amb 1.000 usuaris concurrents es trenca amb 10.000. Necessites caching, CDN, optimització de queries, possiblement separar lectura d'escriptura a la teva base de dades.
10x dades significa que les consultes que tardaven mil·lisegons comencen a tardar segons. Necessites indexació intel·ligent, arxivat de dades històriques, possiblement migrar a una base de dades més adequada per al teu patró d'accés.
10x equip significa que 3 enginyers treballant al mateix monòlit poden coordinar-se en persona. 15 no poden. Necessites separar dominis, definir interfícies clares entre mòduls, possiblement extreure els primers serveis independents.
Les decisions primerenques que exploten en aquesta fase:
- El model de dades que semblava "suficient" però no suporta les features que els teus usuaris demanen
- El monòlit sense separació de dominis on cada canvi pot trencar alguna cosa inesperada
- L'absència de tests que fa que cada refactor sigui un salt de fe
- El pipeline de desplegament manual que tarda hores i requereix una persona específica
Senyals de desajust tècnic-producte
Com saber si la teva arquitectura ja no encaixa amb el teu producte:
- La teva arquitectura no suporta les features que els usuaris volen. L'equip de producte demana alguna cosa que "hauria de ser simple" i els enginyers diuen que portarà mesos per com està estructurat el sistema.
- Desplegar tarda hores en comptes de minuts. Cada desplegament és un esdeveniment estressant que requereix coordinació entre múltiples persones.
- Incorporar nous desenvolupadors tarda setmanes. Si un enginyer senior necessita més de 2 setmanes per fer la seva primera contribució significativa, el teu codebase té un problema de complexitat o documentació.
- Els bugs augmenten amb cada release. Cada nova feature introdueix regressions. L'equip sent que va dos passos endavant i un enrere constantment.
- Els enginyers eviten tocar certes parts del codi. Hi ha mòduls que ningú vol modificar perquè "sempre es trenquen". Aquestes zones de por creixen amb el temps.
Si reconeixes tres o més d'aquests senyals, estàs en un moment de desajust tècnic-producte. I la solució no és només tècnica: és d'equip.
L'evolució de l'equip que la teva arquitectura necessita
L'arquitectura no evoluciona sola. Evoluciona perquè l'equip la fa evolucionar. I cada fase necessita perfils diferents:
De desenvolupador sol a equip petit (2-4): necessites generalistes. Gent que pugui tocar frontend, backend, base de dades i infraestructura. No hi ha espai per a especialistes purs.
D'equip petit a múltiples equips (5-15): necessites separar responsabilitats. Un equip de producte, potser un equip de plataforma. Apareixen els primers especialistes: un enginyer enfocat en infraestructura, un altre en dades.
De múltiples equips a equip de plataforma (15+): necessites un equip dedicat a la plataforma interna: CI/CD, eines de desenvolupament, abstraccions compartides. Sense això, cada equip reinventa la roda.
L'error més car: canviar l'arquitectura sense canviar l'equip. Si decideixes migrar a microserveis però el teu equip mai ha operat un sistema distribuït, crearàs més problemes dels que resols. L'arquitectura ha de coincidir amb la capacitat de l'equip per operar-la.
Errors comuns en cada fase
Sobreenginyeria en pre-PMF: microserveis amb 50 usuaris. Kubernetes per a una API amb 10 endpoints. Event sourcing per a un CRUD. Tot això retarda la validació del producte i consumeix capital en infraestructura que no necessites.
Subinversió en growth: "ja ho arreglarem després" és la frase que precedeix els incidents en producció. Quan els usuaris creixen 3x en un trimestre i la teva infraestructura no ha canviat en un any, estàs vivint de prestat.
Canviar arquitectura sense canviar equip: decidir que "ara som microserveis" sense tenir enginyers que entenguin orquestració de serveis, observabilitat distribuïda i gestió de consistència eventual. El resultat és un sistema distribuït amb tots els problemes d'un monòlit més tots els problemes de microserveis.
Tenir l'equip per a l'evolució
El product-market fit tècnic no és una destinació. És un procés continu d'ajust entre el que el teu producte necessita i el que la teva arquitectura pot lliurar. I el factor determinant és tenir enginyers que hagin passat per aquestes fases abans.
Un enginyer que ha viscut la transició de monòlit a serveis sap quan és el moment correcte (i quan és massa aviat). Un enginyer que ha escalat una base de dades d'1 milió a 100 milions de registres sap quines optimitzacions importen i quines són prematures. Un enginyer que ha vist un equip créixer de 5 a 30 persones sap quines pràctiques de desenvolupament necessites implementar abans que la coordinació es converteixi en un coll d'ampolla.
A Conectia connectem startups europees amb enginyers senior de LATAM que han passat per aquestes fases d'escalat. No són juniors que aprenen sobre el teu producte. Són professionals amb experiència en les decisions arquitectòniques que importen a cada etapa: quan mantenir el monòlit, quan extreure el primer servei, quan invertir en plataforma interna.
El teu producte evolucionarà. El teu mercat canviarà. La pregunta és si la teva arquitectura i el teu equip poden evolucionar al mateix ritme.
La teva arquitectura s'està quedant enrere respecte al que el teu producte necessita? Parla amb un CTO — t'ajudem a incorporar enginyers senior que saben quines decisions tècniques importen en cada fase de creixement.
