Na vibe coding si dnes postavíte cokoliv.

V kostce

Prodator si vibe codingem postavil tři reálné systémy, na kterých jede celá firma, a k tomu vlastního AI agenta. Bylo to působivé. A v jednu chvíli to přestalo být udržitelné: každá nová úprava rozbila něco jinde, výkon padal, a hlavně, systém s osobními daty kandidátů a údaji klientů nešlo s klidným svědomím otevřít navenek.

Nepřepisovali jsme. Vzali jsme jejich hotových 80 % a přidali produkční vrstvu: audit na živých datech, mantinely, bezpečnost, ochranu dat, výkon a sjednocenou architekturu. Dnes tým Prodatoru vibe coduje dál sám. Jen už bezpečně, s code review a s AI agentem, který postupně přebírá práci, kterou dřív lidé klikali ručně.

Klient

Prodator Marketing s.r.o.

Obor

Výkonnostní HR a recruitment marketing

Zadavatel

Michal Mikulášek, zakladatel a CEO

Co si postavili sami

CRM, systém pro nábor, provozní systém, AI agent

Jak

Lovable nad Supabase, Claude Code, bez vývojáře

Role Blaze

Fractional CTO, audit, produkční vrstva, sjednocení architektury

Období

Duben 2026 až dnes, partnerství běží dál

Tým Blaze

Daniel Suchan (CTO), Jakub Pilch

Kdo je Prodator

Prodator je výkonnostní agentura, která firmám obsazuje pozice, které se jinak obsazují těžko: řidiči, mechanici, operátoři výroby, obchodníci. Klient si zaplatí kampaň, Prodator shání kandidáty a měří se to na čtyřech číslech: kontakty, domluvené pohovory, realizované pohovory, nástupy. Za pár let obsadili tisíce lidí napříč Evropou a vybudovali si jméno mezi velkými značkami.

Zakladatel Michal Mikulášek patří k lidem, kteří technologii nečekají. Sami ji berou do ruky. Místo aby firma kupovala krabicové CRM a nástroje, rozhodl se postavit si vlastní systémy přesně na míru byznysu. Bez vývojářského týmu. Vibe codingem.

prodator.cz

Co si postavili sami

Tohle není příběh o prototypu, který nikdy nespatřil světlo světa. Prodator si postavil a denně používal čtyři věci.

1. CRM a sales intelligence (interně Prospectly)

   Desítky tisíc firem a kontaktů, tisíce obchodních příležitostí, cold emailing.

2. Systém pro nábor kandidátů (ATS)

   Desítky tisíc kandidátů, stovky tisíc odpovědí, desítky recruiterů. A vidí do něj i klienti.

3. Provozní systém (OMS)

   Klienti, kampaně, objednávky, čerpání, renewaly, fakturace.

4. AI agent

   Na vyhledávání a obohacování obchodních příležitostí.

Všechno v Lovable nad jedním sdíleným Supabase projektem, data původně vyexportovaná z HubSpotu, s Claude Code na analýzu.

A ta rychlost byla skutečná. Člen týmu si během dvaceti minut postavil čtyři nové landing pages se čtyřmi různými layouty. Michal si sám, s pomocí AI, udělal optimalizaci načítání frontendu a stáhl první vykreslení stránky o 42 %. Tohle není netechnická firma, která zkouší něco, na co nemá. Tohle je tým, který v AI nástrojích umí fakt hodně.

Proto je férové to říct nahlas: na vibe coding si dnes postavíte cokoliv. Prodator je toho živý důkaz.

Kde to narazilo

Vibe coding vás dostane k fungující věci nesmírně rychle. Posledních 20 % cesty, z „funguje nám to“ do „můžeme to dát do rukou reálným klientům“, je ale jiná disciplína. A tam Prodator narazil na strop.

„Řekneme: přidej tlačítko tady. A ono to v tom vibe codingu rozbije něco jinde. Seděli jsme nad tím každý den, na konci dne opravené, druhý den znova.“

Michal Mikulášek, zakladatel Prodatoru

Pod povrchem se sešlo několik věcí najednou.

1. Rozdělená data

   Tři aplikace, tři oddělené databáze slepené zrcadlovými tabulkami a synchronizačními funkcemi. Spousta kódu existovala jen proto, že data byla rozdělená. Klíčová pole zabetonovaná v JSON strukturách po importu z HubSpotu, která nešlo indexovat.

2. AI agent, který nerozumí struktuře

   Když Lovable agent dostal pokyn něco upravit, nechápal, jak spolu data souvisí, a zapisoval na více míst najednou. Přesně tak vznikají rozbité vazby, duplicity a záznamy, které „zmizí“.

3. Výkon

   Pracovní mřížky, na kterých obchodníci a recruiteři denně pracovali, se načítaly i 14 až 17 sekund a padaly na timeout. Jeden jediný skrytý bug stál za dvěma třetinami všech chyb provozního systému.

4. Bezpečnost a ochrana dat

   Systém držel osobní data kandidátů, nahrávky hovorů a údaje klientů. Otázka, kdo přesně vidí a smí měnit čí data, byla kritická. A chyběla ochrana proti tomu, aby něco nenávratně zmizelo bez možnosti dohledat co a kdy.

Nejcitlivější moment přišel, když obchodníci začali hlásit, že jim „mizí data“: tasky, hovory, emaily. Pro firmu, která na těch datech stojí, je to existenční strach.

Bez zásahu by se projekt v téhle fázi rozdrolil. Ne proto, že by byl špatně vymyšlený, ale proto, že ho už technicky nešlo dotáhnout zevnitř. A to je přesně bod, ve kterém jsme nastoupili.

Proč jsme nepřepisovali

Nejjednodušší, a pro mnoho agentur nejvýhodnější, by bylo říct: zahoďte to, postavíme vám to znovu pořádně. My jsme udělali opak.

Zachovat hotových 80 % dávalo mnohem větší smysl než přepis od nuly. Byl to fungující software, který tým znal a uměl v něm rychle iterovat. Přepis by tuhle výhodu zahodil a posunul firmu o měsíce zpátky. Místo toho jsme nad to, co měli, přidali produkční vrstvu a nechali jádro, které si postavili, žít dál.

Michal si pro to zavedl vlastní metriku. Místo ROI mluví o „Return on Capacity“: kolik kapacity týmu mu spolupráce reálně uvolní.

Co jsme udělali

1. Audit na živých datech, ne od oka

   Nezačali jsme dojmem, ale měřením. Tři audity, zdraví systému, datový model a chování AI agenta, nad reálnou telemetrií a skutečnými dotazy. Tři nejhorší nálezy mluvily za vše: jeden řádek kódu za dvě třetiny chyb, nedostatečná izolace dat mezi klienty a mřížky padající na timeout s naměřeným zpomalením skoro 15×.

   Bezpečnostní audit odhalil 25 nálezů, z toho 9 kritických. Část jsme opravili rovnou, u zbytku jsme předali jasný plán nápravy.

2. Nejdřív mantinely, potom opravy

   Než jsme cokoli změnili, postavili jsme záchrannou síť. Oddělené vývojové větve, povinné review přes pull requesty, automatické testy a bránu na nasazení: na produkci nejde nic bez výslovného odsouhlasení. K tomu desítky nočních testů, které běží proti reálné produkci a hlídají, že se základ nerozsype. Ten nápad, mimochodem, přišel od Michala. Chtěl „nočního testera“, který ráno nahlásí, co se v noci rozbilo. Dnes to tak funguje.

   Souběžně jsme postavili ochranu proti ztrátě dat: měkké mazání, auditní stopu, blok proti tvrdému smazání a hlídače naplánovaných úloh.

3. Forenzní důkaz, že data nemizí

   Na nahlášené mizení dat jsme nasadili 22 agentů přímo na živý provoz a dohledali každý jednotlivý případ. Výsledek: neztratil se ani jeden záznam. Všech pět stížností byly chyby viditelnosti, špatně navázané vazby, prázdné identifikátory, čtení z neaktuální tabulky. Ne ztráta dat. Firma poprvé dostala černé na bílém, že její data jsou v pořádku.

4. Sjednocení základů

   Tohle byl největší kus práce a zároveň ta věc, kterou Michal od začátku chtěl: „Ty tři databáze mezi sebou prostě musí komunikovat.“

   Přes léto jsme tři oddělené databáze postupně sloučili do jedné. Migrace běžely o víkendech, aplikace po aplikaci, s testováním před pondělním provozem. Kód všech tří aplikací jsme převedli do jednoho repozitáře, aby sdílely společné části místo trojích kopií. Zavedli jsme centralizované logování, takže když se něco stane, je všechno na jednom místě. Doba, za kterou tým najde příčinu problému, klesla z 30 na 10 minut.

   A odstřihli jsme HubSpot. 183 klientů a 124 kampaní jsme napojili napřímo do nového provozního systému, starou historii nechali v archivu. Firma poprvé jede na jednom zdroji pravdy.

A k tomu nové věci, ne jen opravy

Souběžně jsme dodávali i to, kvůli čemu si Prodator systémy stavěl. AI agenta Opportunity Radar na vyhledávání nových obchodních příležitostí, první funkční verze za jeden víkend nad vyčištěnou databází s vektorovým vyhledáváním. Obohacování dat z více zdrojů. A hlavně agenta Prody. Ten žije ve WhatsAppu a Slacku, posílá týmu i klientům denní přehledy a postupně přebírá úkoly, které dnes lidé klikají ručně v systémech. To je ten AI native provoz, o který od začátku šlo.

Výsledky

Každý řádek je nakreslen v měřítku: šedá je doba před úpravou, oranžová je doba dnes, ve stejném měřítku.

1. Klíčové přehledové výpočty139×
   před: 139 spo: zhruba 1 s
2. Pracovní mřížky v CRM~100×
   před: 14 až 17 spo: 0,1 až 0,3 s
3. Filtr aktivit~100×
   před: 13 spo: 0,13 s
4. Filtr nad daty14,7×
   před: 709 mspo: 48 ms
5. Slučování duplicitních firem~6×
   před: 77 spo: 13 s

• Načítání stránek pro uživatele: z 10 až 20 sekund na většinou pod 5 sekund. Michal to označil za měřitelný posun.
• Dvě třetiny chyb provozního systému byl jeden bug, opravený jedním řádkem.
• Nulová ztráta dat, forenzně doložená napříč živým provozem.
• Tři databáze sloučené do jedné. Diagnostika problému z 30 minut na 10.
• HubSpot odstřižen: 183 klientů a 124 kampaní běží napřímo v jednom systému.
• Tři plné aplikace a více než 150 000 záznamů zachováno místo přepisu od nuly.
• AI agent Prody v produkci na WhatsAppu a Slacku.

Jak spolupráce běží dnes

Tohle je důležité říct na rovinu: není to jednorázová záchrana. Když provozujete tři aplikace pro reálné klienty, věci se rozbíjejí. I po sjednocení, i s testy. Rozdíl je v tom, jak rychle se to dozvíte a jak rychle to opravíte.

• Fractional CTO. Daniel Suchan dělá Prodatoru fakticky technického šéfa: rozhoduje o architektuře, reviewuje kód, nese odpovědnost za to, že to běží.
• Pevná týdenní kapacita, týdenní call s Michalem a denní kontakt na Slacku.
• Publish jen přes vývojáře, jednou denně, po code review. Tým Prodatoru dál vibe coduje v Lovable, ale nic nejde ven bez toho, aby to někdo přečetl. U každého review zapisujeme, jaký by byl dopad, kdyby změna šla ven tak, jak přišla.
• Reakce na nahlášenou chybu do hodiny v pracovní době.
• Incidenty s příčinou. Každé hlášení od klienta se eviduje s kategorií příčiny a dobou vyřešení. Týdenní přehled zvlášť za každou aplikaci, aby tým Prodatoru věděl, co čekat, a viděl trend.
• Hlášení chyb přímo z aplikace, s identifikací klienta a kampaně, místo přeposílaných zpráv.

Tým Prodatoru díky tomu nepřestal stavět. Jen už nestaví bez sítě.

Časová osa

1. Duben 2026

   Michal reaguje na LinkedIn příspěvek. Pár callů. Prodator nasazuje Džarvise, našeho AI agenta, na první provozní automatizace.

2. 8. května

   Celodenní workshop u nás v Ostravě. Tým Prodatoru se učí stavět s AI a my poprvé vidíme, co všechno už mají.

3. Květen

   Audit na živých datech. První bezpečnostní hardening provozního systému, monitoring chyb. Opportunity Radar: první funkční verze za víkend.

4. Červen

   Forenzní důkaz nulové ztráty dat. Ochrana proti smazání, výkon, mantinely. Přebíráme odpovědnost za provoz.

5. Červenec

   Plán sjednocení tří databází a jednoho repozitáře. Cíl: výpadek nikdy déle než 20 minut v pracovní době.

6. Srpen

   Migrace o víkendech, aplikace po aplikaci. Jedna databáze, centralizované logování. HubSpot odstřižen. Agent Prody v produkci.

7. Září

   Provozní režim: code review, publish jednou denně, incident reporting s příčinou. Roadmapa: dotažení provozního systému a refaktoring.

Co říká klient

Michal je klient, který se ptá „proč“, ne jen „co“. Sám do systému denně sahá, sám navrhuje, co zlepšit, a sám nás drží u měřitelných výsledků. Přesně takový klient, se kterým se dá stavět dlouhodobě.

Je to i váš případ?

Zaškrtněte, co platí u vás.

• Postavili jste si vlastní systém v Lovable, Bolt, Replit, Cursor nebo Claude Code a firma na něm reálně jede.
• Nemáte ve firmě vývojáře, nebo máte jednoho a ten nestíhá.
• Každá nová úprava rozbije něco jinde a už se bojíte cokoliv měnit.
• Systém drží data klientů, kandidátů nebo zákazníků a nejste si jistí, kdo přesně vidí co.
• Chcete ho pustit externím uživatelům, ale něco vám říká, že ještě ne.
• Nechcete začínat od nuly a zahazovat měsíce práce.

Časté otázky