Slotiq
Neveřejný rezervační produkt ve vývoji: návrh zákaznické rezervace, provozní administrace, rolí a kritických stavů.
Projekt v kostce
Kalendář je jen špička rezervačního systému
Slotiq je koncept víceuživatelského rezervačního systému pro provozovny se službami. Projekt zatím není veřejně vydaný; studie proto představuje směr, návrh a ověřované technické základy, nikoli výsledky z provozu.
Zákazník, provozovna a superadmin, každá s vlastními právy a rozhraním.
Přístup k provozním datům je chráněný druhým faktorem a každá změna je dohledatelná.
Zákaznická rezervace a provozní administrace sdílejí typy i doménovou logiku.
Dočasná rezervace termínu znemožní dvojí obsazení i při souběžných požadavcích.
Orientace ve studii
Stav projektu a moje role
Stav projektu
Projekt je stále ve vývoji. Studie proto ukazuje hotové části, návrhová rozhodnutí a otázky, které ještě ověřuji — ne výsledky z veřejného provozu.
Co bylo v mém rozsahu
- Definoval jsem produktový rozsah, cílové provozovny a tři úrovně uživatelů.
- Navrhl jsem zákaznický rezervační průchod od výběru služby po potvrzení.
- Připravil jsem datový model pro provozovny, personál, služby, klienty, rezervace, notifikace a dočasné blokace termínů.
Výchozí problém
Dvojí rezervace, role a provozní výjimky
Rezervační systém není jen kalendář. Musí zabránit dvojím rezervacím, respektovat pracovní dobu, délku služby a provozní pauzy, rozlišit role, bezpečně pracovat s klientskými údaji a zvládnout potvrzení, připomínky, rušení i synchronizaci s externími kalendáři.
Moje uvažování
Nejdřív role a výjimky, teprve pak obrazovky
Projekt jsem rozložil na tři samostatné zkušenosti: jednoduchý rezervační widget pro zákazníka, administraci provozovny a superadministraci celé služby. Ještě před stavbou obrazovek jsem popsal role, datové entity, výjimky a kritické scénáře. Zvláštní pozornost věnuji situacím, které běžný prototyp ignoruje: souběžný výběr stejného termínu, oprávnění zaměstnanců, audit změn nebo pravdivost notifikačních logů.
Řešení
TypeScript monorepo se třemi rozhraními
Technickým základem ve vývoji je TypeScript monorepo. Uživatelská rozhraní vznikají v Reactu a Vite, aplikační rozhraní používá Hono na Node.js a datovou vrstvu Supabase. Návrh počítá s více provozovnami, přepínači funkcí, ověřením přístupu, e-mailovými notifikacemi a napojením na kalendář.
Zajímavosti
Čtyři věci, které kalendář neukáže
Úrovně uživatelů, které vidí stejná data jinak
Zákazník vidí volné termíny a svoje rezervace. Provozovna vidí obsazenost, personál, služby a pravidla. Superadmin vidí provozovny, jejich nastavení a systém jako celek. Nejde o tři sady obrazovek nad jednou databází — jde o tři různé mentální modely téhož. Většina chyb v návrhu vznikla tam, kde jsem si myslel, že jde o totéž jen s jinými právy.
Co se stane, když dva lidé kliknou naráz
Klasická past rezervačních systémů: dva zákazníci otevřou stejný termín, oba vidí volno, oba potvrdí. Řešení je dočasná blokace slotu, která vzniká atomicky — ve chvíli, kdy jeden začne rezervovat, druhý už termín volný nevidí. Vypadá to jako drobnost v jedné funkci, ale ovlivňuje to datový model, stavy rezervace i to, jak dlouho smí být slot držený bez potvrzení.
Proč bezpečnost nebyla položka na konci seznamu
Provozovna má v systému kontakty a historii cizích zákazníků. Dvoufaktorové ověření a auditní stopu jsem řešil brzy právě proto, že doplnit je zpětně by znamenalo sáhnout do každé části aplikace. Je to práce, kterou v demu nikdo neocení a která rozhoduje o tom, jestli je produkt použitelný v reálném provozu.
Dva frontendy, které si nemůžou odporovat
Zákaznická rezervace a provozní administrace sdílejí typy a doménovou logiku v jednom repozitáři. Změna pravidla — třeba jak dlouho drží dočasná blokace — se propíše na obě strany naráz. Cena je vyšší vstupní složitost; nastavení buildů zabralo víc času, než by zabralo napsat dvě oddělené aplikace.
Rozbor řešení
Nejdůležitější části projektu
Každý blok odděluje problém, zvolený směr a konkrétní důsledky pro výsledné řešení. První je otevřený, další lze postupně procházet.
01 Produktový problém Nejtěžší část rezervace není termín, ale pravidla kolem něj +
Salon má jiné otevírací hodiny v pátek, klinika potřebuje mezi zákazníky rezervu na úklid, studio pronajímá dva sály se sdíleným personálem. Kalendář zvládne kdokoliv; produkt vzniká až ve chvíli, kdy systém unese provozní výjimky, aniž by je musel provozovatel obcházet ručně. Právě obcházení systému je nejjistější známka toho, že návrh selhal.
- otevírací doba s výjimkami, ne jen týdenní vzorec
- rezerva mezi rezervacemi jako pravidlo, ne jako ruční blokace
- sdílený personál napříč službami
02 Role a oprávnění Tři mentální modely téhož systému +
Zákazník, provozovna a superadmin nepracují se stejnými daty s jinými právy — pracují s jinou představou o tom, co systém je. Pro zákazníka je to způsob, jak si domluvit termín. Pro provozovnu je to plán dne. Pro superadmina je to soubor provozoven s vlastními pravidly. Návrh podle rolí tenhle rozdíl vytáhne hned; návrh podle obrazovek ho zakryje až do chvíle, kdy je pozdě.
- zákaznická část optimalizovaná na jednu úlohu: domluvit termín
- provozní část optimalizovaná na přehled dne a rychlé zásahy
- superadmin spravuje provozovny, ne jednotlivé rezervace
03 Souběh a stavy Dvojí rezervace jako hlavní technický nepřítel +
Rezervace prochází stavy volný → dočasná blokace → potvrzeno → zrušeno. Dočasná blokace vzniká atomicky, takže dva souběžné pokusy o stejný termín nemůžou oba uspět. Blokace má omezenou platnost — když zákazník proces nedokončí, termín se uvolní zpět. Vypadá to jako detail jedné funkce a ve skutečnosti to určuje datový model.
- atomická blokace slotu při zahájení rezervace
- expirace držených slotů bez zásahu obsluhy
- jasně definované přechody mezi stavy
04 Bezpečnost a technický základ Cizí data znamenají jiná pravidla hry +
V systému jsou kontakty a historie zákazníků třetích stran. Dvoufaktorové ověření pro provozní účty a auditní stopa změn proto vznikly brzy, ne jako doplněk. Technicky jde o TypeScript monorepo se dvěma frontendy, které sdílejí typy a doménovou logiku — díky tomu nemůže jedna strana počítat s jiným pravidlem než druhá.
- dvoufaktorové ověření pro provozní účty
- auditní stopa změn v rezervacích a nastavení
- sdílené typy a doménová logika napříč rozhraními
Architektura
Jak spolu části řešení komunikují
Vyberte vrstvu a podívejte se, co v ní řešení zajišťuje. Mapa ukazuje logiku produktu bez dlouhého seznamu technologií.
Zákaznická část
- výběr služby
- volné termíny
- rezervace
- potvrzení
- zrušení
Provozní administrace
- přehled dne
- personál
- služby a ceny
- otevírací doba a výjimky
- zákazníci
Správa systému
- provozovny
- nastavení a značka
- role a oprávnění
- auditní stopa
Technický základ
- TypeScript monorepo
- sdílené typy
- doménová logika
- atomická blokace slotů
- dvoufaktorové ověření
Produktová rozhodnutí
Volby, které drží projekt udržitelný
U vlastního produktu nestačí vybrat technologii. Důležité je vědět, co tím získám, jaký kompromis přijímám a jestli řešení zvládnu dlouhodobě provozovat.
Nejdřív role a výjimky, teprve pak obrazovky
První pokus vedený návrhem obrazovek skončil zjištěním, že se polovina rozhraní bude muset přepsat pro další typ uživatele. Restart a návrh od rolí stál pár dní a ušetřil týdny. U víceuživatelského systému je pořadí návrhu důležitější než jeho rychlost.
Modularita jako produktové, ne technické rozhodnutí
Provozovna nechce univerzální nástroj, chce svůj. Společný technický základ se svojí značkou, službami a pravidly nahoře dává obojí: udržitelnost pro mě a pocit vlastního systému pro zákazníka.
Bezpečnost brzy, ne na konci
Dvoufaktorové ověření a auditní stopa se do hotové aplikace doplňují draho — dotýkají se každé části. Když jde o cizí zákaznická data, není to funkce k odložení.
Monorepo přes vyšší vstupní složitost
Sdílené typy a doménová logika znamenají, že změna pravidla se propíše na obě strany naráz. Cenou je náročnější nastavení buildů. U projektu jednoho člověka je to hraniční rozhodnutí — rozvádím ho v sekci o kompromisu.
Vývoj v čase
Od kalendáře k systému rolí a stavů
-
Začátek 2026
Nápad, který vypadal na týden práce
Rezervační systém pro menší provozovny zněl jako přehledné zadání: kalendář, volné termíny, potvrzení. Během prvních návrhů se ukázalo, že kalendář je špička ledovce a všechno zajímavé se odehrává pod ní — v pravidlech, výjimkách a v tom, kdo co smí vidět.
-
Návrh rolí
Přepsání zadání po první špatné odbočce
Začal jsem obrazovkami a po pár dnech zjistil, že polovina z nich dává smysl jen zákazníkovi a pro provozovnu se bude muset přepsat. Vrátil jsem se o krok zpět a navrhl nejdřív role, oprávnění a provozní výjimky. Byl to nepříjemný restart a nejlepší rozhodnutí projektu.
-
Stavový model rezervace
Volný, dočasně blokovaný, potvrzený, zrušený
Stavy rezervace jsem navrhl jako samostatný problém, ne jako vlastnost formuláře. Právě tady žije dvojí rezervace, expirace držených slotů a otázka, co se stane, když zákazník zavře prohlížeč uprostřed procesu.
-
Monorepo a sdílená logika
Jeden základ, dvě rozhraní
Zákaznická a provozní část se přesunuly do jednoho repozitáře se sdílenými typy a doménovou logikou. Znamenalo to den navíc na nastavení a od té doby žádnou situaci, kdy by jedna strana počítala s jiným pravidlem než druhá.
-
Současnost
Produkt ve vývoji
Slotiq zatím není veřejně vydaná aplikace. Aktuální práce ověřuje návrh nastavení provozovny, rolí a rezervačního průchodu před jakýmkoliv nasazením.
Proces práce
Jak převádím nápad do funkce
- U víceuživatelského systému začínám rolemi a oprávněními. Dokud nevím, kdo co vidí a smí, nemá smysl kreslit obrazovky.
- Stavy a přechody navrhuji jako samostatný problém. Většina těžkých chyb rezervačních systémů žije právě mezi stavy, ne uvnitř nich.
- Provozní výjimky hledám dřív než šťastnou cestu. Systém, který nezvládne pátek s jinou otevírací dobou, budou lidé obcházet ručně — a tím zmizí jeho hodnota.
- Bezpečnostní požadavky řeším na začátku. U cizích zákaznických dat je zpětné doplňování dražší než původní návrh.
Co jsem se naučil
Poznámky, které si odnáším dál
- Rezervační systém vypadá zvenku jako kalendář, ale kalendář je z celého problému ta nejmenší část. Skutečná složitost je v rolích, výjimkách, souběhu a v tom, co se stane, když dva lidé kliknou na stejný termín ve stejnou vteřinu.
- Role a oprávnění se musí navrhnout dřív než obrazovky. Když jsem to zkusil opačně, zjistil jsem, že polovina rozhraní dává smysl jen pro jeden typ uživatele a pro zbylé dva se musí přepsat.
- Provozovna nechce univerzální systém, chce svůj systém. Modularita proto nebyla technickým rozhodnutím, ale produktovým — společný základ, vlastní značka, služby a pravidla nahoře.
- Bezpečnost není funkce na konci seznamu. Dvoufaktorové ověření a auditní stopu jsem řešil brzy právě proto, že jde o cizí zákaznická data, a doplnit je zpětně by znamenalo sáhnout do každé části aplikace.
Zpětný pohled
Co bych udělal jinak
Postavil jsem to jako monorepo se dvěma frontendy sdílejícími typy a doménovou logiku, což se vyplatilo — změna pravidla se propíše na obě strany naráz. Cena je vyšší vstupní složitost: nastavení buildů a závislostí mi sebralo víc času, než by zabralo napsat dvě oddělené aplikace. U projektu jednoho člověka je to hraniční rozhodnutí a ve chvíli, kdy bych nepočítal se třetím rozhraním, volil bych jednodušší cestu.
Moje role
Za co jsem v projektu odpovídal
Tady odděluji, co jsem v projektu skutečně navrhl, postavil nebo rozhodl. Výsledek je důležitý, ale stejně podstatná je odpovědnost, kterou jsem při cestě k němu převzal.
-
01
Definoval jsem produktový rozsah, cílové provozovny a tři úrovně uživatelů.
-
02
Navrhl jsem zákaznický rezervační průchod od výběru služby po potvrzení.
-
03
Připravil jsem datový model pro provozovny, personál, služby, klienty, rezervace, notifikace a dočasné blokace termínů.
-
04
Navrhl jsem atomický mechanismus blokace slotů, který omezuje riziko dvojí rezervace.
-
05
Řeším oddělení rolí, vícefaktorové ověření, auditní stopu, omezení požadavků a bezpečné zacházení s daty.
-
06
Navrhuji marketingový web, oborové landing pages a white-label podobu produktu.
Výsledek a důkazy
Co je na projektu doložitelné
Rozpracovaný základ víceuživatelské aplikace s odděleným rezervačním a provozním rozhraním.
Detailně popsané hlavní i chybové scénáře před případným produkčním nasazením.
Návrh bezpečnostních a provozních pravidel, který se má ověřit ještě před veřejným vydáním.
Ukázka schopnosti uvažovat současně nad zákaznickou zkušeností, provozem, daty a technickými riziky.
Silné stránky
Kompetence viditelné na projektu
Nástroje a prostředí
Technický a pracovní základ
Relevantní role
Další krok
Hodí se vám do týmu podobný způsob práce?
Rád se rychle ponořím do nového kontextu, položím otázky a pomohu dostat nejasný problém k řešení, které lze vyzkoušet. Hledám dlouhodobou roli, ve které mohu převzít konkrétní odpovědnost a sledovat dopad v čase.