11. 1. 2026

Vibe-code seznamka aneb web si dnes udělá každý. Proč je to pro produkty dobrá i špatná zpráva?

Ano, je to skutečně tady: AI dnes zvládne pomoci postavit web skoro komukoliv. I mně. Otázka je, jestli tím vznikají lepší produkty, nebo jen víc hezkého „šumu“. V tomhle projektu jsem zjistil, že kód už fakt není hlavní bariéra — hlavní je umět vybrat správný problém, definovat hodnotu a bez milosti škrtat scope.

Kontext projektu

Projekt „Seznamka pro dříve narozené“ vznikl jako moje studentská zkouška trendu vibe codingu. Cílem nebylo postavit produkční aplikaci ani ji hned tlačit na trh (to možná až příští semestr). Chtěl jsem hlavně převést nápad do funkčního prototypu co nejrychleji — aby šel sdílet jedním odkazem, proklikat, ukázat lidem a poctivě popsat jako case study.

Současně jsem si chtěl ověřit, jestli s pomocí AI zvládnu dodržet timebox Praxe III (cca 20 hodin) a přitom postavit demo, které nebude působit jako školní hříčka. V rámci experimentu jsem záměrně moc neřešil UX do hloubky a část promyšlenosti funkcí jsem nechal na AI — můj focus byl otestovat potenciál i limity vibe codingu. Nechtěl jsem ale jít cestou hotových nástrojů typu Lovable, kde je kontrola výsledku omezená; chtěl jsem mít možnost sahat do kódu. A té příležitosti jsem si nakonec užil až dost…

Dva koncepty. Jeden časový limit. A první řez do masa.

Jak jsem se do toho pustil? Na začátku jsem měl dva podobné nápady a oba mi zněly „pitchově“ dobře:

Koncept 1: „Tinder, ale pro rozvedené/rozešlé rodiče“
Vychází z mého jednoduchého pozorování: mainstream seznamky (jako Tinder) typicky implicitně sedí na mladší lidi bez dětí, s volnějším režimem (i režimem „F-W-B“)  a menšími logistickými omezeními. Jenže rozvedení rodiče řeší ve vztahu, kromě „chemie“ i dost zásadní další  parametry: režim střídavky, čas, vzdálenosti, opatrnost, bezpečí, mentální kompatibilita dětí. Tady dává „niche“ produkt smysl jako reálná odpověď na jiný životní kontext. Rozvádí se přes 50 % všech manželství (ale koncept není jen pro rozvedené).

Koncept 2: „Seznamka jako Pokémon Go“ – s upozorněním, že je poblíž někdo s matchem)
Tohle byl nápad na nativní appku, který se fakt dobře vypráví. Možná ho ještě zrealizuju 🙂  Ale hrozně špatně se  „jen“ funkčně prototypuje. A ano, vyrobit nativní iOS aplikaci je přeci jen ještě o kus složitější, než web. Každopádně, investoři vítáni, jdeme do toho? 🙂

Nakonec jsem se – po patřičné ChatGPT konzultaci,– rozhodl nakonec rychle: pokud je cílem funkční demo v omezeném čase, nemůžu prostě stavět produkt, jehož hodnota stojí na „hard“ problémech (GPS na pozadí, perimetry, notifikace, anti-stalking pojistky, privacy, okrajové situace – a to ani v demu). Buď to udělat seriózně – nebo je lepší to nedělat vůbec. Tak jo, vyhrál koncept pro rozvedené rodiče (níže vlevo).

Dvě vize, dva světy, jeden časový limit.

MVP není to, co je „malé“. MVP je to, co je„ukázněné“.

Nejdůležitější MVP rozhodnutí nebylo o UI. Bylo o tom, co do produktu spíše rovnou a vědomě nedám.

První rozhodnutí: demo bude bez loginu. Tohle jediné rozhodnutí mi škrtlo obří balík práce bez toho, abych „zabil“ smysl: účty, ověřování, bezpečnost, chat, moderaci, ukládání dat na backend, GDPR peklíčko… a hlavně: minimalizovalo to riziko, že se rozjede nekontrolovatelný scope tvorby.

Dále samotná data profilů jsou seedovaná (statická), volby a „likes“ se ukládají lokálně v prohlížeči. Je to prototyp, ne ready-to-launch platforma. A to je v tomhle kontextu v pohodě – protože pořád ukazuje jádro hodnoty: matching pro specifickou cílovku.

Kompatibilitu potenciálních partnerů jsem zúžil na pár „tvrdých“ faktorů, které dávají smysl právě pro rodiče (a zároveň se dají vysvětlit na jedné obrazovce): děti/logistika, vzdálenost, časová kompatibilita. A stejně důležité: z MVP jsem vědomě vyhodil věci, které zněly lákavě, ale jsou smrtící pro začátečnický prototyp (např. veřejné hodnocení lidí typu „Uber/Airbnb rating“). Nebylo pro demo hodnoty podstatné aneb jak se říká, skvělé nápady má každý, kdo má… (ne, a není to hlava:) No, a pak jsem se tedy pustil do práce…

Na rozdíl od služeb typu Lovable se nezdá, že by byl Cursor srozumitelný "i pro mou mamku".

Vibe coding v praxi: AI ti neodpustí špatně zvolený setup

Pak přišla realita produkční tvorby, a moje neznalost FE kódování. Nezasekl jsem se tak na „těžkém kódu“. Zasekl jsem se na nastavení celého prostředí.

V prvním pokusu integrovaný terminál v Cursoru neměl dostupné npm/npx, takže nebylo možné ani založit Next.js projekt. Oprava byla „nudná“ (Node toolchain), ale přesně takhle umí prototypování pěkně sežrat neználkovi kódu čas: ne detailně řešit algoritmy – ale jak to celé rozchodit.

Jakmile byl můj setup všech nástrojů OK, šel jsem cestou, která maximalizuje rychlost a minimalizuje ruční práci: Next.js (App Router) + Tailwind + shadcn/ui. Cílem nebylo být trendy, ale rychle poskládat seriózní UI, které ale nepůsobí jako úplný hackathon.

Druhá lekce přišla hned poté: při instalaci shadcn/ui to vypadalo, že příkaz „nic nedělá“. Nedělal – protože terminál byl obsazen běžícím dev serverem (npm run dev). V tu chvíli jsem si připomněl jednoduché pravidlo vibe codingu: AI ti urychlí práci. Neuhlídá ti hygienu. Tady jsem litoval, že přeci jen nemám víc zkušeností s front-end vývojem. AI (ChatGPT) si o mě musí myslet, že jsem úplný idi**, ale co už. V některých momentech už jsem jen zoufale prosil „připrav mi celý blok kódu, co jen vyměním“.

Ke konci první fáze (nastavení prostředí k práci) jsem udělal malý „smoke test“: na úvodní stránce jsem pouze importoval a vykreslil jednoduchou komponentu (Button). Ne kvůli designu, ale kvůli ověření, že aliasy, Tailwind a generované komponenty reálně fungují. Tohle je přesně ten typ kroku, který ušetří hodiny později. Jak to vypadalo níže:

Malý krok pro lidstvo... ale můj první button venku online, trubky propojený!

UI směr: trust & calm (ne, žádná srdíčka ani konfety)

Seznamky často prodávají dopamin: rychlost, zábavu, „hunting“. Jenže cílovka 40–60 (a zvlášť rodiče po rozvodu nebo rozchodu) typicky nehledá „zábavu“. Často hledá bezpečí, klid, předvídatelnost a důvěru. Zamkl jsem si proto jednoduchý směr: Trust & Calm. 

  • neutrální barevnost + jeden konzistentní akcent pro primární akce

  • vysoký kontrast textu, jasná typografická hierarchie (jako oči už nemáme nejlepší, co si budeme…)

  • minimum „cute“ prvků (žádná srdíčka, žádné růžové gradienty)

  • dospělá práce s prostorem: více whitespace, klidný rytmus, méně přeplácaných karet profilů

Tenhle krok nebyl ani tak o estetice, jako o celkové důvěryhodnosti. U tohoto typu produktu je „tón“ (UI, copy) součást vnímání bezpečnosti. Zároveň jsem zjistil, že ne, co už  je za „AI hotové a vkusné“, úplně neladí s tím, co si myslím jako designér já. Trochu mi to připomíná některé moje rozhovory s vývojáři v reálném životě…. 

A je to venku! Můj první pokus je online. Ale je to nějaký ošklivý co?
Druhý pokus – promptoval jsem někde, že chci organizovat pohřby?
Třetí pokus: Honzo, už je to dostatečně krásný, že jo? ŽE JO?

Ten moment, kdy se z prototypu stává „produkt“: build, commit, deployment...

Dokud je to na localhostu, je to pořád trochu hra. Jakmile to nasadíš ale ven, začneš vidět, co je rozbité doopravdy… jakmile MVP stabilně fungovalo (landing, nastavení preferencí, matches, likes), uložil jsem si stav jako git commit. Vibe coding bez návratových bodů je ruská ruleta: AI ti občas udělá širokou změnu napříč soubory a je extrémně snadné skončit v nefunkčním stavu.

Následoval deployment na Vercel. A tady jsem zvolil pragmatický detail: nasazení přes Vercel CLI spouštěné pomocí npx (bez globální instalace), abych se vyhnul typickým macOS oprávněním na systémové složky. Teprve když MVP prošlo produkčním buildem (npm run build) a běželo mimo můj počítač, dávalo smysl investovat čas do dalšího „polishe“. Pak jsem připojil vlastní doménu (CNAME v DNS), aby demo působilo portfoliově a mělo stabilní adresu.

Když už jsem byl opravdu zoufalý, instruoval jsem AI přes staré dobré post-its 🙂

UX reality check: první návštěvník nejsi ty

Po nasazení jsem ověřil veřejnou dostupnost klíčových rout (/, /setup, /matches, /likes). A narazil jsem na klasický rozdíl mezi „mám už něco na tomto webu naklikáno“ a „přicházím poprvé“.

Lokálně mi to fungovalo, protože jsem měl v prohlížeči uložené preference. Nový návštěvník ale může vidět zavádějící výchozí stav. Takže jsem doplnil explicitní stavy typu „loading“ a „no preferences“ – aby první dojem odpovídal skutečnému toku a produkt nelhal. Tohle je detail, který se v prototypu často vynechává. A přesně proto pak prototyp působí jako hračka. Také jsem – ukázka níže – odstranil některé „slepé větve“, které mi sice fungovaly, ale celkově zvyšovaly komplexitu jak pro uživatele, tak velikosti kódu.

Práci s "premium" obsahem jsem nakonec do fináního dema vyhodil.

„To už vypadá jako seznamka“: portréty, asset pipeline a jedna Next.js past

Postupně jsem produkt dál zdokonaloval, například jsem nahradil dočasné avatary obličejů fotorealistickými portréty. Nechtěl jsem se spoléhat na externí API ani řešit klíče a billing, takže jsem zvolil robustní přístup: obrázky jako statické soubory přímo v projektu (public/profiles/<id>/1.png). Aplikace si pro každý profil složí cestu z jeho id.

Tohle byl moment, kdy demo konečně přestalo působit jako UI šablona. Lidské tváře jsou v seznamce celý vesmír – bez nich je to jen katalog karet. Samozřejmě to přineslo i další  technickou drobnost: narazil jsem na omezení Next.js next/image u lokálních obrázků v kombinaci s cache-busting. Opravil jsem to konfigurací (images.localPatterns v next.config.ts), aby bylo nasazení stabilní.  Desktopová verze vypadala už docela dobře, tak jsem začal ladit mobil:

Na mobilu jsem musel například uklidit hlavní menu do "hamburgeru" vpravo nahoru
nebo se ošklivě zalamovaly karty.

Co dál (kdyby to mělo být víc než školní demo)?

Největší „win“ pro mě není, že AI mi napsala jakýsi kód. Největší win je, že jsem si v praxi znovu ověřil, kde se prototypy reálně lámou:

  1. MVP není wishlist. Je to ukázněná volba, co prostě teď nebude.

  2. Setup a deployment jsou součást produktu. Když to neumíš nasadit, nemáš prototyp…

  3. AI nehlídá kvalitu kódu, proto jsou  checkpointy/commity bezpečnostním pásem pro „návrat zpět“.

  4. Bez empty stavů prototyp lže. A první dojem je v tomto typu produktu všechno.

  5. „Dospělý“ vizuální tón není méně kreativní. Je to kreativita, která buduje důvěru. Tvůj vkus a představu zatím AI nenahradí.

A ještě jedna nepříjemná pravda, kterou mi tenhle projekt zvýraznil: u seznamky je největší problém vždycky userbase/MAU. Pro školní prototyp to neřeším růstem – řeším tím, že validuju porozumění segmentu a matching logiku. Ale pokud by to někdy mělo být víc než portfolio, tady začíná skutečná hra. 

Další kroky by nebyly „přidat víc featur“. Byly by to věci, které dělají z prototypu testovatelný produkt:

  • upřesnit segmenty a otestovat, jestli zvolené faktory kompatibility odpovídají realitě

  • vyřešit bezpečí a práci s citlivými údaji (ne jako PR, ale jako design constraint)

  • teprve potom login, chat a moderace

  • až úplně nakonec cokoliv „social“ (poradna, sdílení zkušeností…), protože to je další produkt sám o sobě

Cílem bylo postavit funkční demo rychle, se smysluplným product framingem – a tenhle projekt mi to splnil. A navíc mi připomněl větu, kterou si chci nechat někde na očích:

Dobrý produkt nezačíná kódem. Začíná omezením.

No, a teď se můžete konečně podívat na výsledek mého snažení 🙂 aneb happy randění.

PS: kdyby kohokoliv nápad „Seznamky pro starší“ zaujal, můžeme to rozpracovat. Stále jsem přesvědčen, že některé myšlenky tohoto dema mají tržní potenciál.