📌 1. Specifikace zadání a výstupu

To nejdůležitější. Co přesně má vzniknout? Webová aplikace? Mobilní? Pro jaké platformy?
Jaké má mít funkce? Jaké uživatelské role?
Bez detailního popisu (ideálně přílohy s wireframy, funkčním zadáním, případně prototypem) bude jakákoliv reklamace neřešitelná.

📌 2. Termíny – milníky, fáze, testování

Jednoduché „dodání do 3 měsíců“ nestačí.
Doporučuji rozdělit na:

• fáze (např. návrh → vývoj → testování → předání),

• mezivýstupy,

• termíny pro kontrolu a zpětnou vazbu.

Umožní to lépe řídit projekt – a řešit prodlení.

📌 3. Cena a způsob fakturace

• Je cena pevná, nebo odhad dle hodin?

• Platí se záloha? Po fázích?

• Co když se zadání změní?

Bez jasného ujednání hrozí, že jedna strana nebude ochotna platit – a druhá dokončit.

📌 4. Odpovědnost za vady a záruka

• Jak se bude reklamovat chyba?

• Je poskytována záruka (např. 6 měsíců na opravu bugů)?

• Jak rychle musí vývojář reagovat na oznámení vady?

I zde doporučuji konkrétní ujednání. Neexistuje „automatická“ záruka na software.

📌 5. Autorská práva a licence

• Přejdou práva kódu na objednatele? V jakém rozsahu?

• Může vývojář kód znovu použít?

• Je součástí i dokumentace, návrhy, testy?

Bez jasné licenční doložky může mít klient zakázaný zásah do kódu.

📌 6. Ukončení smlouvy

• Lze smlouvu ukončit předčasně?

• Kdy vzniká nárok na úhradu dosavadních prací?

• Co když jedna strana neplní?

Prevence toho, aby strany nezůstaly „v pasti“.

🧱 Příklad z praxe

Start-up si nechal vytvořit aplikaci. Smlouva ale jen v e-mailu – „za 200 000 Kč vytvoříte appku do 3 měsíců“.
Po dodání chyběla většina funkcí, nebylo testování. Objednatel chtěl vrátit peníze, vývojář tvrdil, že vše odevzdal.
Výsledek? Spor bez důkazů, drahý a zdlouhavý. Správně nastavená smlouva by ho přitom zcela eliminovala.