Due Diligence Tècnica: Què Revisen els Inversors al teu Stack Abans d'Invertir
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, necessitarem fer una revisió tècnica."
La majoria de fundadors no estan preparats per a aquell moment.
No perquè la seva tecnologia sigui dolenta — sinó perquè mai han vist el seu stack a través dels ulls d'algú la feina del qual és trobar riscos. I en una due diligence tècnica, tot es veu diferent. Aquell workaround que vas implementar per complir un deadline es converteix en un "risk item." Aquella decisió de no escriure tests perquè anaves ràpid es converteix en una "red flag." Aquella dependència d'un sol enginyer que coneix tot el sistema es converteix en un "single point of failure."
La bona notícia: si saps què busquen, pots preparar-te. I preparar-se no significa maquillar problemes — significa arreglar els que importen i tenir respostes honestes per als que no has arreglat encara.
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 — busquen respondre una pregunta: pot aquesta tecnologia sostenir el creixement que promet el business plan?
Per respondre-la, avaluen diverses dimensions:
Qualitat de codi. No esperen codi perfecte. Esperen codi consistent. Hi ha estàndards d'estil? Es fan code reviews? El codi és llegible per algú que no el va escriure? Un codebase on cada enginyer té el seu propi estil és un senyal 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 respostes deliberades. Si vas triar PostgreSQL perquè vas avaluar les opcions i encaixava amb els teus patrons d'accés, bé. Si el vas triar perquè "és el que el primer desenvolupador sabia", això és un senyal de manca de lideratge tècnic.
Escalabilitat. Què passa quan els teus usuaris es multipliquen per 10? No necessites haver resolt aquests problemes encara, però necessites saber quins són. "Quan arribem a 50K usuaris concurrents haurem de separar el servei de cerca i afegir cache — estimem 3-4 setmanes d'enginyeria" és una resposta excel·lent. "No hi hem pensat" no ho és.
Seguretat. Com gestioneu credencials? HTTPS en producció? Dades xifrades en repòs? Control d'accés basat en rols? La seguretat és una àrea on els inversors tenen tolerància zero — una bretxa pot destruir la reputació de l'empresa i la seva inversió.
Deute tècnic. Tota startup té deute tècnic. Els inversors ho saben. El que volen veure és que el coneixes i tens un pla. "Tenim deute tècnic significatiu al mòdul de pagaments — és al nostre backlog com a prioritat Q1" genera confiança. Pretendre que no existeix genera desconfiança.
Maduresa de CI/CD. Com arriba el codi d'un commit a producció? Tests automatitzats? Desplegament automàtic? O algú fa SSH a un servidor i copia arxius? El nivell d'automatització al teu pipeline és un proxy directe de la maduresa del teu equip.
Les red flags que maten deals
Aquests són els hallazgos que fan que els inversors es tirin enrere o redueixin significativament la seva valoració:
Sense tests automatitzats. Sense tests, no pots desplegar amb confiança i qualsevol canvi pot trencar funcionalitat existent. És un risc operatiu que afecta directament l'execució del roadmap.
Sense CI/CD. Desplegaments manuals signifiquen 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 les persones marxen — l'empresa té un risc existencial. Els inversors pregunten pel bus factor: si la resposta és "una persona", això és una red flag seriosa.
Credencials hardcodejades. Contrasenyes de base de dades, API keys, tokens d'accés directament al codi font. No només és un risc de seguretat — és un senyal que ningú a l'equip té experiència amb pràctiques bàsiques de seguretat. Si són al repositori de Git, el dany és encara major: encara que les esborris, segueixen a l'historial.
Sense monitorització. Com saps que la teva aplicació funciona? Com saps que va lenta? Com t'assabentes que un servei ha caigut? Si la resposta és "quan un usuari es queixa", l'inversor sap que estàs operant a cegues.
Dependències abandonades o vulnerables. Llibreries que no s'actualitzen des de fa anys, frameworks en versions obsoletes, dependències amb vulnerabilitats conegudes. Això indica que ningú gestiona activament la salut del projecte.
Les green flags que generen confiança
A l'altre costat de l'espectre, aquests són els indicadors que fan que un inversor se senti còmode amb la tecnologia:
Historial de Git net. Commits amb missatges descriptius, pull requests amb reviews, branches organitzats. Un historial de Git net indica processos de desenvolupament madurs i un equip que treballa amb disciplina.
Decisions d'arquitectura documentades. No necessites 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 pensament deliberat.
Eleccions tecnològiques raonables. No les més modernes. No les més populars. Les que tenen sentit per al problema. Un stack boring però apropiat (Rails, Django, Node.js + PostgreSQL) genera més confiança que un stack exòtic que requereixi enginyers especialitzats difícils de trobar.
Separació de concerns. Frontend separat del backend. Lògica de negoci separada de l'accés a dades. Configuració separada del codi. Aquests patrons bàsics d'enginyeria de programari indiquen que algú amb experiència ha pres decisions de disseny.
Desplegaments automatitzats. Un pipeline que va de commit a producció amb tests, build i deploy automàtics. Bonus si hi ha staging environment, rollback automatitzat i feature flags.
Monitorització i alertes. Dashboards que mostren la salut del sistema, alertes quan alguna cosa falla, logs centralitzats i accessibles. No necessita ser sofisticat — Datadog, Grafana, o fins i tot CloudWatch ben configurat 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 arranjaments ràpids amb el major impacte negatiu si els troben.
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 necessites 80% de coverage.
Setmana 3: Documentació mínima. Un document d'arquitectura d'una pàgina: quins serveis existeixen, com es comuniquen, quines tecnologies fan servir i per què. Documenta les tres decisions tècniques més importants.
Setmana 4: Monitorització. Uptime, temps de resposta, errors, alertes per a 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é la capacitat d'executar al següent nivell, res de l'anterior importa.
Els inversors avaluen l'equip tècnic amb una pregunta simple: poden aquestes persones escalar amb l'empresa?
Busquen diversitat d'experiència, capacitat d'articular decisions tècniques i evidència que l'equip aprèn i s'adapta. Si el teu equip té gaps evidents — falta un líder tècnic, ningú ha operat infraestructura a escala — els inversors ho veuran.
La millor estratègia no és amagar els gaps. És reconèixer-los i tenir un pla. "Necessitem un enginyer de seguretat dedicat i planejem contractar-ne un amb part dels fons d'aquesta ronda" és infinitament millor que pretendre que el teu equip de 4 generalistes cobreix totes les bases.
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 realitzades per CTOs amb experiència en avaluació de startups. Revisem el teu codi, la teva arquitectura, la teva infraestructura i els teus processos amb els mateixos criteris que farà servir l'inversor — i et donem un informe accionable amb les prioritats de correcció.
Segon, amb team augmentation estratègica. Si el teu equip té gaps que un inversor detectarà — manca de seniority, sense experiència en escalat, dependència d'un sol enginyer — podem incorporar enginyers sènior de LATAM que reforcin 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, trobi exactament el que vol trobar: un equip competent, amb decisions deliberades, que sap on són les seves debilitats i té un pla per resoldre-les.
Llevaràs una ronda i vols que el teu stack estigui preparat? Parla amb un CTO — fem l'auditoria tècnica abans que la facin els teus inversors.
