Jak jsem sám za pět týdnů postavil SaaS, který mi loni nacenili na dva miliony

Před dvěma měsíci jsem stejnou službu začal stavět sám. Za pět týdnů byla naživo, mám první uživatele a platby. Naprogramoval jsem ji já sám – člověk, který sice vedl technologickou firmu, ale programovat neumí. Což je možná dnes i moje výhoda. A já vám tady popíšu, jak. A ano, je to dlouhý, ale kua budujete saasko, to je pro tvrďáky, ne pro salámy, co chtějí všechno v pár bulletpointech :-).

Tohle není návod, jak se stát programátorem. Je to návod, jak ho nepotřebovat. Není to ani článek o tom, jak je AI kouzelná a teď už každý zvládne všechno. Je to článek o systému. O tom, jak jsem si kolem umělé inteligence postavil sadu pravidel a kontrol, která ze mě – z netechnického produktového člověka – udělala někoho, kdo dotáhne bezpečný a stabilní placený produkt do konce. A je napsaný tak, abyste si ten systém mohli postavit taky.

Jen ať je hned na začátku jasno, čím to celé stavím – apku píšu v Claude Code, úkoly si vedu v ClickUpu, byznysovou znalost v Notionu, zadávám hlasem přes Wispr Flow. Popíjím Colu Zero Zero.

A protože si pod „nástrojem na psaní kódu“ netechnický člověk obvykle představí černé okno terminálu plné zaklínadel, hned to uvedu na pravou míru: takhle to u mě nevypadá. Claude Code sice ovládat z terminálu jde, ale já ho používám jako obyčejnou desktopovou aplikaci. A pro nás, co nejsme z branže, je to o třídu přívětivější řešení. Stáhnete a nainstalujete ho jako kteroukoli jinou aplikaci, přihlásíte se placeným účtem u Anthropicu a za deset minut píšete první zadání běžnou řečí. Žádné černé okno, žádné zkratky, kterým nerozumíte – píšete do okna, ono vám odpovídá. Měsíčně mě to celé stojí jednotky tisíc korun – předplatné nástroje plus spotřebované AI kredity. Tedy zlomek toho jednorázového rozpočtu, který mi tehdy nacenili. K té matematice i k tomu, z čeho přesně se ty náklady skládají, se ještě vrátím.

Neboj se prvního kroku

Než budeš číst dál, chci tě zbavit jedné obavy, na které spousta netechnických lidí skončí dřív, než vůbec začne: že je rozjezd nějaká věda. Není. Je to ze všeho nejjednodušší.

Nemusíš nic umět dopředu. Claude tě vším provede – stačí mluvit lidsky. Klidně napiš úplně natvrdo: „Nerozumím tomu, jak na to. Mám takovýhle nápad. Pomoz mi ho rozjet.“ A on tě vezme za ruku a provede tě vším – od založení projektu přes první spuštění až po nasazení do produkce. Celou dobu přitom mluví jazykem, kterému rozumíš, ne programátorskými zaklínadly. Když ti něco nedojde, zeptáš se a on to vysvětlí znovu a jinak.

Celá ta bariéra je jenom v hlavě. Nejtěžší na tom je udělat ten první krok – napsat tu úplně první větu do okna. Zbytek pak jde skoro sám.

Jak jsem se sem dostal

Asi rok provozuju s kamarádem numismatický e-shop Mincmistr.cz. Baví mě to víc, než jsem čekal – svět sběratelů mincí má svou hloubku, mě baví marketing, budování něčeho, historie. Vše se tady spojuje. A celou tu dobu jsem koutkem oka pošilhával po tom, jestli by se kolem sběratelů nedala postavit nějaká pořádná online služba.

Blokovaly mě dvě věci. Ta první byla úplně praktická: někdo by to musel naprogramovat, a já to neumím. Ta druhá byla strategická: hledal jsem tu správnou niku, díru na trhu, kam se opřít. Ani jedna z těch věcí se dlouho nehýbala.

A pak se obě najednou pohnuly ve stejný okamžik. AI nástroje dozrály do bodu, kdy mi dovolily dělat vývoj, který by dřív trval měsíce a stál stoh peněz. A já mezitím mezi sběrateli nahmatal reálnou potřebu – často nevědí, co vlastně mají, kde to je a co to stojí. Praktická bariéra a strategická bariéra spadly současně.

Měl jsem to už jednou rozjeté, pod stejnou značkou OutOfDark, ale tehdy jako službu na mapování zákaznické cesty. Nevyšlo to a psal jsem o tom tady. Mohl bych z toho mít trauma a držet se od startupů dál. Místo toho jsem značku oprášil (ehm… jako dal jsem za doménu spoustu peněz, tak to přeci nenechám vyhnít) a nasměroval ji jinam – dneska je z OutOfDark moderní katalog mincí pro sběratele. Vyfotíš minci nebo vložíš odkaz, AI ji sama založí a ty najednou víš, co máš, kde to je a kolik to stojí. Je tam rozpoznávání typů mincí, prodej na eBay a Aukro, tiskové sestavy, importy/exporty, přehled aukcí, pomoc s dohledáváním chybějících mincí, automatický přepočet ceny, AI pomocník a mnohem, mnohem více.

Za dva měsíce jsem ani jeden den nepřestal kroutit hlavou. Ne proto, že bych byl chytřejší než loni, ale protože dnešní jazykové modely dávají lidem, jako jsem já – produktově zaměřeným, neprogramujícím – kouzelné schopnosti, které byly ještě nedávno za zdí. Za pět týdnů jsem dostal do živého provozu to, co mi loni nacenili na dva miliony korun a půl roku vývoje. TVL! A z mého produktového pohledu je výsledek lepší, než co bych tehdy dostal – jsem o tom přesvědčen. Když jsem ho dal na kontrolu zkušenému programátorovi, řekl, že tam nemá moc co dělat – že je to ze strany struktury i zabezpečení nadprůměrně připravené.

Tady se musím přiznat k jedné věci, která lidi překvapuje: za celou tu dobu jsem neviděl jedinou řádku kódu. Jenže já jsem řádku kódu neviděl ani v Shoptetu. Tam jsem musel 12 let věřit programátorům – dnes stejně tak věřím jazykovému modelu, který se navíc každým měsícem zlepšuje a který si můžu nechat zkontrolovat lepším modelem, takže mám aspoň nějakou jistotu, že to nestojí na vodě. A bez jediné viděné řádky kódu jsem tehdy ze Shoptetu udělal miliardovou firmu. Takže ne, fakt, že nečtu kód, mě nikdy nevyděsil.

Co je ale jiné než kdy dřív: tentokrát jsem to celé řídil sám, bez týmu lidí. A přesně proto jsem si musel postavit systém.

A o tom je zbytek článku. Chci nasdílet zkušenosti, které jsem za ty dva měsíce nasbíral – konkrétně to, jak jsem se pokusil vytvořit co nejlepší samoudržovací model. Model, který odstraňuje moji největší slabinu (nejsem programátor) a naopak posiluje moji největší přednost (myslím si, že jsem slušný produkťák). Čísla zatím mluví pro něj: přes 2 573 commitů (to jsou v podstatě jednotlivé uložené změny kódu) a kolem tří tisíc automatických testů. A v ClickUpu, kde si vedu úkoly, kolem osmi set zavřených tasků za dva měsíce – a backlog (zásobník nevyřízených věcí) prakticky na nule, dnes osm položek, a to jsou většinou vědomě odložené budoucí nápady. Ty ale udělám asi o víkendu.

Tohle číslo si vychutnávám, protože je to úplně naopak než ve Shoptetu. Tam nám v backlogu pořád leželo dvě stě až tři sta tasků, které jsme nestíhali. S několika desítkami programátorů. Tady je hotovo skoro všechno, co dává smysl udělat. Bez jediného programátora. Prostě wow.

Tolik k tomu, jak jsem se sem dostal a co to vyneslo. Zbytek článku je už jen o systému – a ten začíná tím, jak na AI vůbec koukám.

AI je tým, který řídím

Než se pustím do jednotlivých dílů, musím vysvětlit, jak na celou věc koukám, protože z toho všechno ostatní vyplývá.

AI pro mě není nástroj. Je to tým, který řídím. Pracuje ve dne v noci, nikdy nereptá a nikdy nejde na oběd. Nemusím řešit, kdo nechal bordel v kuchyňce :-). Ale má tři vlastnosti, se kterými musím napevno počítat, jinak mě potopí:

1. Nic si nepamatuje. Každá nová konverzace začíná od nuly. To, co jsme se domluvili včera, je pryč, pokud jsem to někam nezapsal.
2. Nezná kontext, který jsem mu neřekl. Nemá tušení, jak vypadá můj byznys, proč jsem se rozhodl tak a ne jinak, co je pro mě svaté. Ví jen to, co mu předložím.
3. Když něco neví, radši si to sebevědomě vymyslí, než aby se přiznal. A tohle je ze všech tří nejnebezpečnější. Vymyšlený, ale věrohodně znějící nesmysl je horší než upřímné „nevím“.

Celé moje uspořádání je v podstatě operační systém kolem tohohle týmu. Každé pravidlo, každá kontrola, každý zápis řeší jednu z těch tří vlastností. A nejdůležitější důsledek pro mě osobně: moje práce se přesunula z dělání na řízení a orchestraci. Já nestavím. Já vedu tým, který staví, a hlídám, aby stavěl správnou věc správně. Tuhle metaforu si držte v hlavě, protože se k ní budu vracet.

Celé to stojí na šesti pilířích. Srdcem systému je ten třetí. Ve zkratce, ať víte, kam míříte: (1) pravidla, která týmu dávám, (2) jak týmu zadávám práci, (3) kontrolní soustava = srdce, (4) další záchranné sítě, (5) bezpečná půda pod nohama, (6) provoz a paměť.

Pilíř 1: Pravidla, která dávám týmu

Když tým pokaždé na začátku práce všechno zapomene, musíte mít onboarding, který se přehraje na začátku každého dne. U mě tu roli hrají psaná pravidla projektu – něco jako ústava.

Tady chci na chvíli zpomalit, protože pokud si máte z celého článku zapamatovat jedinou věc, jsou to pravidla. Není to ani kontrolní soustava, ani zálohy, ani žádný chytrý trik s nástroji. Jsou to pravidla. Pravidla, pravidla, pravidla. Právě tam se rozhoduje většina kvality výsledku – tým staví přesně tak dobře, jak dobře jsem mu napsal ústavu – pravidla. Když je systém pravidel slabý, nedožene to ani sebelepší model. Když je dobrý, vytáhne i z průměrného zadání slušný výsledek. Takže jestli máte na začátku omezenou energii a nevíte, kam ji dát, dejte ji sem.

A teď druhá věc, kterou málokdo čeká: ta pravidla nejsou žádný kód. Nepotřebujete znát Python nebo PHP. Jsou to obyčejné textové soubory psané lidskou řečí. Formát se jmenuje Markdown (soubory s koncovkou .md), ale nelekejte se toho slova – je to prostý text s pár jednoduchými značkami (hvězdička kolem slova udělá tučně, mřížka udělá nadpis), nic víc. Žádné programování, žádná syntaxe, kterou byste museli studovat. Kdo umí napsat e-mail, umí napsat pravidlo. Doslova si tam normální větou napíšu „při nejistotě se ptej, nevymýšlej si“ a tým to bere jako zákon. To je celé kouzlo – nejmocnější nástroj v celém systému ovládáte tím, že umíte česky a víte, co chcete.

Tahle pravidla žijí přímo u projektu a mají jednu zásadní vlastnost: přednost před vším ostatním. Před tím, co si AI „pamatuje“, před historií konverzace, před tím, co se jí zrovna zdá rozumné. Když se pravidlo a domněnka rozcházejí, vyhrává pravidlo. A protože pravidel je víc a žijí na víc místech (obecná pro všechny moje projekty, specifická pro OutOfDark, postupy na konkrétní spouštěč), mám jasně danou hierarchii – když si dvě pravidla skáčou do řeči, je jasné, které vyhraje. Pravidla se navzájem hlídají, aby si neodporovala. Tedy je na vás, abyste si toto pravidlo uhlídali.

Jedna praktická věc, na kterou narazíte, jakmile vám pravidel přibude: nedají se nacpat všechna do jednoho dlouhého souboru. Tým si je sice na začátku konverzace načte, ale číst před každým úkolem desítky stránek je zbytečně pomalé, drahé a to podstatné se v tom stejně ztratí. U mě ta pravidla narostla do desítek kilobajtů textu – jako menší brožura. Tak jsem to rozdělil. Úplně nahoře je krátký rozcestník (CLAUDE.md), který se načítá vždycky a funguje jako mapa – v pár řádcích říká „základní pravidla chování jsou tady, podrobné technické zásady tamhle, postup na zálohu zase jinde“. Samotná detailní pravidla žijí ve zvláštním souboru (RULES.md) a ještě konkrétnější postupy v dalších – a načítají se, teprve když jsou zrovna potřeba. Tým tak má pořád před očima mapu a do hloubky sáhne, až když na to dojde. Bez té mapy by se s rostoucí ústavou postupně přestal trefovat do toho, co je zrovna důležité. Snažte se ty důležité informace a rozcestníky dát co nejvíc na začátek.

Tři pravidla pro chování AI jsou pro mě nejdůležitější, protože každé z nich přímo cílí na jednu z těch tří nebezpečných vlastností:

• Při nejistotě se ptej, nedomýšlej si. Tým ode mě hned v pravidlech ví, s kým má tu čest: nejsem klasický programátor, kód nepíšu ani nečtu a zadávám v řeči produktu, ne v řeči kódu. Říkám věci po svém a občas neúplně – a právě proto je tohle pravidlo klíčové. Kdykoli má tým pocit, že nejsme úplně sladění nebo že mu v zadání něco chybí, má se zeptat a společně si to dopřesnit, ne se pustit do práce podle vlastního odhadu.
• Nesahej do produktu bez svolení. Drobnost ano, ale změnu chování ne. Tým nesmí potichu předělat něco, co funguje, jen proto, že ho to napadlo.
• U každé změny dodej laický souhrn, riziko, jak to vrátit zpět, jak to ověřit a co mám dělat já. Tohle je můj řídicí panel. Nezajímá mě, jak to AI udělala uvnitř. Zajímá mě: co se změní z pohledu uživatele, co se může pokazit, jak to v případě průšvihu vrátím, kde si v prohlížeči ověřím, že to funguje, a jaký je můj další krok.

A teď to nejdůležitější, co jsem se za ty dva měsíce naučil – změna myšlení, která mi víc než cokoli jiného zlepšila výsledky. Nehádej se s AI, uprav pravidlo. Když tým udělá něco špatně, instinkt člověka je pustit se do diskuse: „Proč jsi to neudělal jinak? Proč jsi nepoužil tamto? Vždyť je to přece jasné.“ Tahle cesta nikam nevede. Můžete se dohadovat půl hodiny, model se omluví, slíbí nápravu – a v příští konverzaci, která začíná zase od nuly, udělá přesně tutéž chybu znova, protože si z té hádky nic neodnese.

Správná otázka po každém přešlapu nezní „proč jsi to udělal blbě“, ale: jaké pravidlo chybělo, aby to příště neudělal? A tady přijde to nejtěžší, co musíte spolknout: chyba je skoro vždycky na vaší straně, na straně člověka, který pravidla píše, ne na straně modelu. Já jsem to prostě dost jasně neřekl. Model nečetl moje myšlenky, splnil to, co stálo v zadání a v pravidlech – a když tam ten konkrétní mantinel nebyl, jel podle svého nejlepšího odhadu. Oprava tedy skoro nikdy neznamená vyhrát hádku. Znamená doplnit nebo upřesnit pravidlo. Jakmile jsem tohle přijal, přestal jsem ztrácet čas dohadováním a začal jsem každý průšvih brát jako bezplatnou informaci o tom, kde mám v ústavě díru. Je to nepříjemné na ego a strašně účinné v praxi.

A protože tahle znalost „co musí být ohlídané“ je destilát mojí produktové a projektové zkušenosti, ne technické (k tomu se ještě dostanu níž), píšu ta pravidla jako produkťák, ne jako programátor – formuluju, co se nesmí stát z pohledu uživatele a byznysu, ne jak to má být vyřešené uvnitř.

Jak si to nastavit sám: Nečekejte, až vás AI naštve potřetí. Naštve. Sepište si vlastní „ústavu projektu“ do jednoho souboru, který má AI vždycky před očima – v Claude Code se ten výchozí soubor jmenuje CLAUDE.md, nástroj si ho sám načte na začátku každé konverzace (jiné nástroje mají na trvalé instrukce své vyhrazené místo, koukněte do jejich dokumentace). Nemusí být dlouhá. Začněte těmi třemi pravidly chování výš, ta jsou univerzální. A pak přidávejte: pokaždé, když vás AI něčím naštve nebo udělá pitomost, neopravte jen tu pitomost, ale dopište pravidlo, které ji příště nedovolí. Nechte AI, ať to doplní za vás, jen jí to řekněte. Berte to jako nejnávratnější investovanou minutu v celém systému. A nezačínejte rovnou složitou strukturou víc souborů – na úplném startu stačí ten jeden. Rozcestník a oddělené detaily zaveďte, teprve až vám soubor přeroste přes hlavu; dřív je to zbytečná režie.

Pilíř 2: Jak s týmem pracuju

Mít skvělý tým je k ničemu, když mu zadáváte chaoticky. Tady je, jak z myšlenky dělám hotový kus – a kdo nese odpovědnost (pořád já).

Malé úkoly, jedna věc po druhé. Nikdy ne „přepiš celou aplikaci“. Vždycky jeden konkrétní, ohraničený kus. Velký úkol je velká plocha, kde se může něco rozbít a nevíte kde.

Nový úkol znamená novou konverzaci. Dlouhé vlákno postupně zašumí kontext – tým se v něm utopí, ztrácí nit, plete si, co bylo dřív. Čistý start je čistá hlava.

Říkám PROČ, ne jen CO. Tohle je možná nejpodceňovanější trik. „Přidej validaci formuláře“ je horší zadání než „přidej validaci, protože mi lidi posílají prázdné formuláře a já pak nevím, kdo to byl“. To „proč“ dá týmu kontext, který by jinak neměl – a výsledek je rázem chytřejší, protože řeší skutečný problém, ne jen literu zadání.

A teď k části, která mě osvobodila nejvíc – a napřed zní děsivě: jak s tím programátorem na druhé straně reálně mluvím. Nemusím znát jedinou technickou věc. Mluvím čistě z pohledu uživatele a produkťáka. „Tahle obrazovka má dělat tohle.“ „Tady vlevo dole chybí reference.“ „Tohle je matoucí, zjednoduš to.“ „Když kliknu sem, mělo by se stát tamto, a nestane se.“ To je celý můj slovník. Nemusím vědět, jak se to udělá – musím vědět, co to má umět a jak se to má chovat z pohledu člověka, který tu obrazovku používá.

A funguje to i vizuálně. Udělám screenshot obrazovky, hodím ho rovnou do Claude Code a napíšu třeba „tady mi zmenši ten nadpis a změň barvu na tmavší“. Claude Code je na tohle perfektně připravený – obrázek vidí, rozumí mu a změnu přeloží do kódu sám. Je to úplně stejné, jako kdybych měl programátora na druhé straně stolu, otočil k němu monitor, ukázal prstem a řekl „tohle se mi nelíbí, udělej to takhle“. On si to přebere a udělá. Já dodávám zadání v řeči uživatele, on řeší to „jak“.

Tohle je podle mě pro netechnické lidi ta klíčová myšlenka celého článku: stačí umět popsat z pohledu uživatele, co to má umět a jak se to má chovat. Zbytek je práce týmu. Roky jsem si myslel, že abych zadal vývoj, musím mluvit jazykem vývojářů. Nemusím. Musím mluvit jazykem produktu – a ten umím líp než kdokoli, protože vím, pro koho to stavím a proč.

Zadávám hlasem. Diktuju (používám na to Wispr Flow – neuvěřitelně návyková záležitost) a je to mnohem rychlejší a přirozenější než psát. Myšlenky plynou líp, když mluvíte.

Čtu kriticky, co mi tým posílá. Nepřikyvuju. Tohle je klíčové a jde to proti instinktu. AI zní sebevědomě a je lákavé jen odsouhlasit. Jenže já mám často větší kontext než ona – vím o byznysu, o uživatelích, o tom, co jsme řešili minulý týden. Takže se ptám: „Je to opravdu systémové řešení? Nedá se to udělat líp? Nebo jinak?“ Překvapivě často se dá.

Tým smí říct ne. Cynický pohled na rozsah je vítaný. Když se ptám „je tahle funkce fakt nutná?“, chci slyšet i odpověď „není“. Nejlevnější funkce je ta, kterou neuděláte.

Validuju v prohlížeči, ne v kódu. Já kód nepřečtu, takže pro mě „hotovo“ znamená „vidím to fungovat na obrazovce“. Proto u každé změny chci ověřovací cestu: jdi na tuhle adresu, klikni sem, měl bys vidět tohle. Bez toho zírám na localhost a nevím, co testuju. A nově to jde posunout ještě o krok dál: tým si tu cestu dokáže proklikat sám. Claude Code totiž umí vzít prohlížeč doslova do ruky – sám otevře danou stránku v Chromu, proklikne ji jako běžný uživatel, mrkne, jestli to vypadá a chová se, jak má, udělá snímek obrazovky a teprve pak mi práci předá se slovy „hotovo, takhle to teď vypadá“. Já tím pádem nejsem první, kdo objeví, že je něco křivě – jsem až druhá kontrola. Šetří to otravné kolo „odevzdáno → zjistím, že je to špatně → vrať to a oprav“, protože tým tu chybu vidí dřív než já.

Aby to nebyla jen teorie, ukážu vám jeden reálný úkol od nápadu po nasazení. Chtěl jsem, aby aplikace u investičních mincí sama přepočítávala cenu podle aktuální ceny kovu. Zadání jsem nadiktoval zhruba takhle: „U mincí, co mají hodnotu hlavně z drahého kovu, chci, aby se cena automaticky přepočítala podle aktuálního spotu zlata a stříbra – protože ručně to nikdo hlídat nebude a sběratel chce vidět reálnou hodnotu, ne tu, co tam zadal před rokem.“ Agent se nejdřív zeptal na pár věcí (odkud brát kurz, jak často přepočítávat (zaplatil jsem si jedno API, co nabízí aktuální ceny drahých kovů)), pak to postavil a vrátil mi laický souhrn: co přibylo, jaké je riziko, jak to vrátit zpět. A k tomu ověřovací cestu ve stylu „Jdi na http://localhost:8000/admin/coins/, otevři minci označenou jako investiční, podívej se na pole s cenou – mělo by ukazovat hodnotu spočítanou z dnešního spotu, ne tvoje původní číslo.“ Šel jsem na tu adresu, klikl, viděl správné číslo. Teprve pak jsem to vědomě poslal do produkce. Žádný krok jsem nepřeskočil a v žádném jsem nečetl kód.

Jak si to nastavit sám: Rozsekejte práci na malé kusy a každý velký nový kus začněte v čisté konverzaci. V plánovací fázi využívejte „plan mode“ Clauda. K zadání vždy přilepte jednu větu „proč to chci“. Mluvte z pohledu uživatele, ne z pohledu kódu – popište, co má obrazovka dělat, ne jak. Když řešíte vzhled, klidně přiložte snímek obrazovky a ukažte prstem. A vynuťte si od AI ověřovací cestu – konkrétní klikací postup, jak si výsledek osaháte na vlastní oči. Když ji AI nedá, je to často znamení, že si není jistá, že to funguje.

Pilíř 3: Kontrolní soustava – patnáct kontrol a jedna mega kontrola

A jsme u srdce celého kouzla. Tohle je část, kvůli které ten článek vlastně píšu, protože tohle je to, co mě v noci nechá spát.

Nejdřív ale: co taková „kontrola“ fyzicky je? Je to textový soubor s instrukcí pro AI (v Claude Code se mu říká skill, něco jako uložené makro – zabalený postup, který nástroj umí spustit na povel). Napíšu krátký příkaz, třeba security check, a nástroj spustí jednoho konkrétního revizora na jednu věc. Napíšu mega check a spustí jich patnáct najednou. Žádné programování – jen příkaz a počkám si na výsledek.

Mám tedy sadu patnácti „checků“. Každý je samostatný „revizor“ se svým úzkým zaměřením – jako kdybych si najal patnáct specialistů, každého na jednu věc. Můžu spustit jednu cíleně (třeba jen bezpečnostní, když jsem zrovna sahal na přihlašování), nebo můžu jedním příkazem spustit všech patnáct najednou – tomu říkám „mega check“ (ale vy si ho pojmenujte jak chcete :-) ). Berte to jako moji náhradu za celý tým, který bych jinak musel zaplatit – seniorní vývojáře, testera, bezpečáka, produkťáka i provozáka. Ale nejdřív si projděme samotné revizory, seskupené do pěti rodin.

Rodina A – Kód: čistý, udržitelný, rychlý

1. refactor check – hledá mrtvý kód, duplicity a zbytečnou složitost, aby kód časem nehnil.
2. coding check – hlídá, že držíme vlastní psané standardy psaní kódu – a zároveň že ty standardy nezastaraly vůči světu venku. Tohle nahrazuje moje vlastní sledování technologických novinek, na které nemám čas ani vzdělání. Nevíte, jak napsat standardy pro technologie, co si Claude vybral pro váš projekt? Prostě mu to zadejte jako úkol: ať stáhne z netu nejlepší doporučené postupy a podle nich standardy nastaví.
3. test check – kontroluje, že testy pokrývají to důležité a nejsou mrtvé nebo vrtkavé (jednou projdou, jednou ne).
4. performance check – hlídá, že aplikace odpovídá rychle a server se nezadýchává – pomalé databázové dotazy, zbytečně velké obrázky, chybějící cache (dočasná paměť pro opakované věci).

Rodina B – Bezpečnost a „co když to spadne“

5. security check – ochrana dat klientů: aby nikdo neviděl cizí data, kontrola toho, co uživatelé posílají dovnitř, ochrana tajných klíčů, obrana proti zneužití AI promptů. Pro mě jedna z nejdůležitějších kontrol – z cca 800 tasků, co jsem vytvořil za první měsíc, byla 1/3 věnovaná security záležitostem.
6. dependency check – knihovny, na kterých aplikace stojí (cizí kód, který nepíšu, ale používám), jsou aktuální a bez známých děr?
7. resilience check – zálohy fungují a jde z nich opravdu obnovit, externí služby jsou správně nastavené, data jsou konzistentní.
8. postmortem check (rozbor po výpadku) – u každého většího výpadku je náprava i prevence reálně dotažená, ne jen slíbená. Zajišťuje, že chyby, co se jednou staly, se už nebudou opakovat.

Rodina C – Srozumitelnost pro uživatele

9. UX check – chybové hlášky, prázdné stavy, tmavý režim, použitelnost na mobilu, jednotný vzhled. Agent sám kontroluje, že je vše sladěné s naší designovou příručkou. To je stránka, kde jsou standardizované všechny prvky v adminu, aby se pro každou stránku nemusely psát nové CSS třídy.
10. language check – čeština a angličtina jsou konzistentní, nikde nezbyl nepřeložený text. Čeština neobsahuje anglicismy.
11. guide check – nápověda a onboarding sedí s tím, co aplikace reálně umí. Agent sám doplňuje nápovědu o všechny novinky, co právě šly do produktu. Btw v Shoptetu jsme na tohle měli fulltime člověka…
12. features check – marketingový výčet funkcí sedí s realitou (nic neslibuju, co appka neumí). Zároveň plní a udržuje aktuální soubor FEATURES.md, kde jsou popsané všechny funkce aplikace, výborné pro marketingové účely.
13. news check – novinky pro uživatele jsou kompletní a dobře napsané. Zase – agent píše novinky do administrace sám, podle toho, jaké nové funkce se přidaly.

Rodina D – Reální zákazníci a peníze

14. customers check – tahle běží nad živými daty: nečerpá někdo něco, co nehlídáme? Nejsou problémy s platbami? Jak jsou na tom uživatelé ve zkušebním období? Stojí ve vlastní rodině schválně – je to jediná kontrola, která sahá na živá data reálných platících zákazníků, ne jen na kód.

Rodina E – Kontrola sebe sama

15. logical check – pravidla, paměť a procesy si neodporují, nezastaraly, nejsou mrtvé. Jinými slovy: pravidlo, co hlídá pravidla. Je to jediná metaúrovňová kontrola, dohlíží na celý zbytek systému, ne na produkt.

Obsah zadání jednotlivých checků je samozřejmě mnohem více detailní, ale na to tady není prostor. Když Claudovi řeknete, tak vám určitě základní nástřel navrhne a pak to již jen budete ladit dál sami.

Pojďme se podívat, co reálně chytly, protože teorie je hezká, ale důvěru dělají nálezy.

Bezpečnostní kontrola jednou odhalila, že data z externího zdroje tekla rovnou do AI bez filtru – přesně ten typ díry, kterou bych sám v životě nenašel. A našla i webhook (automatické volání mezi službami), který se při výpadku choval nebezpečně. Kontrola nápovědy našla místa, kde nápověda tvrdila uživatelům něco jiného, než aplikace doopravdy dělala. A velký výkonový audit našel naráz desítky věcí: rozpoznání mince z fotky drželo obslužný slot deset až třicet sekund (což by pod zátěží položilo server), tiskový export portfolia dělal tisíce databázových dotazů místo pár, a součet paměťových stropů překračoval paměť serveru – tikající bomba.

Žádnou z těch věcí bych nenašel sám. Ne proto, že bych byl úplný idiot (duh), ale proto, že nečtu kód a nevím, kde se taková věc schovává. Patnáct revizorů ano. Za 200 dolarů za měsíc… Tvl…

Jak funguje mega kontrola (a proč je to ta hlavní páka)

Když spustím mega kontrolu, neproběhne to jako jeden dlouhý seznam, který odšrotuje jeden přetížený mozek. Funguje to chytřeji – a tu souběžnou organizaci zařizuje sám nástroj, ne já ručně. Já napíšu jeden příkaz, zbytek si nástroj zorganizuje.

Běží ve třech řízených vlnách. Nejdřív nezávislé čtení (revizoři, kteří si jen načítají stav), pak kontroly, které na to čtení navazují, a nakonec testy. Uvnitř každé vlny běží revizoři současně, vedle sebe.

Každá kontrola je vlastní čerstvý agent (samostatná instance AI s vlastní čistou pamětí). A tohle je ten klíč. Vzpomínáte na pilíř 2, kde jsem psal, že dlouhé vlákno zašumí kontext a tým se v něm utopí? Tady to řeším u kořene: každý z patnácti revizorů dostane čerstvou hlavu, čistý kontext, žádnou únavu. Neztratí se ke konci dlouhého běhu, protože pro něj žádný dlouhý běh neexistuje – vidí jen svůj jeden úkol.

Je autonomní, ale s brzdou. Drobné, stoprocentně jisté opravy (překlep v komentáři, mrtvý kus kódu) si revizor udělá sám, neotravuje mě s tím. Ale cokoli, co mění chování produktu, smí jen navrhnout jako úkol – nikdy to potichu nezmění. V takových případech sám založí task v ClickUpu. Tým má volné ruce na úklid, ale na produkt musí mít moje svolení. (Vidíte tu pravidlo z pilíře 1 v akci.)

Výstup je laický. U každého nálezu dostanu tři bloky: k čemu ta věc slouží, co je problém, co s tím. Plus odhad rizika a času. A je to seřazené od nejpalčivějšího dolů, takže hned vím, co řešit první.

Nevymýšlí si nálezy. Když je čisto, řekne, že je čisto. A navíc vypíše i to, co kontrola hledala a nenašla – abych věděl, že se na to fakt dívala a jen nemlčí proto, že byla líná. (Opět: krotíme tu třetí nebezpečnou vlastnost.)

A na konci se ptám i sám sebe: „Nechybí nám nějaká kontrola?“ Soustava není zamrzlá – roste s tím, jak se mění produkt. Adaptuje se na nové situace a vymýšlí nové kontroly, pokud jsou potřeba.

Proč je tohle ta hlavní páka celého systému? Protože násobí čtyři věci, které se normálně vylučují: šíři (patnáct různých úhlů pohledu), pravidelnost (spustím to kdykoli a celé), čerstvý mozek na každý úhel (nikdo není unavený, nikdo se neztratí v dlouhém vlákně) a autonomii bez rizika (úklid sám, produkt jen s mým svolením). A nad tím vším je sebekontrola: jedna z patnácti kontrol hlídá samotná pravidla a paměť, a navíc celou soustavu jednou za čtvrt roku audituje nezávislá externí AI úplně zvenku, která do projektu nevidí zevnitř a nekouká na cizí práci se zalíbením.

Jak si to nastavit sám: Nemusíte mít hned patnáct kontrol. Začněte třemi, které vás nejvíc pálí – skoro u každého placeného produktu to bude bezpečnost (tohle by měla být vaše priorita neustále), výkon a třeba soulad nápovědy s realitou. Každou napište jako samostatné zadání. Klidně si ho zkopírujte, takhle vypadá ten nejjednodušší: „Jsi specialista na bezpečnost. Projdi celý projekt z pohledu bezpečnosti dat a zneužití. Drobnosti, u kterých máš stoprocentní jistotu, oprav. Větší věci jen navrhni jako úkol, nesahej na ně. Když je čisto, řekni to a vypiš, co všechno jsi kontroloval.“ Pak je naučte spouštět najednou – a nemusíte přitom řešit žádnou techniku okolo. Stačí vytvořit ještě jednu kontrolu (třeba /vse), do které napíšete prostou větu: „spusť postupně všechny moje kontrolní skilly a výsledky mi shrň na jedno místo.“ Složitější souběžné běhání si pak můžete nechat od AI doladit, až budete chtít. A pravidelnost je důležitější než dokonalost – tři kontroly spouštěné každý týden jsou cennější než patnáct, které spustíte jednou za rok.

A teď trik, který tu vstupní bariéru sráží úplně k zemi: když nevíte, jak takovou kontrolu vůbec napsat, nechte to napsat samotnou AI. Nemusíte to vymýšlet z hlavy. Řekněte jí v základu, co chcete – „chci kontrolu, která projde celý projekt z hlediska bezpečnosti dat a upozorní mě na díry“ – a nechte ji, ať vám tu instrukci sama navrhne. Většinou ji navrhne překvapivě dobře, často líp, než bych ji napsal já, protože ví, na co se u bezpečnosti běžně kouká. Vy ji jen přečtete, schválíte, nebo doladíte vlastními slovy („přidej ještě, ať hlídá platby“). A tohle platí pro celý systém, ne jen pro kontroly: nevíte, jak něco zadat nebo sepsat – pravidlo, kontrolu, ranní briefing? Nechte si to nejdřív navrhnout od AI a pak to upravte k obrazu svému. Čistý list papíru je nepřítel; rozumný první návrh, který jen škrtáte a doplňujete, je o řád snazší.

Pilíř 4: Další záchranné sítě

Kontroly jsou plánovaná obrana. Ale chyba se neptá na rozvrh, takže potřebujete chytat i mimo ně. Proto mám v záloze další pravidla.

Boy scout pravidlo

Pokaždé, když tým sáhne na nějaký kus kódu kvůli něčemu jinému, rovnou po sobě uklidí drobnost, na kterou narazil. Kód díky tomu nehnije postupně, ale průběžně se čistí jakoby mimochodem. Skautský princip „odejdi z tábořiště čistší, než jsi ho našel“ se tady používá pro samokontrolu a průběžné začisťování kódu, o kterém pak ani nevíte.

Round table a křížová kontrola

U větších věcí nechám na jeden problém pohlédnout víc nezávislých mozků, ne jen jeden. Funguje to u mě na dva způsoby.

Tomu prvnímu říkám „kulatý stůl“ (round table) a je to prostě příkaz. Když ho spustím, nevznikne jeden revizor, ale rovnou celý panel specialistů na tutéž věc – a každý se na ni dívá z jiné strany. Vezměte si bezpečnost. Místo jednoho mlhavého „zkontroluj bezpečnost“ se na projekt naráz vrhne několik odborníků: jeden zkoumá přihlašování a kdo se kam dostane, druhý to, co uživatelé posílají dovnitř (jestli se tím nedá aplikace rozbít), třetí možné úniky citlivých dat, čtvrtý zneužití AI. Každý nahlásí svoje a jejich pohledy se nakonec sejdou u jednoho stolu a porovnají – jako kdybych si k jednomu problému pozval celou místnost expertů místo jediného. Víc úhlů chytí víc věcí: co přehlédne jeden, najde druhý. Přesně takhle vznikl i ten velký výkonový audit, co naráz odhalil desítky problémů.

Ten druhý způsob je křížová kontrola jiným nástrojem, a tady chci být konkrétní, protože je to jedna z nejcennějších pojistek v celém systému. Celý produkt píšu v Claude Code, nástroji od Anthropicu. To, co Claude Code napíše, pak nechávám křížově zkontrolovat v OpenAI Codexu, nástroji od OpenAI. Schválně dva různé modely od dvou různých firem – mají totiž různé slepé skvrny a, což je možná ještě důležitější, nejsou zamilované do stejného řešení. Model má tendenci být na svou vlastní práci shovívavý; cizí model takový ohled nemá. Když se oba shodnou, mám větší klid. Když Codex u Claudovy práce něco vytkne, vím přesně, kam se podívat. Je to levné, rychlé a chytá to věci, do kterých je první model zahleděný. Oba mají sdílenou složku, kde se můžou hádat. A přiznám se, občas cítím určitý osten žárlivosti u Clauda, že mu nedůvěřuji :-).

Je to tentýž princip jako ta čtvrtletní externí revize z pilíře 3 – jednou ve velkém na celý systém, tady průběžně v malém na jednotlivé kusy práce.

Automatické testy

Mám kolem tří tisíc automatických testů, které pokrývají to podstatné napříč aplikací. Jsou skvělé. A spustí se při releasu každé nové featury. Jsou nutné, ale samy o sobě nestačí – a mám na to čerstvou jizvu.

Stalo se tohle: přechod na Premium (placenou verzi) přestal všem uživatelům fungovat kvůli drobné změně v platební bráně. A tři tisíce testů to nechytly – protože testy si platbu jen „hrály“ v zástupné, simulované podobě, zatímco naživo se brána zachovala jinak. Chytla to až realita, tedy ten naštvaný moment, kdy někdo nemohl zaplatit. Pár dní mi tiše padaly všechny pokusy o platbu a já o tom nevěděl, protože všechno svítilo zeleně.

Tohle je přesně důvod, proč testy nestačí a proč pořád validuju vlastníma očima a rukama v prohlížeči. Test ověří, že kód dělá, co jste mu řekli. Neověří, že jste mu řekli to správné, ani že se vnější svět chová podle vašich představ.

Jak si to nastavit sám: Vynuťte si skautské pravidlo jednou větou v ústavě projektu („při doteku kódu ukliď drobnost, na kterou narazíš“). U důležitých věcí si nechte práci přečíst druhým modelem – konkrétně: spusťte nad toutéž složkou projektu druhý AI nástroj od jiné firmy (např. ten OpenAI Codex) a řekněte mu prostou větou „projdi v této složce poslední změnu, kterou udělal jiný AI nástroj, a najdi v ní chyby“. Je to další předplatné, ale levné – počítejte s ním jako s drobnou položkou navíc, ne jako s dalším velkým nákladem. Stojí to pár minut a chytne to slepá místa, která vlastní model nevidí. A nikdy nevěřte zeleným testům jako jedinému důkazu. Zvlášť tam, kde tečou peníze nebo se mluví s cizí službou, klikněte si to nakonec sami.

Pilíř 5: Bezpečná půda pod nohama

Některá chyba projde všemi kontrolami výše. Pátý pilíř je o tom, aby vás nepoložila.

Verzování jako velké tlačítko zpět. Všechno, co se v kódu změní, se dá vrátit do předchozího stavu. Tohle není detail, tohle je psychologický základ celé mé odvahy. Technicky se tomu říká Git a v praxi to znamená, že AI po každé změně uloží snímek stavu, ke kterému se dá vrátit – přesně ty commity, o kterých byla řeč. Nemusíte to nijak zapínat ručně: stačí na začátku říct AI „založ mi projekt s verzováním a hlídej, ať po každé změně udělá commit“, zbytek řeší sama. Právě proto, že vím, že každý experiment jde vrátit jediným krokem zpět, si můžu dovolit nechat tým zkoušet odvážné věci. Bez bezpečné sítě bych se bál cokoli pustit.

Nasazení je vědomý krok, ne automat. To, že je něco hotové a otestované, ještě neznamená, že to tím pádem letí k uživatelům. Nasazení do produkce je samostatné, vědomé rozhodnutí, které dělám já. Žádné „samo se to vystrčilo ven“.

Soukromá data oddělená. Citlivé věci (moje sběratelská data, certifikáty, ceny) žijí mimo kód, nikdy se nepletou do něčeho, co by se mohlo omylem zveřejnit.

Zálohy a pravidelná zkouška obnovy. Data se zálohují denně – samozřejmost. Důležitější je to, co dělá málokdo: každý týden se ta záloha sama nanečisto obnoví a otestuje – běží to automaticky, já jen dostanu výsledek. Protože nevyzkoušená záloha je k ničemu – je to jen soubor, o kterém doufáte, že funguje. A jestli nefunguje, zjistíte to přesně ve chvíli, kdy ji nejvíc potřebujete.

Jak si to nastavit sám: Tři věci, žádná není volitelná. Verzování od první minuty – stačí AI na začátku říct, ať projekt založí s verzováním a po každé změně udělá commit; dá vám to odvahu experimentovat. Oddělené nasazení, abyste rozhodovali vy, co a kdy jde ven. A zálohy, které pravidelně nanečisto obnovíte – jinak nevíte, jestli vůbec fungují.

Pilíř 6: Provoz a paměť

Pět pilířů výš řešilo práci samotnou – jak stavět a jak to hlídat, když u toho jsem. Šestý řeší, co se děje, když nepracuju – co tým pamatuje a hlídá, zatímco se věnuju něčemu jinému. Tady totiž ta první nebezpečná vlastnost (AI si nic nepamatuje) udeří nejtvrději, takže paměť musí žít mimo ni.

• ClickUp drží úkoly a dlouhodobou paměť backlogu – co je hotové, co se odložilo, proč.

• Notion drží byznysovou a produktovou znalost – persony, positioning (jak se vůči trhu vymezujeme), messaging (jak o produktu mluvíme). Věci, které nepatří ke kódu, ale tým je musí znát, aby nestavěl naslepo.

• Skilly z pilíře 3 – ty zabalené opakovatelné postupy. Když nějakou věc dělám pořád stejně, zabalím ji do návodu, který tým spustí na povel a vždycky stejně.
• Paměťové soubory drží fakta napříč sezeními – to, co se AI normálně „odpamatuje“ mezi konverzacemi, mám zapsané, aby to platilo i zítra. Vzniknou jednoduše: řeknu AI „tohle si zapamatuj natrvalo“ a ona si to sama uloží do relevantního souboru, který čte na začátku každé konverzace – stejně jako tu ústavu z pilíře 1. Plus ta základní pravidla (.md soubory) vám Claude založí v hlavní složce sám.
• Ranní briefing mailem a Sentry (služba, která hlásí chyby z provozu). Aplikace mi každé ráno sama pošle mail, jak se má – co se děje, jestli něco neskřípe. Je to naplánovaná úloha, která proběhne sama a odešle mail přes službu na odesílání pošty – dá se to postavit jedním zadáním pro AI, není to žádný drahý firemní dohledový systém. O problému se chci dozvědět dřív od svého vlastního systému než od naštvaného uživatele. Díky tomu mám provoz pevně v rukou – ne aby mě dohnal problém, o kterém ani nevím.

Jak si to nastavit sám: Vyberte si jedno místo na úkoly a jedno na byznysovou znalost a důsledně do nich pište – protože co není zapsané, to pro AI zítra neexistuje. A zařiďte si, aby vám produkt sám hlásil, jak se má, ať to nemusíte hlídat ručně. I jednoduchý denní mail „všechno běží / tohle skřípe“ je obrovský rozdíl proti tomu zjišťovat problémy ze stížností.

Dobrou noc

A jeden rituál navíc, který tu paměť a dokumentaci drží aktuální, místo aby zastarávaly: večerní uzávěrka, které říkám „dobrou noc“. Na konci práce napíšu týmu jediné slovo – „dobrou noc“ – a on provede uzávěrku, jako když na konci směny někdo poctivě zavře krám. Projde, co jsme ten den udělali, ověří, že je všechno uložené a otestované a nezůstalo nic rozdělaného v půlce, zkontroluje, že texty pro uživatele sedí v češtině i angličtině, a sám doplní nápovědu k tomu, co během dne přibylo. A moje oblíbená část: sám sepíše a rovnou do aplikace vloží novinky pro uživatele – ten seznam „co je nového“, jaký každý zná z appek na telefonu. Přesně tohle je práce, kterou by člověk na konci dlouhého dne odbyl nebo odložil na neurčito – a právě proto je k nezaplacení, že se děje sama, vždycky stejně a na jeden povel. Den nekončí tím, že zaklapnu notebook uprostřed nepořádku, ale čistým, zdokumentovaným stavem, na který druhý den navážu.

Není to hra pro snowflakes

Abych nemaloval příliš růžový obrázek a vy pak nenarazili: tohle nestojí jen na nadšení. Dělal jsem na tom měsíc prakticky na plný úvazek, řádově 10–12 hodin denně – každý jeden den. Ale bavilo mě to. Byl jsem jak dítě (produkťák) zavřený přes noc v hračkářství. Konečně jsem dostal do ruky svoji kouzelnou hůlku a nebyl ničím limitovaný.

Musíte umět produktově myslet, tedy vědět, co stavíte a proč – to za vás AI nerozhodne. Musíte být ochotní se naučit ovládat ten nástroj, což pár dní až týdnů zabere. A hodně pomůže základní orientace v IT konceptech: vědět zhruba, co je databáze, co je server, co je cache a její invalidace, a aspoň trošku chápat, jak probíhají hackerské útoky. Kdo začíná úplně od nuly, zvládne to taky, ať ale počítá s delším rozjezdem. Shrnuto: nepotřebujete umět programovat. Potřebujete umět přemýšlet a vydržet se učit – a věřím, že vám tenhle článek tu cestu pořádně zkrátí. Já bych za něj před dvěma měsíci byl strašně vděčný.

Moje největší výhoda ale nebyla technická – byla produktová, a bez ní by ten systém nevznikl. Tu základní IT orientaci jsem si sice přinesl z předchozí firmy, ale to hlavní bylo něco jiného: v Shoptetu jsem řídil produkt až do konce – i jako CEO jsem se o něj staral a nikdy se od něj neodtrhl – a k tomu mám roky zkušeností z projektového řízení, z dotahování věcí do konce. Přesně díky téhle kombinaci jsem věděl, které věci se u placeného produktu prostě musí udělat a pohlídat: bezpečnost dat, zálohy, výkon pod zátěží, srozumitelnost pro uživatele, konzistence. Věděl jsem, CO tam musí být – i když jsem netušil, JAK se to technicky udělá.

A to je celá pointa: pravidla a kontroly, které jsem v tomhle článku popsal, nejsou destilátem technické znalosti. Jsou destilátem produktové a projektové zkušenosti. Nepsal jsem je jako programátor. Psal jsem je jako produkťák, který za ty roky ví, co se u živého produktu nesmí zapomenout – a tu znalost jsem jen přeložil do pravidel a kontrol, které za mě hlídá tým. Když nevíte JAK, ale víte CO musí být ohlídané, máte hotovou půlku práce. Tu druhou půlku, to „jak“, dnes umí AI.

Ven z temnoty

Vrátím se k tezi z úvodu, protože o ni celou dobu jde. Postavil jsem si samoudržovací model, který dělá dvě věci najednou: odstraňuje moji největší slabinu – nejsem programátor a kód nepřečtu – a zároveň posiluje to, v čem jsem dobrý – produktové myšlení, rozhodování, prioritizace, cynický pohled na rozsah. Pravidla, kontroly a paměť dělají práci, kterou bych jako neprogramátor nikdy nezvládl. Já dělám práci, kterou žádná AI neudělá za mě: rozhoduju, co je správně, a nesu za to odpovědnost.

Protože to je ta nepřekročitelná hranice. AI nenahradí váš úsudek a vaši odpovědnost. Sebelepší tým potřebuje někoho, kdo ví, kam jde a proč, a kdo si stoupne za výsledek. Ale když kolem toho týmu postavíte správný systém pravidel a kontrol, netechnický člověk dotáhne bezpečný, stabilní a placený produkt sám. Není to teorie. Běží to, platí se za to, a backlog je na nule.

Ten systém jsem nevymyslel přes noc a pořád ho ladím. Ale jádro je jednoduché a dá se okopírovat: berte AI jako tým, dejte mu ústavu, zadávejte mu malé jasné úkoly s důvodem, postavte kolem něj kontroly, mějte bezpečnou půdu pod nohama a pište si, co tým nesmí zapomenout. Začněte třemi pravidly a třemi kontrolami. Zbytek doroste s vámi.

A pak je tu ta matematika, kvůli které možná čtete až sem. Na jedné straně dva miliony korun a půl roku čekání. Na druhé jednotky tisíc korun měsíčně – a pět týdnů do živého provozu. A ať víte, z čeho se ty měsíční náklady skládají, protože pro rozhodnutí „jít, nejít“ je to klíčové: část je pevná (předplatné nástrojů, jednotky tisíc měsíčně, které neutečou), část pohyblivá (AI kredity podle toho, jak intenzivně pracujete a jestli přesáhnete klasické předplatné). V nejdivočejších týdnech, kdy jsem jel naplno, se ta pohyblivá část vyšplhala blíž k hornímu kraji. I tak je ten rozdíl proti dvěma milionům jiný řád, ne pár procent. A to už vůbec nezmiňuji účet 20 mega za původní OutOfDark před 4 roky. Něco co bych si byl schopný udělat nyní za měsíc za 5000 kč. Žijeme v úžasné době.

Poslední věc, a tu myslím vážně. Nic z tohohle není neprůstřelné ani vytesané do kamene. Je to strašně nová oblast a všichni se teprve učíme, jak s tím pracovat – já taky. Sdílím to jako „co funguje mně teď“, ne jako dogma a ne jako poslední slovo. Za měsíc to možná budu dělat trochu jinak, protože se zase něco posune. A přesně proto: jestli stavíte něco podobného a něco vám funguje líp – jiný způsob zadávání, chytřejší kontrola, lepší síť pod nohama – napište mi. Rád se přiučím a svůj proces vylepším. Společně to osaháme rychleji, než kdyby si každý dumal sám ve svém koutě.

A opravdu poslední poslední věc pro statečné mohykány, co si to fakt dočetli do konce :-) – pokud se vám tyto rady hodily pro váš nový projekt, pojďte si koupit nějakou minci k Mincmistrovi a pojďte si ji přidat do OutOfDark – je to vůbec nejstarší a nejelitnější sběratelský koníček a úžasný svět, který vás obohatí intelektuálně i finančně :-).