Když klient poprvé přijde s nápadem na webovou aplikaci, téměř vždy předpokládá, že jde hlavně o programování. Přijde se zadáním, vývojář si sedne k počítači a za pár týdnů je hotovo. Realita je jiná — kódování tvoří přibližně třetinu celého procesu, zbytek jsou věci, které bývají stejně důležité a bez kterých by samotný kód nestál za nic. Tenhle článek projde všechny fáze od prvního setkání přes architekturu, design a testování až po spuštění a dlouhodobý provoz.
Fáze 1: Discovery — co chcete a proč
Discovery je nejdůležitější fáze celého projektu. Pokud sem vstoupíte s mlhavým zadáním, vše, co přijde potom, bude stát na špatných základech.
V rámci discovery se řeší:
- Cíl aplikace — co má aplikace dělat, pro koho a proč zrovna teď
- Uživatelé — kdo ji bude používat, jak technicky zdatní jsou, co od ní očekávají
- Rozsah — co je nutné pro spuštění (MVP) a co může přijít later
- Integrace — propojení s existujícími systémy (ERP, CRM, platební brány, API třetích stran)
- Bezpečnostní a regulatorní požadavky — GDPR, oborové normy, interní politiky
Jako klient byste měli přijít připraveni s: popisem problému, který aplikace řeší, přehledem stávajících systémů, se kterými se má propojit, a ideálně s popisem, jak aktuálně daný proces probíhá (i když manuálně). Čím přesněji popíšete "jak to teď děláme", tím lépe.
Discovery trvá typicky 1–3 týdny a výstupem je dokument s požadavky — ne wireframy, ne kód, jen přesný popis toho, co se bude stavět a co ne.
Příklad z praxe: Výrobní firma Kovostav s.r.o. přišla s požadavkem na "portál pro subdodavatele". Po dvou dnech discovery vyšlo najevo, že portál má řešit pět různých problémů najednou — schvalování dokumentů, sledování zakázek, fakturace, docházka a komunikace. Tři z pěti problémů bylo možné vyřešit konfigurací existujícího ERP. Portál se nakonec zaměřil jen na schvalování dokumentů a komunikaci, vývoj byl třikrát levnější a rychlejší, než bylo původně plánováno.
Fáze 2: Architektura a volba technologií
Jakmile víte, co se bude stavět, musíte rozhodnout, jak se to bude stavět. Tohle rozhodnutí ovlivní vývoj na roky dopředu — špatná architektura vás bude pronásledovat každým sprintem.
Co se rozhoduje v architektuře
Databáze: Relační databáze (PostgreSQL, MySQL) pro strukturovaná data s jasnými vztahy. Dokumentové databáze (MongoDB) pro flexibilní schémata. Redis pro cache a session storage. Většina aplikací potřebuje kombinaci.
Backend: Node.js, Python (Django/FastAPI), PHP (Laravel), Go, .NET — každá technologie má silné stránky a záleží na typu aplikace, výkonu, dostupnosti vývojářů a existující infrastruktuře.
Frontend: Server-side rendering (Next.js) pro SEO a rychlé načítání, SPA (React, Vue) pro interaktivní aplikace, nebo kombinace obou přístupů.
Infrastruktura: Vlastní server, cloud (AWS, Azure, Google Cloud), nebo PaaS (Vercel, Railway). Záleží na požadavcích na dostupnost, škálování a rozpočtu.
Praktický tip: Nevolte technologii, která je nejmodernější, ale technologii, na které máte vývojáře a u níž víte, že za tři roky budete schopní najít dalšího. Aplikace se vyvíjí — tým a jazyk zůstávají.
Výstupem architektonické fáze je technická dokumentace — diagram komponent, schéma databáze, popis API a volba zásobníku.
Fáze 3: Design a UX
Design není o tom, aby aplikace vypadala hezky. Design je o tom, aby se dala používat. Špatné UX zkomplikuje přijetí aplikace uživateli víc než jakákoli chyba v kódu.
Fáze designu probíhá v několika krocích:
- Wireframy — jednoduché schematické nákresy bez barev a detailů. Řeší layout, hierarchii informací a tok uživatele.
- Uživatelské toky — mapy, jak uživatel prochází aplikací od vstupu k cíli.
- Mockupy — vizuálně věrné návrhy s barvami, typografií a ikonami, ale stále bez interaktivity.
- Prototyp — klikatelný prototyp, na kterém lze otestovat použitelnost ještě před napsáním řádku kódu.
Tato fáze je momentem, kdy by klient měl být nejvíce zapojen. Je infinitně levnější přesunout tlačítko v mockupu než přepsat hotovou komponentu.
Příklad z praxe: Logistická firma Tranzit CZ požadovala interní aplikaci pro dispečery. V mockupech vypadala hlavní obrazovka přehledně. Při testování prototypu s reálnými dispečery se ukázalo, že dispečer průměrně otevře 12 zakázek za hodinu a potřebuje vidět jejich stav najednou, ne sekvenčně. Přidali jsme tzv. Kanban view dřív, než padl první řádek kódu — ušetřilo to zhruba 40 hodin vývoje.
Fáze 4: Vývoj ve sprintech
Samotný vývoj probíhá v iteracích — sprintech, které trvají typicky 1–2 týdny. Na konci každého sprintu je něco funkčního, co lze vidět a otestovat.
Jak sprint vypadá v praxi
- Plánování — tým vybere z backlogu funkce, které se budou v daném sprintu vyvíjet
- Vývoj — backend a frontend pracují paralelně, průběžně se integrují
- Demo — na konci sprintu klient vidí, co bylo hotové, a dává zpětnou vazbu
- Retrospektiva — tým hodnotí, co šlo dobře a co ne
Jako klient byste měli: být dostupní pro otázky (ideálně do 24 hodin), přicházet na dema připraveni a s kontext, a nesoustředit se na kosmetické detaily v prvních sprintech — ty se řeší na konci.
Klíčové je, že backlog není zákon. Pokud se v průběhu vývoje ukáže, že určitá funkce dává méně smysl než původně, upraví se priorita. Agilní vývoj neznamená chaos — znamená schopnost reagovat na nové informace.
Praktický tip: Chtějte přístup do testovacího prostředí po celou dobu vývoje, ne jen na dema. Čím dříve vidíte reálnou aplikaci, tím dříve odhalíte nesoulad mezi vaší představou a realitou.
Fáze 5: Testování
Testování není finální kontrola před spuštěním. Probíhá průběžně celou dobu vývoje.
Typy testování
| Typ testu | Co testuje | Kdy probíhá |
|---|---|---|
| Unit testy | Jednotlivé funkce izolovaně | Průběžně při vývoji |
| Integrační testy | Komunikace mezi komponentami | Po každém mergi |
| End-to-end testy | Celé uživatelské toky v prohlížeči | Před každým releasem |
| Uživatelské testování | Zda reální uživatelé aplikaci pochopí | Po dokončení UI |
| Bezpečnostní testování | Zranitelnosti, autorizace, injekce | Před spuštěním |
| Výkonnostní testování | Chování pod zátěží | Před spuštěním |
UAT (User Acceptance Testing) je fáze, kdy klient a vybraní klíčoví uživatelé systematicky testují aplikaci oproti původním požadavkům. Trvá typicky 1–2 týdny a je podmínkou pro přechod do produkce.
Příklad z praxe: Účetní aplikace pro firmu FinServis Praha prošla interním testováním bez problémů. Při UAT si finanční ředitel všiml, že import faktur z konkrétního dodavatele generuje duplicitní záznamy kvůli specifickému formátu dat. Problém by se v produkci projevil prvního dne a data by musela být ručně opravována. Odhalit ho v testovací fázi stálo 3 hodiny — opravit ho v produkci by stálo 3 dny a nervový zátřes celého účtárna.
Fáze 6: Nasazení a spuštění
Nasazení není přepnutí jediného vypínače. Je to řízený proces, který minimalizuje riziko.
Co se děje před spuštěním
CI/CD pipeline — automatizovaný řetězec, který při každé změně kódu automaticky spustí testy, sestaví aplikaci a nasadí ji do staging prostředí. Nikdo nedeployuje ručně přes FTP.
Staging prostředí — identická kopie produkce, na které probíhá finální testování. Staging musí mít stejnou konfiguraci, databázové schéma i data (anonymizovaná) jako produkce.
Go-live checklist zahrnuje:
- Záloha databáze před spuštěním
- Připravený rollback plán (jak se vrátit zpět, pokud něco selže)
- Monitorovací nástroje aktivní od prvního okamžiku
- Notifikace pro tým při chybách
- Otestované SSL certifikáty a DNS konfigurace
- GDPR a cookies compliance
Praktický tip: Spouštějte ve čtvrtek ráno, ne v pátek odpoledne. Máte celý den na reakci na případné problémy s celým týmem v dostupnosti.
Fáze 7: Provoz a iterace
Spuštění není konec projektu — je to začátek jeho života. Každá aplikace potřebuje péči po spuštění.
Monitoring sleduje výkon, dostupnost, chyby a chování uživatelů. Nástroje jako Sentry, Datadog nebo vlastní dashboardy dávají okamžitou viditelnost do toho, co se děje.
Bug fixes po spuštění jsou nevyhnutelné. Žádná aplikace není bez chyb — důležité je mít zavedený proces, jak je reportovat, prioritizovat a opravovat.
Iterace přicházejí na základě reálných dat o používání. Funkce, které jste považovali za nejdůležitější, mohou být málo využívané. Funkce, které jste odkládali, se ukážou jako kritické. Data z produkce jsou nejcennějším vstupem pro další rozvoj.
Dobrá aplikace se nikdy nedokončí — jen se přesouvá z fáze "vývoje" do fáze "kontinuálního zlepšování".
Časové a cenové srovnání
Níže je orientační přehled. Skutečné hodnoty závisí na konkrétních požadavcích, integraci s existujícími systémy a zvoleném technologickém zásobníku.
| Typ aplikace | Popis | Délka vývoje | Orientační cena |
|---|---|---|---|
| Jednoduchá aplikace | CRUD, 3–5 obrazovek, jedno uživatelské role | 6–10 týdnů | 150 000–350 000 Kč |
| Středně složitá aplikace | Více rolí, integrace, reporting, notifikace | 3–6 měsíců | 400 000–900 000 Kč |
| Komplexní / enterprise | Komplexní workflow, více integrací, vysoká dostupnost | 6–18 měsíců | 1 000 000 Kč a více |
Tyto ceny zahrnují discovery, design, vývoj, testování a spuštění. Nezahrnují roční provoz, hosting a průběžné iterace po spuštění.
Praktický tip: Podceněný rozpočet je nejčastější příčina neúspěšných projektů — ne špatný kód, ne špatná technologie. Raději aplikaci zmenšete na solidní MVP a iterujte, než přijít s přestřeleným zadáním a nedostatkem peněz v půli projektu.
V BASAD Studios provázíme klienty celým procesem vývoje webových aplikací — od první analýzy přes design a vývoj až po spuštění a provoz. Pokud plánujete webovou aplikaci a chcete vědět, jak na to přistoupit, ozvěte se nám nebo se podívejte na naši službu webové aplikace.