Vodič za direktore i investitore: Kako proceniti tehnologiju u akviziciji SaaS biznisa i ne kupiti „mačku u džaku“

Kupovina SaaS (Software as a Service) biznisa je kao kupovina superautomobila. Na prvi pogled, sve može izgledati savršeno. Blistava karoserija u vidu impresivnog mesečnog ponavljajućeg prihoda (MRR), uglađen enterijer u formi dobrog korisničkog interfejsa (UI), i prodavac koji vas uverava u neverovatne performanse. Ali, da li ste ikada podigli haubu?

Šta ako se ispod te sjajne haube krije motor koji je sklepan od delova sa otpada, koji curi na sve strane i preti da eksplodira pri prvom pokušaju da pritisnete gas do daske?

U svetu SaaS akvizicija, „motor“ je tehnologija. Ona je srce, duša i centralni nervni sistem celokupnog poslovanja. Zanemariti dubinsku analizu tehnologije – poznatu kao tehnički due diligence – nije samo propust; to je recept za katastrofu. To je kockanje sa milionima, gde je ulog vaša celokupna investicija.

Ovaj tekst nije samo lista tehničkih termina. Ovo je vaš strateški vodič. Namenjen je osnivačima koji žele da kupe drugi biznis, direktorima zaduženim za rast, investicionim menadžerima i svima onima koji stoje pred velikom odlukom o akviziciji. Proći ćemo kroz ključne aspekte procene tehnologije, korak po korak, na način koji je razumljiv čak i ako niste programer. Jer na kraju dana, tehnološke odluke su poslovne odluke.

Zato se udobno smestite. Krećemo u detaljnu inspekciju motora.

Zašto je tehnički Due Diligence važniji nego ikad?

U zlatnoj groznici SaaS tržišta, gde se akvizicije dešavaju svakodnevno, lako je postati opijen brojevima. ARR (godišnji ponavljajući prihod), LTV (životna vrednost korisnika), CAC (trošak akvizicije korisnika)… Ovo su metrike koje dominiraju pregovorima. I dok su one apsolutno ključne, one prikazuju samo trenutno stanje, fotografiju poslovanja.

Tehnologija, s druge strane, priča priču o budućnosti. Ona određuje da li će taj ARR moći da se udvostruči, utrostruči ili će se srušiti pod teretom sopstvenog uspeha.

Zamislite sledeće scenarije:

• Scenario A: Kupujete SaaS platformu sa 10.000 korisnika i stabilnim prihodom. Vaš plan je da investirate u marketing i za 18 meseci dostignete 100.000 korisnika. Ali, niste znali da je arhitektura sistema monolitna, krhka i da jedva izdržava trenutni teret. Prva uspešna marketinška kampanja dovodi do pada sistema. Korisnici su besni, reputacija je uništena, a vi ste sada vlasnik digitalne ruševine koja zahteva kompletnu i preskupu rekonstrukciju.
• Scenario B: Akvizicija prolazi glatko. Šest meseci kasnije, otkrivate da je ključni deo koda zapravo „pozajmljen“ sa open-source projekta sa restriktivnom licencom koja zabranjuje komercijalnu upotrebu. Sada ste suočeni sa tužbom za povredu intelektualne svojine.
• Scenario C: Preuzimate kompaniju i njen mali, ali naizgled efikasan tim programera. Ubrzo shvatate da je celokupno znanje o sistemu bilo u glavi jednog „heroja programera“ koji je upravo dao otkaz. Dokumentacija ne postoji, kod je haotičan, i niko ne zna kako da popravi kritičan bag koji se upravo pojavio.

Ovo nisu izmišljene horor priče. Ovo su realne posledice preskakanja ili površnog obavljanja tehničkog due diligence-a. Cilj ovog procesa nije da se pronađe savršen softver – jer on ne postoji. Cilj je da se identifikuju, razumeju i kvantifikuju rizici. Da se dobije realna slika onoga što kupujete i da se proceni stvarna cena posedovanja i razvoja te tehnologije u budućnosti.

Sada kada razumemo zašto, hajde da vidimo kako. Podelićemo proces u sedam ključnih stubova.

Stub 1: Arhitektura i Skalabilnost – Temelj vaše buduće imperije

Ako je tehnologija motor, arhitektura je njegova osnovna konstrukcija i šasija. Ona određuje kako su komponente sistema organizovane i kako komuniciraju. Od arhitekture direktno zavisi najvažnije pitanje za svaki rastući biznis: skalabilnost.

Skalabilnost je sposobnost sistema da efikasno podnese povećanje opterećenja. Ne radi se samo o tome da li sajt može da podnese više korisnika istovremeno. Radi se o tome kako sistem raste. Da li dodavanje novih funkcionalnosti traje nedeljama ili mesecima? Da li troškovi servera rastu linearno ili eksponencijalno sa brojem korisnika?

Šta treba da istražite?

1. Tip arhitekture (Monolit vs. Mikroservisi vs. Serverless):
   • Monolit: Zamislite ga kao jednu veliku zgradu u kojoj su sve funkcije (naplata, korisnički profili, analitika) isprepletane. Monoliti su često brži za razvoj u početku, ali postaju noćna mora za održavanje i skaliranje kako rastu. Promena na jednom malom delu može zahtevati testiranje i implementaciju cele aplikacije.
   • Mikroservisi: Zamislite ih kao poslovni park sa više manjih, specijalizovanih zgrada (servisa). Svaki servis (npr. servis za plaćanje) je nezavisan, može se razvijati i skalirati odvojeno. Ovo je moderniji pristup, fleksibilniji, ali i kompleksniji za upravljanje.
   • Serverless: Još apstraktniji nivo, gde se ne brinete o serverima, već samo o funkcijama koje se izvršavaju na zahtev. Idealno za određene tipove poslova, veoma isplativo, ali nosi rizik vezivanja za jednog cloud provajdera (npr. AWS Lambda).

   Pitanja za prodavca:

   • Možete li mi nacrtati dijagram arhitekture sistema?
   • Zašto ste se odlučili za ovaj arhitektonski pristup?
   • Kako dodajete nove velike funkcionalnosti u sistem? Opišite mi proces.
2. Infrastruktura i Hosting:
   • Gde se aplikacija „vrti“? Da li je na nekom od velikih cloud provajdera (AWS, Google Cloud, Azure) ili na sopstvenim serverima u nekom data centru (On-premise)?
   • Cloud je skoro uvek bolja opcija zbog fleksibilnosti i skalabilnosti. On-premise infrastruktura može biti ogroman, skriven trošak i rizik.
   • Da li koriste tehnologije poput Dockera i Kubernetesa za kontejnerizaciju? Ovo je veliki plus jer olakšava upravljanje i prenosivost aplikacije.

   Pitanja za prodavca:

   • Koji hosting provajder koristite i zašto?
   • Pokažite mi mesečne račune za hosting za poslednjih 12 meseci. Kako su se troškovi kretali sa rastom broja korisnika?
   • Kako izgleda proces deploymenta (postavljanja nove verzije koda)? Da li je automatizovan?
3. Performanse pod opterećenjem:
   • Teorija je jedno, praksa drugo. Kako se sistem zaista ponaša kada ga „nagazite“?
   • Tražite izveštaje sa alata za praćenje performansi (npr. New Relic, Datadog). Gledajte vreme odziva servera, broj grešaka, iskorišćenost procesora i memorije.
   • Idealno bi bilo sprovesti „load testing“ – simulaciju velikog broja korisnika kako bi se videle tačke pucanja.

   Primer iz prakse: Jedna kompanija je kupila SaaS za e-trgovinu koji je radio savršeno u normalnim uslovima. Nisu uradili load testing. Prvi Crni petak nakon akvizicije, sajt je pao pod teretom posetilaca. Gubici su bili milionski, ne samo u prodaji tog dana, već i u dugoročnom poverenju korisnika. Dublja analiza bi pokazala da je baza podataka bila usko grlo koje nije moglo da podnese više od 500 upita u sekundi.

Crvene zastave 🚩:

• Nejasni ili nepostojeći dijagrami arhitekture.
• Odgovor „nikada nismo imali problema sa performansama“ bez konkretnih podataka.
• Visok i nepredvidiv rast troškova hostinga.
• Zavisnost od zastarele on-premise infrastrukture.
• Kompleksan, ručni proces deploymenta koji traje satima ili danima.

Stub 2: Tehnološki Stek (Tech Stack) – Gradivni materijal

Ako je arhitektura nacrt zgrade, tehnološki stek su materijali od kojih je ona sazidana: cigle, beton, drvo, staklo. Tehnološki stek obuhvata sve programske jezike, frejmvorke, baze podataka i alate koji se koriste za izgradnju i funkcionisanje softvera.

Izbor steka nije pitanje mode. On utiče na sve: brzinu razvoja, bezbednost, performanse, i što je možda najvažnije – mogućnost pronalaženja i zapošljavanja programera.

Šta treba da istražite?

1. Jezici i Frejmvorkovi (Backend i Frontend):
   • Backend (ono što se dešava na serveru): Da li koriste moderne, dobro podržane jezike kao što su Python (sa Django/Flask), JavaScript (Node.js), Ruby (on Rails), PHP (sa Laravel/Symfony), Java (sa Spring), Go? Ili se oslanjaju na nešto egzotično ili zastarelo poput ColdFusion-a ili starog ASP-a?
   • Frontend (ono što vidite u browseru): Da li koriste moderne JavaScript frejmvorke kao što su React, Angular ili Vue.js? Ili je sve urađeno u „vanilla“ JavaScript-u i jQuery-ju, što može biti teško za održavanje na kompleksnim aplikacijama?

   Zašto je ovo važno? Korišćenje zastarelih tehnologija je kao gradnja kuće od azbesta. Možda je nekada bilo popularno, ali danas je opasno i skupo za zamenu. Takođe, biće vam skoro nemoguće da nađete programere koji žele (ili znaju) da rade sa tim tehnologijama.

2. Baza podataka:
   • Da li je u pitanju relacion a baza (npr. PostgreSQL, MySQL) ili NoSQL baza (npr. MongoDB, DynamoDB)? Izbor zavisi od prirode podataka, ali važno je da je taj izbor bio nameran i opravdan.
   • PostgreSQL se generalno smatra robusnijim i pouzdanijim izborom za većinu SaaS aplikacija.
   • Proverite verziju baze podataka. Stara verzija može imati bezbednosne propuste i nedostatak modernih funkcionalnosti.
3. Zavisnosti (Dependencies) i Open Source komponente:
   • Nijedan moderan softver se ne piše od nule. Svi koriste eksterne „biblioteke“ ili pakete (dependencies) za obavljanje standardnih zadataka.
   • Potrebno je skenirati projekat alatima poput npm audit (za Node.js) ili Snyk-a kako bi se proverilo:
     • Stanje ažuriranosti: Da li su paketi redovno ažurirani? Stari paketi su primarna meta hakera.
     • Licence: Da li se koriste open-source komponente sa odgovarajućim licencama? Korišćenje paketa sa restriktivnom licencom (npr. GPL) može vas zakonski obavezati da ceo vaš kod učinite javnim. Ovo je „tempirana bomba“ za intelektualnu svojinu.

Pitanja za prodavca:

• Dajte mi kompletnu listu tehnologija koje čine vaš stek.
• Koliko često ažurirate ključne frejmvorke i biblioteke? Kakav je vaš proces za to?
• Da li ste radili analizu licenci open-source komponenti koje koristite?

Crvene zastave 🚩:

• Korišćenje tehnologija koje su „end-of-life“ (više nemaju podršku proizvođača).
• Veliki broj kritičnih bezbednosnih upozorenja nakon skeniranja zavisnosti.
• Nepostojanje jasnog odgovora o licenciranju.
• „Egzotičan“ stek za koji je teško naći programere.
• Korišćenje veoma starih verzija popularnih frejmvorka (npr. Angular 1, Laravel 4).

Stub 3: Kvalitet Koda i Tehnički Dug – Inspekcija instalacija

Ušli ste u zgradu. Izgleda dobro. Ali šta se krije iza zidova? Kakve su električne i vodovodne instalacije? Kvalitet koda je upravo to. Može biti čist, organizovan i dokumentovan, ili haotičan, isprepletan i nerazumljiv – poznat kao „špageti kod“.

Tehnički dug je metafora za sve svesne ili nesvesne kompromise u kodu, napravljene zarad brzine. To je kao da uzmete brzi kredit sa visokom kamatom. Kratkoročno rešavate problem, ali dugoročno vas kamata (usporen razvoj, bagovi, poteškoće u održavanju) uništava. Svaki softver ima neki tehnički dug. Vaš zadatak je da procenite koliki je i da li je kamata podnošljiva.

Kako proceniti nešto tako apstraktno?

1. Pregled Koda (Code Review):
   • Ovo je najdirektniji način. Potreban vam je iskusan programer (vaš interni ili unajmljeni konsultant) koji će „zaroniti“ u kod. Ne morate pregledati sve. Dovoljno je uzeti uzorak ključnih, najkompleksnijih delova aplikacije.
   • Šta se traži?
     • Čitljivost i konzistentnost: Da li kod prati određene standarde i stil? Da li je lako razumeti šta radi bez dodatnih objašnjenja?
     • Jednostavnost (KISS – Keep It Simple, Stupid): Da li su rešenja prekomplikovana bez potrebe?
     • Ponavljanje (DRY – Don’t Repeat Yourself): Da li se isti blokovi koda kopiraju na više mesta, umesto da budu izdvojeni u funkcije koje se mogu ponovo koristiti?
     • Komentari: Da li postoje komentari u kodu? Ali oprez! Dobar kod je sam po sebi dokumentacija. Previše komentara može značiti da je kod nerazumljiv. Nedostatak komentara za kompleksne algoritme je takođe loš znak.
2. Automatizovano testiranje (Automated Testing):
   • Ovo je pokazatelj zrelosti i profesionalizma razvojnog tima. Testovi su vaša sigurnosna mreža. Oni automatski proveravaju da li nova promena nije pokvarila nešto staro.
   • Vrste testova:
     • Unit testovi: Testiraju najmanje delove koda (pojedinačne funkcije).
     • Integracioni testovi: Testiraju kako više delova sistema radi zajedno.
     • End-to-End (E2E) testovi: Simuliraju kompletan korisnički scenario (npr. od logovanja do plaćanja).
   • Pokrivenost koda testovima (Test Coverage): Koliki procenat koda je pokriven testovima? Alat će vam dati broj (npr. 80%), ali ne treba slepo verovati metrici. Važnije je da su ključni, poslovno kritični delovi sistema dobro pokriveni. Pokrivenost od 20% je jasan znak upozorenja.
3. Istorija grešaka (Bug History):
   • Tražite pristup njihovom sistemu za praćenje zadataka (npr. Jira, Trello, Asana).
   • Analizirajte istoriju prijavljenih grešaka (bagova).
   • Koliko brzo se rešavaju kritični bagovi? Koliko dugo bagovi stoje otvoreni? Da li se isti bagovi stalno vraćaju (regresije)? Ovo poslednje je siguran znak niskog kvaliteta i nedostatka testova.

Primer tehničkog duga: Tim je, da bi stigao na tržište, „hardkodovao“ poreske stope direktno u kod, umesto da napravi fleksibilan sistem za upravljanje porezima. Sada, kada treba da uđu na tržište druge zemlje sa drugačijom poreskom stopom, suočavaju se sa mesecom dana posla prepravljanja stotina fajlova, umesto da samo dodaju novi red u bazu podataka. To je „kamata“ na tehnički dug koju sada morate da platite.

Crvene zastave 🚩:

• Kod koji je nemoguće čitati i razumeti.
• Potpuno odsustvo automatskih testova ili veoma niska pokrivenost.
• Česte regresije (stari bagovi se ponovo pojavljuju).
• Programeri se žale da se plaše da diraju određene delove koda jer „sve može da pukne“.
• Ne postoji sistem za praćenje bagova, ili je on haotičan.

Stub 4: Procesi Razvoja i DevOps – Fabrika softvera

Imati dobar nacrt, materijale i majstore nije dovoljno ako je vaša fabrika neorganizovana. Procesi razvoja i DevOps (Development Operations) predstavljaju proizvodnu traku. Oni određuju koliko brzo, efikasno i pouzdano možete pretvoriti ideju u funkcionalnost koja je dostupna korisnicima.

Loši procesi dovode do sporog razvoja, čestih grešaka u produkciji i frustriranih timova.

Šta treba da istražite?

1. Metodologija razvoja (Agile, Scrum, Kanban…):
   • Kako tim organizuje svoj rad? Da li prate neku od agilnih metodologija?
   • Scrum: Rad u fiksnim iteracijama (sprintovima), obično 2 nedelje, sa jasnim planiranjem i retrospektivom.
   • Kanban: Fokus na kontinualnom protoku zadataka, bez fiksnih sprintova.
   • Nije bitno koju metodologiju koriste, već da li je primenjuju dosledno i da li ona donosi rezultate. Haotičan proces bez ikakve strukture je opasan.
2. Upravljanje izvornim kodom (Source Control):
   • Da li koriste Git? Danas je sve osim Gita praktično nezamislivo.
   • Kako izgleda njihov proces grananja (branching strategy)? Da li koriste nešto poput GitFlow-a?
   • Da li se „code review“ radi za svaku promenu pre nego što ona uđe u glavnu granu koda? Ovo je ključna praksa za održavanje kvaliteta.
3. CI/CD (Continuous Integration / Continuous Deployment):
   • Ovo je sveti gral modernog DevOps-a.
   • Continuous Integration (CI): Svaki put kada programer pošalje novu promenu, automatski sistem (npr. Jenkins, GitLab CI, GitHub Actions) preuzme kod, pokrene sve testove i proveri da li je sve ispravno.
   • Continuous Deployment/Delivery (CD): Ako CI prođe uspešno, sistem automatski postavlja novu verziju na servere (staging ili čak produkciju).
   • Dobar CI/CD pipeline znači brži, pouzdaniji i manje stresan proces isporuke softvera. Ako je njihov proces „programer se uloguje na server preko FTP-a i prekopira fajlove“, bežite glavom bez obzira.
4. Monitoring i Alerting:
   • Kako znaju da sistem radi ispravno? Kako prvi saznaju za problem, pre nego što korisnici počnu da se žale?
   • Moraju imati alate za praćenje (monitoring) performansi aplikacije, iskorišćenosti servera, broja grešaka…
   • Moraju imati sistem za uzbunjivanje (alerting) koji automatski obaveštava tim (npr. preko Slacka ili PagerDuty-ja) kada neka metrika pređe kritičnu vrednost.

Pitanja za prodavca:

• Opišite mi put jedne ideje od koncepta do produkcije. Koliko to obično traje za manju promenu?
• Pokažite mi vaš CI/CD pipeline. Šta se sve automatski dešava kada se kod spoji sa glavnom granom?
• Koji alat za monitoring koristite? Pokažite mi dashboard. Koje alarme imate podešene?

Crvene zastave 🚩:

• Deployment se radi ručno, noću ili vikendom „za svaki slučaj“.
• Ne postoji praksa „code review“-a.
• Često se dešava da deployment nove verzije obori sajt.
• Za probleme saznaju od korisnika na Twitteru.
• Razvojni tim se protivi implementaciji CI/CD-a jer je „previše komplikovano“.

Stub 5: Bezbednost i Usklađenost (Compliance) – Tvrđava i njeni zakoni

Bezbednost nije samo jedna funkcionalnost; to je način razmišljanja koji mora biti utkan u svaki deo sistema i procesa. Jedan jedini bezbednosni propust može uništiti reputaciju i poslovanje koje je godinama građeno.

Pored opšte bezbednosti, tu je i usklađenost sa regulativama, koja je posebno važna ako poslujete u određenim industrijama ili regionima (npr. GDPR u Evropi, HIPAA u zdravstvu).

Šta treba da istražite?

1. Upravljanje osetljivim podacima:
   • Kako čuvaju lozinke korisnika? (Tačan odgovor: heširane sa jedinstvenim „saltom“ koristeći moderne algoritme poput Bcrypt ili Argon2. Ako kažu „enkriptovane“ ili, ne daj Bože, „plain text“, to je katastrofa).
   • Kako čuvaju druge osetljive podatke (lični podaci, podaci o plaćanju)? Da li su enkriptovani „u mirovanju“ (na disku) i „u tranzitu“ (preko interneta)?
   • Da li imaju implementiranu kontrolu pristupa (Role-Based Access Control – RBAC)? Da li zaposleni imaju pristup samo onim podacima koji su im neophodni za rad?
2. Uobičajeni vektori napada (OWASP Top 10):
   • OWASP Top 10 je lista najčešćih bezbednosnih rizika za web aplikacije. Ne morate biti haker da biste razumeli osnove.
   • Pitajte tim kako se štite od napada kao što su:
     • SQL Injection: Mogućnost da napadač preko polja za unos izvrši maliciozne komande nad bazom podataka.
     • Cross-Site Scripting (XSS): Mogućnost da napadač ubaci maliciozni skript u sajt koji se izvršava u browserima drugih korisnika.
     • Broken Access Control: Mogućnost da korisnik pristupi podacima kojima ne bi smeo da ima pristup.
3. Bezbednosne provere i procedure:
   • Da li su ikada radili eksterno testiranje na prodor (penetration testing)? Ako jesu, tražite da vidite izveštaj i dokaz da su svi pronađeni propusti ispravljeni.
   • Da li koriste alate za statičku analizu bezbednosti koda (SAST) koji automatski skeniraju kod u potrazi za poznatim propustima?
   • Kakva je procedura u slučaju bezbednosnog incidenta? Da li imaju plan?
4. Usklađenost (Compliance):
   • Ako posluju u Evropi, da li su usklađeni sa GDPR-om? To podrazumeva pravo korisnika na pristup i brisanje podataka, politiku privatnosti, itd.
   • Ako obrađuju platne kartice, da li su usklađeni sa PCI DSS standardom? Često se ovo rešava korišćenjem eksternih procesora plaćanja kao što su Stripe ili Braintree, što je dobra praksa.

Crvene zastave 🚩:

• Čuvanje lozinki u nebezbednom formatu.
• Nikada nisu radili penetration test.
• Nepostojanje jasnog plana za reagovanje u slučaju incidenta.
• Programeri nisu upoznati sa osnovnim bezbednosnim praksama (OWASP).
• Ignorisanje zahteva regulativa poput GDPR-a.

Stub 6: Tim i Kultura – Ljudi iza mašine

Možete kupiti najbolji kod na svetu, ali ako kupujete tim koji je toksičan, nemotivisan ili pred otkazom, kupili ste problem. Tehnologija je živa stvar koju održavaju i razvijaju ljudi. Tim koji preuzimate je često vredniji od samog koda.

Šta treba da istražite?

1. Struktura i uloge tima:
   • Ko su ključni ljudi? Ko je tehnički lider (Tech Lead/CTO)? Ko su senior, a ko junior programeri?
   • Da li postoji „bus faktor“? Koliko ljudi treba da udari autobus da bi projekat stao? Ako je odgovor „jedan“, imate ogroman rizik. Znanje mora biti distribuirano.
   • Da li je tim kompletan? Ili im hronično nedostaju određene uloge (npr. QA inženjer, DevOps inženjer)?
2. Kvalitet i motivacija tima:
   • Ovo je teško izmeriti, ali je ključno. Potrebno je obaviti razgovore sa ključnim članovima tima (bez prisustva njihovih menadžera).
   • Pitajte ih o izazovima sa kojima se suočavaju, na šta su ponosni, šta bi promenili u tehnologiji ili procesima.
   • Pokušajte da osetite njihovu energiju. Da li su strastveni oko proizvoda ili samo „odrađuju“ posao? Da li planiraju da ostanu nakon akvizicije?
3. Kultura deljenja znanja:
   • Kako se novi članovi tima uvode u posao (onboarding)?
   • Da li postoji interna dokumentacija? Da li se redovno ažurira?
   • Da li se praktikuju „code reviews“ i „pair programming“ kao način deljenja znanja?
   • Kultura u kojoj se znanje čuva kao tajna je toksična i opasna.

Primer iz prakse: Investiciona firma je kupila SaaS kompaniju sa naizgled sjajnom tehnologijom. Propustili su da primete da je ceo tim bio „pregoreo“ zbog godina lošeg menadžmenta i nerealnih rokova. U roku od tri meseca nakon akvizicije, 80% originalnog tima je dalo otkaz, odnoseći sa sobom svo institucionalno znanje. Novi vlasnici su morali da potroše skoro godinu dana i ogroman novac da bi oformili novi tim i osposobili ga za rad.

Crvene zastave 🚩:

• Visok „bus faktor“ (zavisnost od jedne ili dve osobe).
• Visoka stopa odlazaka (turnover) programera u poslednjih godinu dana.
• Tim se žali na tehnički dug, loše procese i nedostatak podrške menadžmenta.
• Nepostojanje volje za deljenjem znanja i dokumentovanjem.
• Ključni članovi tima izražavaju jasnu nameru da odu nakon akvizicije.

Stub 7: Dokumentacija i Intelektualna Svojina (IP) – Papiri o vlasništvu

Kupili ste kuću, ali da li ste proverili u katastru da li je prodavac zaista vlasnik? Intelektualna svojina je vlasnički list vašeg SaaS biznisa. Dokumentacija je uputstvo za upotrebu. Oboje su kritični.

Šta treba da istražite?

1. Vlasništvo nad kodom:
   • Da li je sav kod napisan od strane zaposlenih u okviru njihovih ugovora o radu?
   • Ako su korišćeni frilenseri ili eksterne agencije, da li postoje ugovori u kojima se jasno navodi da sva intelektualna svojina pripada kompaniji koju kupujete? Ovo je čest propust.
   • Kao što je pomenuto, proverite licence svih open-source komponenti.
2. Kvalitet dokumentacije:
   • Tehnička dokumentacija: Postoji li dokumentacija o arhitekturi, uputstva za podešavanje razvojnog okruženja, API dokumentacija za integracije?
   • Procesna dokumentacija: Da li su opisani ključni procesi poput deploymenta, procedure u slučaju incidenta, onboardinga?
   • Dobra dokumentacija drastično smanjuje vreme potrebno za uhodavanje vašeg ili novog tima. Njeno odsustvo je ogroman skriveni trošak.
3. Upravljanje znanjem:
   • Gde se čuva sva ova dokumentacija? Da li je to centralizovano mesto (npr. Confluence, Notion, interni Wiki) ili je razbacana po Google Drive folderima i individualnim računarima?

Crvene zastave 🚩:

• Nejasni ugovori sa frilenserima ili njihovo odsustvo.
• Korišćenje open-source koda sa restriktivnim (Copyleft) licencama.
• Odgovor „sva dokumentacija je u glavama naših programera“.
• Zastarela ili nepostojeća API dokumentacija.

Sinteza: Kreiranje izveštaja i donošenje odluke

Nakon što ste prošli kroz svih sedam stubova, vreme je da sve to saberete u jasan i konkretan izveštaj o tehničkom due diligence-u. Ovaj izveštaj ne treba da bude samo gomila tehničkih podataka. On mora da prevede tehničke nalaze na jezik biznisa.

Za svaki od stubova, dajte ocenu (npr. od 1 do 5, ili semafor sistem: zeleno, žuto, crveno) i sažetak ključnih nalaza, rizika i preporuka.

Izveštaj treba da odgovori na ključna pitanja:

1. Koji su najveći tehnički rizici? (npr. Skalabilnost, Bezbednost, Zavisnost od ključnih ljudi)
2. Koliki je procenjeni trošak „popravke“? (npr. „Procenjujemo da će refaktorisanje monolitne arhitekture u mikroservise trajati 12 meseci i zahtevati tim od 5 inženjera, što je trošak od X EUR.“ ili „Migracija sa zastarelog frejmvorka će koštati Y EUR.“)
3. Da li tehnologija podržava našu investicionu tezu i plan rasta? (Ako je vaš plan brza ekspanzija, a arhitektura to ne može da podnese, odgovor je „ne“.)
4. Da li identifikovani rizici mogu biti osnova za pregovaranje o nižoj ceni? (Apsolutno. Kvantifikovani tehnički dug je legitiman razlog za smanjenje valuacije.)

Konačna odluka nije crno-bela. Možda ćete otkriti značajan tehnički dug, ali ako je cena dovoljno niska i ako imate tim i plan da ga sanirate, to i dalje može biti odlična investicija. Možda je tehnologija prosečna, ali je tim koji stoji iza nje apsolutno izvanredan.

S druge strane, ako otkrijete fundamentalne, strukturne probleme u arhitekturi, ozbiljne bezbednosne propuste i toksičan tim, to su znaci da treba da odustanete od akvizicije, bez obzira na to koliko MRR izgleda primamljivo.

 Gledajte dalje od sjajne površine

Kupovina SaaS biznisa je jedna od najznačajnijih strateških odluka koju možete doneti. Lako je zaljubiti se u priču o rastu, u lepo dizajniran interfejs i impresivne finansijske metrike. Ali prava vrednost, otpornost i potencijal za budući rast leže dublje, u slojevima koda, arhitekture i procesa.

Temeljni tehnički due diligence nije trošak. To je najisplativija investicija koju ćete napraviti u celom procesu akvizicije. To je razlika između kupovine superautomobila i preskupe olupine sa sjajnom karoserijom.

Zato, sledeći put kada budete razmatrali akviziciju, setite se ovog vodiča. Podignite haubu. Postavljajte teška pitanja. Zaronite duboko. Jer ono što pronađete ispod površine odrediće uspeh vaše investicije i mirnoću vašeg sna u godinama koje dolaze.