Product-market fit tècnic: per què l'arquitectura ha d'evolucionar amb el producte

El 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 PMF no hi ha negoci.

Però hi ha un concepte paral·lel que gairebé mai sento discutir: el product-market fit tècnic. És el punt en què la teva arquitectura encaixa (o deixa d'encaixar) amb el que el teu producte ha d'oferir. I quan totes dues coses es desajusten, tot s'alenteix.

L'arquitectura del dia 1 no hauria de ser la 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 superen aquesta transició i les que s'encallen és gairebé sempre la mateixa: tenir l'equip adequat per fer evolucionar l'arquitectura en el moment oportú.

Fase 1: pre-PMF — tecnologia d'usar i llençar

Abans de trobar product-market fit, la teva feina tècnica 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 a l'escalabilitat és llençar temps i diners.

El que necessites en aquesta fase:

• Monòlit simple: un servei, un repositori, una base de dades. Ni microserveis, ni arquitectura event-driven. 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 el moment d'experimentar amb tecnologia bleeding-edge.
• Desplegament bàsic: un PaaS com Heroku, Vercel, Railway o Fly.io. Si muntes Kubernetes abans de tenir 100 usuaris, estàs fent sobreenginyeria.
• Tests mínims: tests per a la lògica de negoci crítica. No pas una cobertura del 90%. Just el necessari per no trencar el que importa.

La regla en aquesta fase: escriu codi que puguis llençar sense recança. Perquè probablement el llençaràs. Pivotaràs, canviaràs el model de dades, descobriràs que la feature que creies central és, de fet, irrellevant.

L'error més habitual que veig aquí és contractar un enginyer sènior vingut d'una gran empresa que vol implantar totes les «bones pràctiques» des del primer dia. Kafka per a la missatgeria. Microserveis. CI/CD amb 14 etapes. Infraestructura com a codi per a 3 servidors. Tot plegat 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 que paguen diners reals i que depenen del teu producte. El joc canvia.

En aquesta fase no et pots permetre que el sistema caigui sense que ningú se n'adoni. No pots perdre dades dels usuaris. No pots tenir una vulnerabilitat de seguretat bàsica que algú acabi explotant.

El que has d'implementar ara:

• Backups automatitzats i provats: no n'hi ha prou de configurar-los; cal verificar regularment que pots restaurar-los. Un backup que no pots restaurar no és un backup.
• Monitorització i alertes: seguiment d'errors (Sentry, Bugsnag), monitorització d'infraestructura (Datadog, Grafana), alertes quan alguna cosa peta. Si l'usuari t'avisa abans que el teu sistema d'alertes, tens un problema.
• Seguretat bàsica: HTTPS pertot arreu, autenticació robusta, inputs sanejats, dependències al dia. Encara no necessites un pentest complet, però sí els fonaments.
• Refactoritzar el deute tècnic més perillós: no pas tot el deute tècnic. Només el que et frena o el que pot acabar en incident. Aquell endpoint que de tant en tant triga 30 segons. Aquella consulta SQL sense índex. Aquell component que no entén ningú.

L'equilibri en aquesta fase és delicat. Has de continuar avançant ràpid (la competència no s'atura), però sobre una base més sòlida. És com canviar les rodes amb el cotxe en marxa.

Fase 3: growth — l'arquitectura ha d'aguantar 10x

Has crescut. Més usuaris, més dades, més equip. I aquí és on les decisions tècniques inicials et passen factura. O et donen avantatge.

L'arquitectura ha de gestionar 10x de tràfic, 10x de dades i 10x d'equip respecte de la fase anterior. Cada multiplicador planteja reptes diferents:

10x de tràfic vol dir que el que funcionava amb 1.000 usuaris concurrents peta amb 10.000. Necessites caching, CDN, optimització de consultes i, potser, separar lectures i escriptures a la base de dades.

10x de dades vol dir que les consultes que trigaven mil·lisegons comencen a trigar segons. Necessites una indexació intel·ligent, arxivar les dades històriques i, potser, migrar a una base de dades més ben adaptada als teus patrons d'accés.

10x d'equip vol dir que 3 enginyers treballant sobre el mateix monòlit es poden coordinar de viva veu. 15, no. Necessites separar dominis, definir interfícies clares entre mòduls i, potser, extreure els primers serveis independents.

Les decisions inicials que esclaten en aquesta fase:

• El model de dades que semblava «prou bo» però que no pot suportar les features que demanen els usuaris
• El monòlit sense separació de dominis on qualsevol canvi pot trencar alguna cosa inesperada
• La manca de tests que converteix cada refactor en un acte de fe
• El pipeline de desplegament manual que triga hores i depèn d'una persona concreta

Una arquitectura que ja no encaixa deixa pistes

Deixa'm concedir d'entrada el contraargument evident: no totes les empreses necessiten aquesta evolució amb el calendari a la mà. Hi ha molts productes que funcionen anys i panys sobre el monòlit original, i això no és estancament: és que l'arquitectura encara encaixa amb el producte. El problema no és mantenir un stack avorrit; és mantenir-lo més enllà del punt en què va deixar d'encaixar, sense que ningú ho digui en veu alta. Així ho pots detectar:

• L'arquitectura no pot suportar les features que els usuaris volen. L'equip de producte demana una cosa que «hauria de ser senzilla» i els enginyers responen que trigaran mesos per com està estructurat el sistema.
• Desplegar triga hores en comptes de minuts. Cada desplegament és un esdeveniment estressant que exigeix coordinar diverses persones.
• Incorporar nous desenvolupadors costa setmanes. Si un enginyer sènior necessita més de 2 setmanes per fer la primera contribució significativa, el codebase té un problema de complexitat o de documentació.
• Els bugs augmenten amb cada release. Cada feature nova introdueix regressions. L'equip té la sensació de fer constantment dos passos endavant i un enrere.
• 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 t'hi reconeixes en tres o més senyals, ets en ple desajust tècnic-producte. I la solució no és només tècnica: passa per l'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 demana perfils diferents:

De desenvolupador en solitari a equip petit (2-4): necessites generalistes. Gent que pugui tocar frontend, backend, base de dades i infraestructura. No hi ha lloc per a especialistes purs.

D'equip petit a diversos equips (5-15): cal separar responsabilitats. Un equip de producte, potser un de plataforma. Apareixen els primers especialistes: un enginyer centrat en infraestructura, un altre en dades.

De diversos 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 no ha operat mai un sistema distribuït, crearàs més problemes dels que resoldràs. L'arquitectura ha d'encaixar amb la capacitat de l'equip per operar-la.

Cada fase té la seva manera de fallar

Sobreenginyeria en pre-PMF: microserveis amb 50 usuaris. Kubernetes per a una API de 10 endpoints. Event sourcing per a un CRUD. Tot plegat retarda la validació del producte i crema capital en infraestructura que no necessites.

Subinvertir durant el growth: «ja ho arreglarem més endavant» és la frase que precedeix els incidents en producció. Quan els usuaris creixen 3x en un trimestre i la infraestructura fa un any que no canvia, vius de pròrroga.

Canviar l'arquitectura sense canviar l'equip: decidir que «a partir d'ara fem microserveis» sense enginyers que entenguin l'orquestració de serveis, l'observabilitat distribuïda i la gestió de la consistència eventual. El resultat és un sistema distribuït amb tots els problemes d'un monòlit i, a sobre, tots els dels microserveis.

El factor decisiu és l'equip, no l'stack

El product-market fit tècnic no és un punt d'arribada. És un procés continu d'alineació entre el que el producte necessita i el que l'arquitectura pot oferir. I el factor decisiu és tenir enginyers que ja hagin passat per aquestes fases.

Un enginyer que ha viscut la transició de monòlit a serveis sap quan és el moment (i quan és massa d'hora). 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 créixer un equip de 5 a 30 persones sap quines pràctiques de desenvolupament cal implantar abans que la coordinació es converteixi en un coll d'ampolla.

A Conectia connectem startups europees amb enginyers sèniors de LATAM que han passat per aquestes fases d'escalat. No són júniors aprenent sobre el teu producte. Són professionals amb experiència en les decisions d'arquitectura que importen a cada etapa: quan mantenir el monòlit, quan extreure el primer servei, quan invertir en una plataforma interna.

El teu producte evolucionarà. El teu mercat canviarà. La pregunta és si la teva arquitectura i el teu equip podran evolucionar al mateix ritme.

---

La teva arquitectura s'està quedant enrere del que el teu producte necessita? Parla amb un CTO — t'ajudem a incorporar enginyers sèniors que saben quines decisions tècniques importen a cada fase de creixement.