← Zpět · 6. května 2026 · 2 min čtení

Můj první SaaS

Jak vznikal můj první SaaS projekt zaměřený na GDPR-friendly PoW CAPTCHA pro EU trh. Od prvního nápadu přes návrh vlastního proof-of-work algoritmu, optimalizaci výkonu a škálování až po řešení GDPR, DPA a právních dokumentů.

Pracuji pro pravidelného německého zákazníka a ptal se mě, jestli nevím o nějakém CAPTCHA balíčku pro Laravel. Samozřejmě jsem mu nabídl reCAPTCHA a Cloudflare Turnstile. Vysvětlil mi, jak je to s nakládáním s daty v EU.

Začal jsem hledat na internetu a našel jsem několik firem, které nabízejí GDPR-compliant CAPTCHA služby. Překvapila mě ale cena a také to, jak málo takových firem existuje.

V tu chvíli mě to trklo: „Hele, to by mohla být díra na trhu,“ říkal jsem si. A tak jsem se rozhodl vytvořit vlastní CAPTCHA službu.

Cesta

Samozřejmě jsem nevěděl nic o GDPR ani o tom, jak má všechno přesně fungovat. Nejdřív jsem přemýšlel nad tím, jaký typ CAPTCHA zvolit. Vyhrála PoW, a to hlavně kvůli jednoduchosti implementace. Navíc z osobní zkušenosti vím, jak velký opruz je klikat na obrázky. První iterace PoW byla jednoduché řešení pro hledání počtu počátečních „0“ v hash řetězci. Fungovalo to dobře a překvapila mě jednoduchost celého řešení. Problém přišel ve chvíli, kdy jsem potřeboval škálovat obtížnost. Přidávání dalších „0“ (aby byla obtížnost vyšší) exponenciálně zpomalovalo výpočet. Výpočty s takovou obtížností trvaly i desítky sekund, a to na nejnovějším hardwaru. Neumím si představit, co by se dělo na starších telefonech.

Optimalizace

Takže přišla změna: server vydá náhodný 32B token + target (uložený v cache spolu s hashem IP adresy). Klient hledá solution takový, aby: hexdec(substr(sha256(token + solution), 0, 8)) <= target Čím nižší target, tím těžší výpočet. Tahle škálovatelnost už byla naprosto v pohodě a vše fungovalo tak, jak mělo. JS widget byl taky kapitola sama pro sebe (o tom ale až jindy). Poslední popsaný algoritmus PoW používám i dnes, ale namísto vystavení challenge a následného ověření na serveru to dnes za mě řeší přímo JS widget. Backend nakonec dostane JWT-lite (HS256 bez headeru a bez alg) a pomocí secret klíče ověří HMAC a vyparsuje JSON s daty PoW tokenu (attestation).

Rychlost

Největším strašákem pro mě byla rychlost a obava z paralelních útoků vedených na endpoint. Díky Redisu a jedinému SQL dotazu v endpointu pro vystavení tokenu se mi podařilo odstranit bottleneck kolem databáze. Teď už je limitem hlavně síť a CPU. To se dá řešit vertikálním škálováním, takže bez větších problémů.

GDPR

Celé to bylo fajn. Programování mě fakt baví, takže jsem si samotnou cestu užíval. Pak ale přišla na řadu landing page a legals. Tady už to byl úplně jiný druh „zábavy“. Takový, který pro programátora není zábavný ani trochu. Strávil jsem několik týdnů hledáním informací a pročítáním GDPR, Schrems II, DPA, sub-processors a dalších věcí kolem compliance. Nakonec si ale myslím, že se mi podařilo dát dohromady povedené legals pro celý projekt.

Tech Stack

  • Laravel 13
  • Livewire 4
  • FluxUI Pro
  • Tailwind CSS 4
  • PostgreSQL 18
  • Redis

Server běží u Hetznera v Norimberku. Projekt nepoužívá žádnou non-EU službu kromě platební brány (Stripe) a MoR řešení (Lemon Squeezy).

https://captchaapi.eu

Stačí psát část slova · ⌘K otevře hledání odkudkoliv

No results found