Estudi de cas: com un fundador legaltech va posar en producció una plataforma d'IA sense cofundador tècnic
El problema del fundador (no el del producte)
El fundador de Bonus Iuri coneixia a fons el mercat legal espanyol: anys d'ofici, contacte directe amb els problemes reals i una convicció clara sobre l'oportunitat de producte. Autònoms que paguen massa per revisions bàsiques de contractes. Petites empreses que signen acords que no acaben d'entendre. Advocats que treballen sols i dediquen dues hores a una anàlisi de contracte que s'hauria de poder fer en minuts.
La visió de producte era precisa: puges un contracte i reps a l'instant una avaluació de risc fonamentada en legislació espanyola real, amb un semàfor de risc i citacions d'articles concrets. No un chatbot d'IA genèric: una eina legal especialitzada en què un advocat en exercici pugui confiar.
El que el fundador no tenia: un cofundador tècnic, un equip de desenvolupament, ni la capacitat de construir-ho tot sol.
Aquest cas el conec des de dins — jo vaig ser el CTO del projecte —, així que el que segueix és la perspectiva des de la cadira d'enginyeria, no una història d'èxit explicada de segona mà.
És un dels colls d'ampolla més habituals de l'ecosistema startup. Un fundador amb expertesa del sector, visió de mercat i una idea de producte clara — bloquejat per la capacitat d'enginyeria per construir-la. El consell convencional: dedicar de tres a sis mesos a buscar un cofundador tècnic, cedir entre el 30% i el 50% de l'empresa i confiar que la relació sobrevisqui la pressió de construir un producte junts.
El fundador va triar un altre camí.
La decisió: soci d'enginyeria en lloc de cofundador tècnic
En comptes de buscar un cofundador — un procés que s'hauria menjat mesos i hauria afegit una dilució d'equity considerable i un risc relacional gens menor — el fundador va incorporar Conectia com a soci d'enginyeria liderat per un CTO.
El model de col·laboració era molt concret:
Lideratge tècnic de nivell CTO. No un project manager que tradueix requisits a tiquets de Jira: un CTO que havia construït diversos productes d'IA, capaç d'avaluar compromisos d'arquitectura, de prendre decisions tecnològiques pel seu compte i de plantar cara quan la visió del fundador necessitava una base tècnica.
Un equip petit i sènior. Dos enginyers: el CTO, responsable de l'arquitectura i del motor de raonament d'IA, i un enginyer full-stack sènior per a la plataforma, els pagaments i el desplegament. Cap desenvolupador júnior. Cap corba d'aprenentatge.
Col·laboració directa. Stand-ups diaris, repositori compartit, Slack obert. L'equip d'enginyeria funcionava com una extensió de la visió del fundador, no com un proveïdor extern que lliura contra un plec d'especificacions.
Zero dilució d'equity. Un servei mensual. El fundador va conservar la propietat íntegra del producte, del codi i de l'empresa. El cost d'enginyeria era una despesa operativa, no una dilució permanent del cap table.
Què hi va posar el fundador
Aquest model funciona perquè el fundador hi va posar allò que només un expert del sector pot posar-hi — i no va pretendre posar-hi el que no li tocava.
Coneixement del mercat. El fundador sabia quins tipus de contracte calia prioritzar. Dels nou, no tots valien igual: els contractes laborals i els de lloguer concentraven el volum més alt i el problema més evident. Aquesta priorització va marcar l'ordre de la feina d'enginyeria.
Lògica del domini legal. Les llistes de verificació de dotze punts per a cada tipus de contracte — quins articles de llei revisar, quins llindars de risc aplicar, quins patrons de clàusula delaten problemes — sortien de l'expertesa legal del fundador. Un equip d'enginyeria sense aquest coneixement hauria construït una detecció de riscos genèrica. El criteri del fundador va fer que l'anàlisi fos prou específica per ser útil de debò.
Direcció de producte. El model freemium (puntuació de risc gratuïta amb tres punts de la checklist, informe complet premium a 14,90 €) va ser una decisió de producte basada en la sensibilitat al preu del mercat objectiu, que el fundador coneixia bé. El preu no sortia de cap playbook de SaaS: reflectia el que autònoms i petites empreses d'Espanya estaven disposats a pagar de veritat.
Context de negoci. El termini de sis setmanes, lligat a un congrés del sector jurídic, no era arbitrari: era una decisió de timing de mercat. El fundador coneixia el públic, l'escenari i l'oportunitat de mostrar el producte a usuaris i socis potencials. Aquest context de negoci va dictar el calendari d'enginyeria.
De què es va ocupar l'equip d'enginyeria
De tot el que el fundador no podia fer — i que tampoc no hauria hagut d'intentar:
Decisions d'arquitectura. Com estructurar el pipeline d'IA per a nou tipus de contracte. Com implementar un RAG conscient de la legislació, que fragmenta els documents legals pels límits d'article i no per finestres fixes de tokens. Com dirigir cada tasca d'anàlisi al model LLM adequat segons la profunditat de raonament i el cost. Com integrar l'aïllament de dades del RGPD a la capa d'emmagatzematge des del principi, en lloc d'apedaçar-ho després.
Són decisions que demanen anys d'experiència en enginyeria d'IA. Un fundador que les hagués d'aprendre pel camí hauria comès errors cars — dels que afloren sis mesos més tard en forma de colls d'ampolla d'escalat, vulnerabilitats de seguretat o forats de compliment normatiu.
Arquitectura de compliment. RGPD, Reglament europeu d'IA, LOPDGDD, requisits deontològics del CCBE. El fundador sabia que aquestes normes existien i que complir-les no era negociable. L'equip d'enginyeria sabia com implementar-les: aïllament de dades per usuari a S3, supressió en cascada per al dret a l'oblit, distintius de transparència d'IA i classificació de risc segons el marc del Reglament europeu d'IA.
La distinció és important. El fundador va fixar els requisits de compliment. Els enginyers van resoldre l'enginyeria del compliment.
Selecció de tecnologia. React 18 amb TypeScript al frontend. FastAPI al backend. PostgreSQL per a la persistència. Amazon Bedrock per accedir als LLM amb encaminament multimodel. Stripe per als pagaments. Infraestructura AWS sobre ARM64 per eficiència de costos. GitLab CI/CD per automatitzar els desplegaments.
Un fundador no tècnic que volgués prendre aquestes decisions s'hauria passat setmanes investigant, o s'hauria refiat del que li recomanés un desenvolupador freelance — que pot acabar optimitzant per les seves preferències i no per les necessitats del producte.
Operacions de producció. Certificats TLS, configuració del CDN, monitoratge, gestió d'errors, migracions de base de dades, pipelines de desplegament. La infraestructura invisible que separa una demo d'un producte. Un fundador no tècnic no pot avaluar si tot això està ben fet. Amb un equip liderat per un CTO, no li cal.
El resultat: en producció, amb ingressos i conforme en sis setmanes
Llançament a temps. Bonus Iuri era en marxa per al congrés del sector jurídic, sis setmanes després del tret de sortida. Usuaris reals podien pujar contractes, rebre avaluacions de risc generades per IA i comprar informes premium via Stripe.
Ingressos des del primer dia. El model freemium va convertir usuaris des del començament. Les puntuacions de risc gratuïtes generaven tracció; els informes premium a 14,90 € i els plans professionals a 490,90 €/any generaven ingressos sense necessitat d'equip comercial.
Conforme des del primer dia. Res de «ja ho arreglarem més endavant». L'aïllament de dades del RGPD, la transparència del Reglament europeu d'IA i els avisos deontològics del CCBE eren característiques d'arquitectura el dia del llançament. I això importava: el mercat objectiu del fundador — professionals del dret — té tolerància zero amb les eines que no compleixen.
Propietat íntegra de la PI. El fundador és l'amo de l'empresa, del codi, de la marca i de la relació amb els clients. Cap repartiment d'equity amb un cofundador. Cap dilució d'inversors (el llançament inicial no va requerir finançament). La col·laboració d'enginyeria va ser un cost de servei: significatiu, però finit i controlat.
Independència operativa. La plataforma corre sobre una infraestructura que el fundador pot entendre a nivell de negoci (costos d'AWS, ingressos de Stripe, mètriques d'ús) sense haver d'entendre-la a nivell tècnic. Quan necessita canvis o funcionalitats noves, la relació d'enginyeria continua. Quan no, els costos s'aturen.
Els números: cofundador vs. soci d'enginyeria
Val la pena posar els dos camins l'un al costat de l'altre:
| Factor | Cofundador tècnic | Soci d'enginyeria (Conectia) |
|---|---|---|
| Temps fins a començar a construir | 3–6 mesos (cerca + encaix) | 1 setmana (descoberta + desplegament de l'equip) |
| Cost en equity | 30–50% de l'empresa | 0% |
| Cost mensual en efectiu | 0 $ (compensat amb equity) | 12.000–20.000 $ |
| Control de qualitat tècnica | Depèn de la persona | Metodologia validada per un CTO |
| Flexibilitat d'escalat | Fixa (una persona) | Variable (afegir o treure enginyers) |
| Risc relacional | Alt (les ruptures entre cofundadors són freqüents) | Baix (contracte de servei, preavís de 30 dies) |
| Temps fins a producció | 4–8 mesos (si el cofundador va ràpid) | 6 setmanes (lliurament demostrat) |
| Opcions post-llançament | El cofundador és permanent | Transició a un CTO intern quan toqui |
El model de cofundador no és cap error: és l'opció correcta per a certs fundadors i certes etapes. Però per a un expert del sector que ha de validar un producte dins d'una finestra de mercat concreta, el model de soci d'enginyeria elimina els riscos més grossos: el temps, l'equity i la dependència d'una única relació tècnica.
El patró: quan funciona millor aquest model
Bonus Iuri il·lustra un patró que veiem una vegada i una altra:
Experts del sector amb recorregut — no emprenedors novells explorant idees, sinó gent amb un coneixement profund d'un mercat concret i una tesi de producte clara.
Mercats regulats — legal, salut, finances, assegurances — on el compliment no es pot ajornar i on l'expertesa del sector és el diferencial principal, no la tecnologia.
Productes basats en IA — on el valor ve d'aplicar la IA a un problema concret del sector, i on el repte d'enginyeria és construir un sistema d'IA fiable i conforme, no inventar capacitats d'IA noves.
Finestres de mercat estretes — llançaments lligats a congressos, terminis regulatoris, timing competitiu — on els tres a sis mesos de cerca de cofundador o les vuit a dotze setmanes de la contractació tradicional senzillament no hi caben.
El fil conductor: l'avantatge del fundador és al sector, no a la tecnologia. La tecnologia ha de ser excel·lent — però ha de servir l'expertesa del sector, no substituir-la.
El que ve després: l'enginyeria escala amb el producte
El fundador de Bonus Iuri opera avui un SaaS en producció amb usuaris de pagament, una arquitectura conforme i un full de ruta clar per créixer: més tipus de contracte, més jurisdiccions (dret de la UE, dret portuguès), una API professional per a despatxos d'advocats i integracions amb els sistemes de gestió dels bufets.
La relació d'enginyeria escala amb el producte. Quan cal un sprint de funcionalitats noves, l'equip s'hi posa. Quan el producte és estable i el fundador se centra en el negoci, l'equip es redueix. I quan arribi el moment de contractar un CTO intern — probablement a la sèrie A — l'equip de Conectia facilitarà la transició amb la documentació d'arquitectura completa, una repassada guiada del codi i suport durant l'onboarding.
El fundador no necessitava un cofundador tècnic. Necessitava un soci d'enginyeria capaç de convertir l'expertesa del sector en un producte en producció, amb un calendari a l'alçada de l'oportunitat de mercat.
Tens l'expertesa del sector i una visió de producte clara, però et falta l'equip tècnic? Parla amb un CTO per anar del concepte a producció sense haver de buscar cofundador.
