Due diligence tècnica: què revisen de debò els inversors al teu stack abans de signar el xec
Has aconseguit la reunió amb el partner. Les mètriques de negoci impressionen. El mercat és gran. L'equip té bona trajectòria. I llavors, al final de la segona reunió, et diuen: «Abans d'avançar amb el term sheet, ens caldrà fer una revisió tècnica».
La majoria de fundadors no hi arriben preparats.
No pas perquè la seva tecnologia sigui dolenta, sinó perquè no han vist mai el seu stack amb els ulls d'algú que té per feina trobar-hi riscos. Jo he fet aquestes revisions des de l'altra banda de la taula, i t'ho puc assegurar: en una due diligence tècnica, tot es veu diferent. Aquell workaround que vas desplegar per arribar a un termini es converteix en un «risk item». La decisió de saltar-te els tests perquè anaves de pressa es converteix en una «red flag». Aquell únic enginyer que coneix tot el sistema es converteix en un «single point of failure».
La bona notícia: si saps què hi busquen, t'hi pots preparar. I preparar-se no vol dir maquillar els problemes — vol dir arreglar els que importen i tenir respostes honestes per als que encara no has arreglat.
Què avaluen realment els inversors
La due diligence tècnica no és una auditoria de codi línia per línia. És una avaluació de risc. Els inversors — o els consultors tècnics que contracten — volen respondre una sola pregunta: aquesta tecnologia pot sostenir el creixement que promet el pla de negoci?
Per respondre-la, avaluen diverses dimensions:
Qualitat del codi. No esperen codi perfecte; esperen codi consistent. Hi ha estàndards d'estil? Es fan code reviews? Algú que no l'ha escrit, el pot llegir? Un codebase on cada enginyer té el seu propi estil delata que no hi ha supervisió tècnica.
Decisions d'arquitectura. Per què vas triar aquesta base de dades? Per què aquest framework? No busquen les respostes «correctes»: busquen decisions deliberades. Si vas triar PostgreSQL perquè vas avaluar les opcions i encaixava amb els teus patrons d'accés, perfecte. Si el vas triar perquè «és el que sabia el primer desenvolupador», això delata manca de lideratge tècnic.
Escalabilitat. Què passa quan els usuaris es multipliquin per deu? No cal que ho tinguis resolt, però has de saber quins problemes t'esperen. «Quan arribem a 50K usuaris concurrents haurem de separar el servei de cerca i afegir una capa de cache; ho estimem en 3-4 setmanes d'enginyeria» és una resposta excel·lent. «No hi hem pensat» no ho és.
Seguretat. Com gestioneu les credencials? HTTPS a producció? Dades xifrades en repòs? Control d'accés basat en rols? La seguretat és l'àrea on els inversors tenen tolerància zero: una bretxa pot enfonsar la reputació de l'empresa — i la seva inversió.
Deute tècnic. Totes les startups en tenen. Els inversors ho saben. El que volen veure és que en siguis conscient i tinguis un pla. «Tenim deute tècnic important al mòdul de pagaments; és al backlog com a prioritat del Q1» genera confiança. Fer veure que no existeix la destrueix.
Maduresa del CI/CD. Com va el codi d'un commit a producció? Tests automatitzats? Desplegament automàtic? O algú entra per SSH al servidor i hi copia fitxers? El grau d'automatització del teu pipeline és un proxy directe de la maduresa de l'equip.
Les red flags que tomben operacions
Aquestes són les troballes que fan que un inversor es faci enrere o retalli la valoració de manera significativa:
Sense tests automatitzats. Sense tests no pots desplegar amb confiança, i qualsevol canvi pot trencar funcionalitat que ja funcionava. És un risc operatiu que impacta directament l'execució del roadmap.
Sense CI/CD. Desplegar a mà vol dir desplegaments lents, propensos a errors i difícils de revertir. Si el teu procés és «l'enginyer sènior fa push a producció els dijous a la tarda», tens un problema.
Single point of failure humà. Un desenvolupador que és l'únic que entén el sistema. Si marxa — i la gent marxa — l'empresa s'enfronta a un risc existencial. Els inversors pregunten pel bus factor: si la resposta és «una persona», la red flag és seriosa.
Credencials hardcodejades. Contrasenyes de la base de dades, claus d'API, tokens d'accés escrits directament al codi font. No és només un risc de seguretat: delata que ningú de l'equip té experiència amb pràctiques bàsiques de seguretat. I si són al repositori de Git, el dany encara és més gran: encara que les esborris, queden a l'historial.
Sense monitoratge. Com saps que l'aplicació funciona? Com saps que va lenta? Com t'assabentes que un servei ha caigut? Si la resposta és «quan es queixa un usuari», l'inversor ja sap que voles a cegues.
Dependències abandonades o vulnerables. Biblioteques que fa anys que no s'actualitzen, frameworks en versions obsoletes, dependències amb vulnerabilitats conegudes. Tot plegat indica que ningú gestiona activament la salut del projecte.
Les green flags que generen confiança
A l'altre extrem de l'espectre, aquests són els senyals que fan que un inversor se senti còmode amb la tecnologia:
Historial de Git net. Commits amb missatges descriptius, pull requests amb review, branques ordenades. Un historial net indica processos de desenvolupament madurs i un equip disciplinat.
Decisions d'arquitectura documentades. No cal documentació exhaustiva. Però un document que expliqui les tres o quatre decisions d'arquitectura més importants — què es va decidir, per què, quines alternatives es van considerar i quins tradeoffs es van acceptar — demostra que penseu de manera deliberada.
Tries tecnològiques assenyades. Ni les últimes novetats ni les més populars: les que tenen sentit per al problema. Un stack avorrit però adequat (Rails, Django, Node.js + PostgreSQL) genera més confiança que un stack exòtic que demana enginyers especialitzats difícils de trobar.
Separació de responsabilitats. El frontend separat del backend. La lògica de negoci separada de l'accés a dades. La configuració separada del codi. Aquests patrons bàsics d'enginyeria de programari indiquen que les decisions de disseny les va prendre algú amb experiència.
Desplegaments automatitzats. Un pipeline que va del commit a producció amb tests, build i deploy automàtics. Punt extra si hi ha entorn de staging, rollback automatitzat i feature flags.
Monitoratge i alertes. Dashboards que mostren la salut del sistema, alertes quan alguna cosa falla, logs centralitzats i accessibles. No cal que sigui sofisticat: amb Datadog, Grafana o fins i tot un CloudWatch ben configurat ja n'hi ha prou.
Com preparar-te abans que arribi la due diligence
No esperis que l'inversor demani la revisió tècnica. Audita el teu propi stack abans que ho facin ells.
Setmana 1: inventari i red flags. Credencials hardcodejades, dependències vulnerables, codi mort, configuracions insegures. Són les correccions més ràpides i les que més mal fan si les troba algú altre.
Setmana 2: CI/CD i tests. Si no tens pipeline de CI/CD, munta'n un de bàsic. Si no tens tests, comença pels fluxos que generen ingressos. No et cal una cobertura del 80%.
Setmana 3: documentació mínima. Un document d'arquitectura d'una pàgina: quins serveis hi ha, com es comuniquen, quines tecnologies fan servir i per què. Documenta les tres decisions tècniques més importants.
Setmana 4: monitoratge. Uptime, temps de resposta, errors, alertes per a les fallades crítiques. Això no només et prepara per a la due diligence: et fa operar millor.
El factor equip: els inversors aposten per persones
El codi es pot reescriure. L'arquitectura es pot millorar. Però si l'equip no té capacitat per executar al nivell següent, tota la resta no importa.
Els inversors avaluen l'equip tècnic amb una pregunta ben simple: aquestes persones poden escalar amb l'empresa?
Busquen diversitat d'experiència, capacitat d'articular les decisions tècniques i proves que l'equip aprèn i s'adapta. Si el teu equip té mancances evidents — cap líder tècnic, ningú que hagi operat infraestructura a escala — els inversors les veuran.
La millor estratègia no és amagar les mancances: és reconèixer-les i tenir un pla. «Necessitem un enginyer de seguretat dedicat i tenim previst contractar-lo amb part dels fons d'aquesta ronda» és infinitament millor que fer veure que el teu equip de quatre generalistes ho cobreix tot.
Enforteix la teva posició abans de la ronda
A Conectia ajudem startups europees a preparar-se per a la due diligence tècnica de dues maneres concretes.
Primer, amb auditories tècniques fetes per CTOs amb experiència avaluant startups. Revisem codi, arquitectura, infraestructura i processos amb els mateixos criteris que farà servir l'inversor — i et lliurem un informe pràctic amb les correccions prioritzades.
Segon, amb team augmentation estratègica. Si el teu equip té mancances que un inversor detectarà — poca seniority, ningú que hagi escalat sistemes, dependència d'un sol enginyer — podem incorporar enginyers sènior de LATAM per reforçar aquestes àrees abans que comenci el procés de fundraising.
L'objectiu no és maquillar el teu stack. És que, quan l'inversor faci la revisió tècnica, hi trobi exactament el que vol trobar: un equip competent, amb decisions deliberades, que sap on té les debilitats i té un pla per resoldre-les.
Encares una ronda de finançament i vols que el teu stack hi arribi preparat? Parla amb un CTO — fem l'auditoria tècnica abans que la facin els teus inversors.
