Jak vybrat dodavatele webové aplikace pro firmu?

Dobrého dodavatele webové aplikace je vhodné posuzovat podle více věcí než jen ceny a portfolia. Měl by pochopit problém firmy, jasně vymezit první etapu, pojmenovat předpoklady a rizika a zapsat, podle čeho obě strany poznají dokončení práce. Před zahájením projektu je také nutné dohodnout vlastnictví kódu a dat, přístup k repozitáři a účtům, způsob testování, převzetí, nasazení, předání a další správy.

Nabídky lze poctivě porovnat až tehdy, když se týkají podobného rozsahu a výsledku. Nižší cena může znamenat menší rozsah, chybějící migraci dat, testy nebo podporu po spuštění. Ani vyšší cena sama o sobě nedokazuje kvalitu, pokud nabídka nevysvětluje, co za ni firma dostane.

Malý a jednoznačný úkol nemusí vždy vyžadovat rozsáhlou analýzu. Pokud ale aplikace zahrnuje více rolí, integrací, výjimek a důležitých dat, rychlý odhad bez doplňujících otázek je důvodem k upřesnění předpokladů.

Nejdříve ověřte, zda dodavatel rozumí problému firmy

První rozhovor by neměl začínat pouze výběrem technologie a seznamem obrazovek. Nejdříve je potřeba určit, kdo dnešní proces používá, kde vznikají zdržení, jaká data jsou potřeba a co má po změně fungovat jinak.

Dobrý dodavatel se ptá například:

• kdo provádí jednotlivé činnosti a kdo rozhoduje;
• ve kterých programech, tabulkách nebo souborech jsou data;
• kde se práce opakuje nebo provádí ručně;
• jaké výjimky se v reálném procesu objevují;
• co musí fungovat v první etapě a co může počkat;
• podle čeho uživatelé a zadavatel vyhodnotí výsledek.

Dobrým signálem je také ochota navrhnout jednodušší řešení. Někdy stačí konfigurace používaného systému, další modul nebo integrace. Pokud dodavatel navrhuje vývoj od nuly bez prověření těchto možností, stojí za to zeptat se, proč jednodušší varianty odmítl.

Pro první rozhovor nepotřebujete technickou specifikaci. Užitečnější je krátký popis problému, dnešního způsobu práce a očekávaného výsledku. Pomůže vám článek Jak popsat potřebný systém bez technické specifikace.

Zjistěte, jak dodavatel pracuje s nejasnostmi

Na začátku nového projektu bývají některé informace neúplné. Firma může znát svůj problém, ale ještě neví, jak má vypadat cílový tok dat, rozdělení oprávnění nebo integrace s používaným programem. Poctivá nabídka by měla oddělit potvrzené požadavky od předpokladů.

Zeptejte se, co dodavatel potřebuje před určením ceny a termínu. Sledujte, zda dokáže pojmenovat:

• rozhodnutí, která je potřeba přijmout před zahájením;
• data a přístupy, které je třeba prověřit;
• předpoklady ovlivňující odhad;
• položky vyřazené z první etapy;
• rizika závislá na externích systémech nebo dodavatelích;
• situace, ve kterých bude nutné rozsah znovu dohodnout.

U jednoduchého úkolu mohou stačit podklady, krátký rozhovor a jasná podmínka převzetí. Při větším počtu procesů, rolí, dat a integrací může dávat smysl samostatná business analýza a stanovení rozsahu MVP. Nemá být povinným doplňkem každé zakázky. Jejím cílem je omezit nejistotu tam, kde by jinak obě strany oceňovaly jiný projekt.

Porovnávejte stejnou první etapu, ne jen částky

Dvě nabídky mohou používat podobné názvy a přitom zahrnovat úplně jinou práci. Jedna může obsahovat migraci dat, testy a nasazení, druhá pouze aplikaci s ukázkovými daty. Před porovnáním ceny proto obě nabídky převeďte na stejný seznam.

Podrobnější vysvětlení rozdílů mezi nabídkami najdete v článku Kolik stojí webová aplikace pro firmu?. Samotná hodinová sazba neříká, kolik práce bude potřeba, co se bude ověřovat a co klient na konci obdrží.

Před podpisem dohodněte vlastnictví kódu, dat a účtů

Vlastnictví a přístupy se často řeší až při ukončení spolupráce. Tehdy je jejich uspořádání nejtěžší. Před zahájením písemně určete:

• kdo a za jakých podmínek získá práva ke kódu připravenému v projektu;
• kde se nachází repozitář a kdo k němu má přístup;
• kdo vlastní doménu, hosting a cloudové účty;
• z čího účtu se platí externí API, e-mail, SMS a další služby;
• jak klient získá export dat a podklady potřebné pro další práci;
• které knihovny, šablony nebo služby mají vlastní licenční podmínky;
• co se stane s přístupy dodavatele po skončení spolupráce.

Nelze předpokládat, že zaplacením faktury automaticky přejdou všechna práva, kód, licence a účty. Rozsah musí být výslovně uveden ve smlouvě.

V Domin Software používáme model, ve kterém klient zůstává vlastníkem domény, hostingu a účtů, které platí. My získáváme dohodnutý přístup potřebný pro práci. Odpovědnost, kód a předávané materiály je přesto nutné určit pro každý projekt zvlášť.

Zeptejte se, jak se budou ověřovat nejdůležitější funkce

Věta „aplikace bude otestována“ je příliš obecná. Kontaktní formulář, import faktur a systém s rolemi, platbami a přístupem k údajům klientů vyžadují odlišné kontroly.

Požádejte o jasné odpovědi na tyto otázky:

1. Které procesy jsou zásadní a jak budou ověřeny?
2. Proběhne převzetí v testovacím prostředí nebo jiným bezpečným způsobem?
3. Jak se prověří role, oprávnění a citlivé operace?
4. Kdo před změnou vytvoří zálohu a je znám postup obnovení?
5. Jak proběhne nasazení a kontrola bezprostředně po spuštění?
6. Co se stane, pokud nasazení nesplní podmínky převzetí?
7. Jak se hlásí chyby a kdo určuje jejich naléhavost?

Také bezpečnost má být popsána konkrétními požadavky a způsobem ověření, ne obecným slibem. OWASP ASVS nabízí požadavky použitelné při návrhu a ověřování zabezpečení webových aplikací. NIST SSDF popisuje bezpečné vývojové postupy, které lze začlenit do používaného způsobu práce. Neznamená to, že každý malý projekt musí zavést celý standard. Hloubka kontroly má odpovídat riziku, typu dat a následkům chyby.

Ověřte komunikaci na konkrétním příkladu

Rychlá odpověď na obchodní poptávku nedokazuje kvalitu komunikace během realizace. Požádejte dodavatele, aby jednoduchým jazykem vysvětlil jednu důležitou část nabídky, například převzetí, riziko integrace nebo rozdíl mezi první etapou a dalším rozvojem.

Sledujte, zda dodavatel:

• shrnuje dohody a upozorňuje na chybějící rozhodnutí;
• vysvětluje důsledky volby místo pouhého výčtu technologií;
• dokáže říct, co zatím neví;
• rozlišuje chybu od změny rozsahu;
• určuje rozhodující osoby a způsob schvalování změn;
• stanovuje, jak často bude informovat o postupu.

Dobrá komunikace neznamená vyhýbat se nepříjemným informacím. Odpověď „Toto zatím neumíme spolehlivě ocenit, dokud neprověříme formát dat a dokumentaci API“ je užitečnější než přesné číslo založené na domněnkách.

Portfolio má ukázat způsob práce, ne jen vzhled

Snímek obrazovky dokazuje, že existovalo nějaké rozhraní. Neříká ale, jaký problém dodavatel vyřešil, za které části odpovídal ani zda se systém stále používá. V případové studii hledejte zvlášť popsaný problém, rozsah práce, omezení a ověřitelný výsledek.

Podobnost procesu může být důležitější než stejný obor. Zkušenost s rezervačním systémem může být užitečná pro projekt s více rolemi, kalendáři a vyúčtováním, i když nový klient působí v jiném odvětví.

Naše realizace ukazují různé typy složitosti:

• 44Islands představuje rezervační proces a systém rozvíjený po etapách pro různé role;
• HUB.ITM.PL představuje historický projekt mapování dat z různých účetních programů do formátu EDI++;
• HUB-2-API představuje historický tok produktů, nabídek na eBay.de, objednávek a API pro tři klienty ve Francii.

HUB.ITM.PL a HUB-2-API se už produkčně nepoužívají. Dokládají dřívější práci s daty, integracemi a procesy, ne současnou dostupnost zapojených externích služeb. Podobná omezení je vhodné sledovat v každém portfoliu.

Dohodněte předání a správu ještě před zahájením projektu

Převzetí fungující aplikace neřeší všechny povinnosti. Je potřeba určit, co klient dostane na konci etapy a kdo se bude o řešení starat později.

Předání může zahrnovat:

• přístup k repozitáři a odpovídající verzi kódu;
• návod ke spuštění a popis důležitých závislostí;
• přístupové údaje předané bezpečným kanálem;
• seznam externích služeb a termínů jejich plateb;
• kopii nebo export dat v dohodnutém rozsahu;
• výsledky převzetí a seznam známých omezení;
• informace o zálohách, monitoringu, aktualizacích a hlášení chyb.

Správa může být součástí projektu, samostatnou smlouvou nebo prací objednávanou podle potřeby. Neexistuje jeden model vhodný pro všechny firmy. Pojmy jako doba reakce, servisní hodiny a zahrnuté aktualizace musí mít konkrétní význam. Chcete-li oddělit vývoj od následné péče, podívejte se na správu aplikací a e-shopů.

Varovné signály, které vyžadují další otázku

Jeden varovný signál nemusí dodavatele automaticky vyřadit. Měl by ale vést ke konkrétní otázce. Buďte opatrní, když:

• se úplná cena a termín objeví před prověřením rolí, dat, integrací a výjimek;
• je zvolená technologie představována jako záruka bezpečnosti nebo škálovatelnosti;
• nabídka neurčuje vlastnictví repozitáře, dat a účtů;
• rozsah nemá podmínky převzetí ani výslovná vyloučení;
• není jasné, jak bude řešení testováno a nasazeno;
• portfolio nevysvětluje, co daná firma skutečně provedla;
• pravidla změn, oprav, správy a ukončení spolupráce jsou nejasná;
• dodavatel tlačí na rychlý podpis před vyjasněním základních předpokladů.

Rizikem není samotný rozdíl v názorech ani potřeba další analýzy. Větší problém nastává, když důležité otázky zůstanou bez odpovědi a obě strany předpokládají, že rozsahu rozumějí stejně.

Co připravit pro první rozhovor s dodavatelem?

Nemusíte začínat dlouhou specifikací. Připravte podklady, které ukazují skutečný problém:

1. jednu větu popisující situaci a očekávaný výsledek;
2. dnešní způsob práce a zúčastněné osoby;
3. hlavní zdroje dat, systémy a potřebné integrace;
4. tři priority první etapy;
5. omezení termínu, rozpočtu nebo stávající infrastruktury;
6. příklady neobvyklých případů a výjimek;
7. osobu, která může rozhodovat;
8. ukázkové materiály bez hesel, klíčů a skutečných dat klientů.

Můžete využít bezplatný Tvůrce projektového zadání. Provede vás hlavními otázkami a připraví uspořádané shrnutí pro další rozhovor. Nástroj projekt automaticky neodesílá a nenahrazuje analýzu většího rozsahu.

Nejčastější otázky

Potřebujeme před výběrem dodavatele hotovou technickou specifikaci?

Ne. Na začátku stačí popis problému, dnešního procesu, uživatelů, dat a očekávaného výsledku. Technická specifikace může vzniknout později, až bude řešení a rozsah lépe rozpoznán.

Je lepší freelancer, malá firma nebo software house?

Neexistuje jedna odpověď. Záleží na velikosti projektu, riziku, potřebné dostupnosti, specializaci a komunikaci. Důležitější než označení modelu je vědět, kdo práci skutečně provede, co se stane při jeho nedostupnosti a jak se předá kód a znalost systému.

Jak porovnat dvě nabídky aplikace s různým rozsahem?

Nejdříve porovnejte výsledek první etapy, funkce, role, data, integrace, testy, nasazení a vyloučené položky. Až potom posuzujte cenu. Pokud rozsahy nelze převést na společný seznam, požádejte dodavatele o upřesnění.

Kdo má vlastnit kód, repozitář a data?

Podmínky mají být jasné a zapsané ve smlouvě. Zadávající firma by měla alespoň vědět, kde jsou kód a data, kdo k nim má přístup, jaké licence platí a jak po skončení spolupráce získá potřebné materiály. Samotné zaplacení etapy tato ujednání nenahrazuje.

Je placená analýza před odhadem vždy nutná?

Ne. Jednoduchý úkol s jasným výsledkem lze často ocenit podle krátkého popisu a podkladů. Samostatná analýza dává smysl, pokud rozsah podstatně ovlivňuje více procesů, datových zdrojů, rolí, integrací a nejasností.

Na co se ptát ohledně testů a bezpečnosti?

Zeptejte se, které procesy budou ověřeny, kde proběhne převzetí, jak se zkontrolují role a citlivé operace, kdo vytvoří zálohu a jak bude probíhat bezpečné nasazení. Hloubka testů má odpovídat riziku projektu.

Co má být předáno po skončení projektu?

Záleží na smlouvě, ale obvykle je vhodné dohodnout přístup ke kódu a repozitáři, návod ke spuštění, informace o závislostech a externích službách, export dat, výsledky převzetí a známá omezení. Důležitý je také bezpečný způsob předání přístupů a jejich pozdější odebrání dodavateli.

Musí být správa aplikace součástí stejné smlouvy?

Ne. Správa může být součástí projektu, samostatnou službou nebo může přejít k jinému dodavateli. Před spuštěním je však potřeba určit, kdo odpovídá za monitoring, zálohy, aktualizace, incidenty a komunikaci s poskytovateli infrastruktury.

Dejte všem dodavatelům stejný výchozí bod

Začněte problémem, prvním potřebným výsledkem a hlavními omezeními. Pomocí Tvůrce projektového zadání připravte jedno shrnutí pro všechny porovnávané dodavatele. Každý rozhovor tak začne stejnými informacemi.

Pokud hledáte dodavatele aplikace na míru, prohlédněte si vývojářské služby PHP a Laravel od Domin Software. Po přečtení popisu můžeme říct, zda stačí krátký rozhovor a malá etapa, nebo zda má nejdříve proběhnout samostatná analýza. Úplnou cenu a termín neuvádíme bez znalosti rozsahu, dat, integrací a způsobu převzetí.

Zdroje

• OWASP Application Security Verification Standard, OWASP, stabilní verze 5.0.0 publikovaná 30.05.2025, přístup ověřen 30.10.2026.
• NIST SP 800-218: Secure Software Development Framework (SSDF) Version 1.1, National Institute of Standards and Technology, publikováno v únoru 2022, přístup ověřen 30.10.2026.