Partner de desenvolupament per a la teva startup: futur, no legacy

Triar el partner de desenvolupament de software per a la teva startup és una de les decisions més cares que prens abans de tenir ingressos — i gairebé sempre es pren pel criteri equivocat: qui lliura més ràpid i més barat. El problema és que la velocitat d'una arrencada de startup té dues factures. La primera la pagues ara, en temps i diners. La segona la pagues després, quan intentes escalar el producte i descobreixes que el que es va construir ràpid no es va construir per durar. Aquest article va sobre com triar un partner que no et passi aquesta segona factura.

El parany: velocitat avui, sostre demà

El mercat de "et construïm el teu producte" està ple d'opcions que optimitzen per al que un founder no tècnic pot avaluar: una demo bonica, ràpid i a bon preu. I aquí hi ha el parany, perquè el que fa escalable un producte és justament el que no es veu a la demo:

• La demo no mostra si hi ha especificació. Un producte construït "a ull", sense definir regles de negoci ni casos límit, funciona al camí feliç i es trenca tan bon punt arriba un usuari real que fa alguna cosa inesperada.
• La demo no mostra si hi ha tests. Sense una xarxa de seguretat automàtica, cada feature nova pot trencar-ne tres de velles — i en tres mesos l'equip dedica més temps a apagar focs que a construir.
• La demo no mostra qui entén el codi. Si només l'entén qui el va escriure, has comprat una dependència, no un actiu. El dia que aquesta persona marxa (o el partner factura l'última hora), et quedes amb un producte que no pots tocar.

Res d'això no fa mal a la seed. Fa mal a la Sèrie A, quan un inversor envia una due diligence tècnica i l'informe diu "deute tècnic alt, arquitectura no escalable, bus factor d'un". Aquest informe no baixa la teva valoració una mica: reobre la negociació sencera.

"Legacy" no és codi vell. És codi que ningú pot canviar amb seguretat

Solem pensar que legacy és un sistema de fa vint anys. En una startup, el legacy apareix en sis mesos: és qualsevol codi que el teu equip no pot modificar amb confiança perquè ningú sap què trencarà. La IA, mal feta servir, l'accelera — generar codi a tota velocitat sense especificació ni verificació produeix legacy més ràpid que mai, no menys.

Construir "per al futur" no significa sobre-enginyeria ni triar l'arquitectura més de moda. Significa una cosa molt més simple i més difícil: que cada peça del producte tingui una especificació del que fa, una verificació que ho fa bé, i un rastre de per què està construïda així. Això és el que permet que un equip que arriba nou —el CTO que contractes després de la ronda— entengui el sistema en dies en comptes de en trimestres, i segueixi construint a sobre sense por.

Com construeix un partner que pensa en la teva Sèrie A

A la pràctica d'onext, construir producte de startup "per al futur" es recolza en tres coses concretes que pots exigir a qualsevol partner:

• Spec-Driven Development (SDD): abans d'escriure codi, s'especifica què es construeix, amb quines regles i quins casos límit. El codi es genera contra aquesta diana, no contra una intuïció. És el que evita el producte "caixa negra".
• Enginyeria de context: el coneixement de com funciona el teu negoci i el teu producte es recull i es codifica com a context reutilitzable —no viu al cap d'un freelancer—. Quan el partner marxa, aquest context es queda amb tu.
• Verificació humana a cada pas (human-on-the-loop): la IA accelera, però una persona signa a cada frontera de risc. Velocitat amb control, no "prompt i a producció". Producció governada, no una demo que resa per no trencar-se.

La diferència és mesurable: en els equips de producte que onext acompanya, el patró és ×7 de velocitat de lliurament amb 0 sprints perduts i −50% de time-to-production. Però per a un founder el número que més importa és un altre: en acabar, el mètode i el control es queden al teu equip. No et venem una dependència amb data de renovació; et deixem un producte que el teu propi equip pot operar i escalar.

Cinc preguntes per triar partner (abans de signar)

Porta aquestes cinc a qualsevol conversa amb un candidat a construir el teu producte. Les respostes et diuen més que qualsevol portfolio:

1. Escriviu una especificació abans de codificar, o aneu directes al codi? Si no hi ha spec, no hi ha manera de saber si el construït és correcte — només si "sembla" que funciona.
2. Quina cobertura de tests lliureu, i la puc veure? Sense tests, cada release futura és una aposta. La resposta ha de ser un número, no un "sí, testegem".
3. Quan acabeu, el meu equip podrà entendre i modificar el codi sense vosaltres? Si la resposta honesta és "és més fàcil que seguim nosaltres", estàs comprant dependència.
4. Com feu servir la IA — per anar més ràpid, o per construir millor? La bona resposta parla d'especificar i verificar millor, no només de teclejar més ràpid. La IA sense mètode produeix deute a més velocitat.
5. Què passa amb el que apreneu del meu negoci quan el projecte acaba? S'ha de quedar amb tu, documentat i utilitzable. Si marxa amb ells, la propera ronda de canvis torna a passar per la seva factura.

Preguntes freqüents

Com trio un partner de desenvolupament per a la meva startup?

No per preu ni per velocitat de la demo, sinó pel que et deixa quan acaba: un producte amb especificació, tests i context documentat que el teu equip pot entendre i escalar sense dependre del partner. Pregunta explícitament si construeixen amb Spec-Driven Development, quina cobertura de tests lliuren i si el coneixement del teu negoci es queda amb tu. Un partner que construeix per a la teva Sèrie A optimitza l'actiu que et queda, no només el lliurament d'avui.

Per què és perillós construir l'MVP "ràpid i barat"?

Perquè la velocitat té dues factures. La primera la pagues en arrencar; la segona en escalar, quan el codi construït sense especificació ni tests es converteix en deute tècnic que frena cada feature nova i apareix a la due diligence de la teva ronda. Ràpid i barat està bé si a més és especificat i verificat; sense això, és un sostre que et poses a tu mateix.

La IA no fa que construir producte sigui més ràpid i prou?

La IA accelera escriure codi, però sense mètode accelera també el deute: genera més codi, més ràpid, que ningú va especificar ni verificar. "Construir per al futur" amb IA significa fer-la servir per especificar i verificar millor —no només per teclejar més—, amb una persona signant a cada pas de risc. Aquesta és la diferència entre un producte que escala i una caixa negra que corre ràpid cap al mur.

Conclusió

El partner que triïs per construir el teu producte no decideix només quan surts al mercat: decideix quant et costarà créixer després. "Construir per al futur" no és sobre-enginyeria ni la tecnologia de moda; és especificació, verificació i control que es queden al teu equip — el que fa que un CTO nou entengui el teu sistema en dies i segueixi construint sense por. Tria pel que et deixa, no només pel ràpid que lliura.

Si estàs a punt de signar amb un partner —o ja treballes amb un i no saps què et quedarà quan marxi— comença per un diagnòstic: en unes setmanes tens una foto honesta de la salut del teu producte (especificació, tests, dependència) i un pla per construir la resta de cara al futur, amb el control al teu equip.