Z Bolt.new prototypu do produkcie za 2 týždne

Prišiel k nám founder so SaaS produktom postaveným takmer celkom cez Bolt.new a Claude. Strávil tri týždne jeho stavbou — pôsobivým nástrojom na riadenie projektov pre kreatívne agentúry. UI bolo vyleštené. Demo bolo presvedčivé. Mal piatich platiacich beta používateľov.

Mal tiež dátum launchu o tri týždne a rastúce podozrenie, že jeho aplikácia nie je pripravená na skutočný traffic.

Mal pravdu.

Poznámka: Detaily klienta boli anonymizované. Technické zistenia sú reálne.

Výzva

Founder — nazvime ho Tomáš — je bývalý projektový manažér v kreatívnej agentúre. Problémovú oblasť poznal dokonale. Použil AI nástroje na stavbu riešenia, ktoré skutočne fungovalo pre jeho use case. Produktová logika bola solidná.

Ale Tomáš nie je inžinier. Nevedel rozoznať kód, ktorý funguje na deme, od kódu, ktorý funguje pod záťažou. Mal niekoľko varovných signálov:

• Aplikácia občas ukazovala prázdne stránky, ktoré zmizli po refreshi
• Načítacie časy sa spomaľovali ako beta používatelia pridávali viac dát
• Jeden používateľ nahlásil, že krátko videl meno projektu iného používateľa počas načítavania stránky
• Nemal tušenie, čo sa stane s 50 alebo 100 súčasnými používateľmi

Ten posledný bod bol ten, ktorý ho priviedol k nám.

Čo sme našli

Spustili sme náš štandardný Quick Audit — komplexný prehľad bezpečnosti, výkonu, infraštruktúry a kvality kódu. Tu je čo audit odhalil:

Bezpečnosť: 23 problémov

• 4 kritické: API kľúče hardkódované v klientskom JavaScripte (vrátane Stripe secret key), žiadna serverová autorizácia na API routes (každý autentifikovaný používateľ mohol pristupovať k akémukoľvek projektu), otvorená CORS politika (*) a admin route bez autentifikácie
• 8 vysokých: Žiadna validácia vstupov na žiadnom endpointe, chýbajúci rate limiting, SQL dotazy postavené konkatenáciou reťazcov na 3 miestach, session tokeny uložené v localStorage
• 11 stredných: Chýbajúce bezpečnostné hlavičky (CSP, HSTS, X-Frame-Options), žiadne audit logovanie, heslá hashované cez MD5 namiesto bcrypt, žiadna CSRF ochrana

Používateľ, ktorý videl meno projektu iného používateľa? To bola chýbajúca autorizácia. Akýkoľvek prihlásený používateľ mohol načítať dáta akéhokoľvek projektu uhádnutím ID (ktoré bolo sekvenčné celé číslo).

Výkon: 4x pomalšie než akceptovateľné

• N+1 dotazy všade — stránka so zoznamom projektov robila 47 databázových dotazov pre 15 projektov
• Žiadne cachovanie — každé načítanie stránky udrelo do databázy pre dáta, ktoré sa menili raz za deň
• Žiadny connection pooling — každý request otváral nové databázové spojenie
• Neoptimalizované obrázky — používateľmi nahrané obrázky servované v originálnom rozlíšení (niektoré boli 5MB+)
• Žiadne CDN — statické assety servované z aplikačného servera vo Frankfurte

Priemerný čas načítania stránky: 4,2 sekundy. Po našich opravách: 0,9 sekundy.

Infraštruktúra: jediný bod zlyhania

• Jeden server, žiadna redundancia — ak VPS spadol, všetko spadlo
• Žiadne automatizované zálohy — databáza nebola nikdy zálohovaná
• Žiadny monitoring — Tomáš sa dozvedel o výpadku, keď mu používatelia napísali email
• Nasadenia cez SSH — git pull && npm run build na produkčnom serveri, bez plánu na rollback
• Žiadne staging prostredie — všetko testovanie prebiehalo v produkcii

Kvalita kódu

AI-generovaný kód bol v skutočnosti dobre štruktúrovaný ako na prototyp. Komponenty boli rozumne organizované, pomenovanie bolo konzistentné a biznis logika bola solidná. Problémy boli všetky v oblastiach, ktoré AI nástroje neprioritizujú: bezpečnosť, výkon pod záťažou a prevádzková pripravenosť.

Čo sme opravili

Pracovali sme s Tomášom dva týždne, prioritizujúc podľa rizika. Tu je čo sme urobili, v poradí:

Týždeň 1: Bezpečnosť a kritická infraštruktúra

Deň 1-2: Bezpečnostné opatrenia

• Presunutie všetkých tajomstiev do premenných prostredia a .env súboru vylúčeného z gitu
• Rotácia exponovaného Stripe kľúča a všetkých databázových poverení
• Pridanie serverových autorizačných kontrol na každú API route
• Konfigurácia CORS na povolenie len produkčnej domény
• Ochrana admin route autentifikáciou a IP obmedzením

Deň 3-4: Validácia vstupov a ochrana dát

• Pridanie Zod validačných schém pre každý API endpoint
• Nahradenie SQL s konkatenáciou reťazcov parameterizovanými dotazmi
• Migrácia hashovania hesiel z MD5 na bcrypt (s migračnou cestou pre existujúcich používateľov)
• Presun session tokenov z localStorage do httpOnly cookies
• Pridanie rate limitingu na autentifikačné endpointy

Deň 5: Základy infraštruktúry

• Nastavenie automatizovaných denných záloh databázy do externého úložiska
• Pridanie monitoringu dostupnosti (Better Stack) a sledovania chýb (Sentry)
• Vytvorenie staging prostredia zrkadliaceho produkciu
• Nastavenie základného CI/CD pipeline: push do main spustí testy a automaticky nasadí

Týždeň 2: Výkon a prevádzková pripravenosť

Deň 6-7: Optimalizácia databázy

• Oprava všetkých N+1 dotazov eager loadingom — 47 dotazov na stránku znížených na 3
• Pridanie databázových indexov na často dotazované stĺpce
• Nastavenie connection poolingu cez PgBouncer
• Pridanie cachovania na úrovni aplikácie cez Redis pre často pristupované dáta

Deň 8-9: Frontend výkon

• Implementácia pipeline na optimalizáciu obrázkov (zmena veľkosti, kompresia, servovanie WebP)
• Pridanie CDN pre statické assety (Cloudflare)
• Implementácia správnych cachovacích hlavičiek
• Code-splitting hlavného bundlu — počiatočný load klesol z 1,8MB na 340KB

Deň 10: Finálne opatrenia

• Záťažový test s 200 súčasnými používateľmi — stabilný na 150ms priemernom čase odpovede
• Pridanie health check endpointu pre load balancer
• Nastavenie PM2 s auto-reštartom a zero-downtime nasadeniami
• Zdokumentovanie procedúr nasadenia a rollbacku

Výsledky

Tomáš spustil podľa plánu. Tri mesiace neskôr má 40+ platiacich zákazníkov, nulové bezpečnostné incidenty a aplikáciu, ktorá zvláda jeho súčasnú záťaž s priestorom na rast.

Čo to stálo

Celá zákazka — dva týždne našej Full Transformation služby — stála výrazne menej než tržby, ktoré by Tomáš stratil bezpečnostným incidentom alebo dlhodobým výpadkom počas jeho kritickej fázy rastu.

Dôležitejšie je, že Tomáš teraz má codebase, ktorý môže s istotou odovzdať budúcemu CTO alebo vývojárskemu tímu. AI-postavený základ bol solidný. Len potreboval produkčné inžinierstvo navrchu.

Kľúčové ponaučenie

AI nástroje sú pozoruhodne dobré v stavbe produktov. Nie sú stavané na to, aby tie produkty pripravili na produkciu. To nie je nedostatok — to je iná disciplína. Medzera medzi "funguje to" a "funguje to spoľahlivo, bezpečne a v scale" je tam, kde operujeme my.

Ak rozpoznávate niektoré z Tomášových varovných signálov vo vašom vlastnom produkte, objednajte si bezplatný Quick Audit. Povieme vám presne, kde stojíte a čo treba opraviť pred škálovaním. Žiadne prekvapenia, žiadny sales pitch — len jasný, prioritizovaný akčný plán.

Prečítajte si viac o bežných problémoch, ktoré nachádzame v AI-postavených aplikáciách:

• 5 vecí, ktoré Bolt/Lovable neopravia
• Bezpečnostné diery v každom vibe-coded app
• MVP do produkcie: Kompletný checklist