Kdy custom systém dává smysl — a kdy ne

Ne všechno potřebuje vlastní kód

„Postavíme si to sami“ zní atraktivně. Vlastní systém slibuje kontrolu, diferenciaci a „přesně podle nás“. Stejně často ale vzniká drahý klon toho, co už umí hotový nástroj — jen s horší údržbou a bez roadmapy.

Rozhodnutí custom vs. hotové nestojí na tom, co je moderní. Stojí na provozu, kapacitě a konkurenční výhodě.

Kdy custom systém dává smysl

Custom (nebo silně přizpůsobená platforma) dává smysl, když:

1. Proces je vaše konkurenční výhoda — ne obecná administrativa.
2. Hotové nástroje vás nutí měnit provoz tak, že ztrácíte výkon nebo kvalitu.
3. Potřebujete propojit systémy, které spolu nemluví, a integrace je součást produktu.
4. Máte (nebo budete mít) vlastníka kódu, dokumentace a provozu.
5. Umíte říct, co v první verzi nebude — a přežijete to.

Příklad: personalizovaná výroba a e-shop, kde každá objednávka nese unikátní data. Krabicový shop ušetří týden na začátku a stojí měsíce na provozu. Viz Baby Naty.

Kdy custom nedává smysl

• Problém vyřeší konfigurace existujícího nástroje.
• Cíl je jen „mít něco online“ bez provozního plánu.
• Nemáte kapacitu udržovat vlastní kód (ani s dodavatelem v Care režimu).
• Chcete custom primárně proto, že „to tak má konkurence“.
• Scope je mlhavý a roste s každou schůzkou.

V těchto případech je poctivé doporučení: nestavět. GEREQ Diagnostic někdy skončí výběrem hotového nástroje a nastavením hranic — ne nabídkou vývoje za každou cenu.

Jednoduchý rozhodovací model

Projdete čtyři otázky. Stačí poctivé ano/ne.

1. Je proces diferencující?
   Ne → preferujte SaaS / konfiguraci.
   Ano → pokračujte.

2. Umí hotový nástroj 80 % bez násilí na procesu?
   Ano → konfigurujte + integrujte.
   Ne → zvažujte custom.

3. Máte vlastníka a rozpočet na provoz (ne jen na stavbu)?
   Ne → nejdřív provozní model, teprve kód.
   Ano → pokračujte.

4. Umíte ořezat MVP na milníky?
   Ne → diagnostika a priorizace.
   Ano → Sprint / System dává smysl.

Náklady, které firmy přehlížejí

Položka	Proč bolí
Údržba a security	Custom žije roky; „hotovo“ neexistuje
Zastupitelnost	Jeden dodavatel / jeden vývojář bez dokumentace
Integrace	Custom bez napojení na zbytek firmy je ostrov
Školení lidí	Nový UI ≠ lepší proces
Přepis po roce	Špatný první model dat

Orientačně: levný custom v řádu desítek tisíc bez diagnostiky často skončí přestavbou v řádu vyšších stovek. Dražší je pak vysvětlovat, proč „to znovu“.

Častá chyba

Firma koupí SaaS, ohýbá ho makry a tabulkami, pak chce „rychlý custom“, který zkopíruje špatný proces 1:1. Výsledek: dražší chaos.

Správný postup: nejdřív zjednodušit proces (diagnostika), pak rozhodnout tool vs. code. Softwarová vrstva nemá zachraňovat neřízené výjimky.

Kontrolní seznam „custom — ano/ne“

• Diferencuje nás proces, nebo jen chceme kontrolu?
• Zkusili jsme poctivě konfiguraci / existující stack?
• Máme milníky a co nebude v MVP?
• Kdo vlastní repozitář, dokumentaci a provoz po spuštění?
• Jak změříme úspěch za 30 / 90 dní (hodiny, chyby, lead time)?

FAQ

Není custom vždy dražší?
Na stavbě často ano. Na provozu ne nutně — pokud hotový nástroj nutí drahé obejití procesu. Dražší je špatná volba, ne „custom“ jako kategorie.

Můžeme začít SaaS a později přejít na custom?
Ano, pokud si držíte data a jasné hranice. Horší je SaaS s nativní logikou, ze které nejdou data ven.

Co když diagnostika doporučí nestavět?
Berte to jako úsporu. GEREQ v takovém případě pomůže s výběrem nástroje a provozními pravidly — viz přístup na stránce Řešení.

Mini case: kdy jsme doporučili nestavět

Firma chtěla „vlastní CRM“, protože stávající SaaS „neuměl přesně jejich pipeline“. Po diagnostice vyšlo:

• 80 % požadavků šlo konfigurací a disciplínou v existujícím nástroji,
• chyběl vlastník procesu a jednotná definice „lead“,
• custom by zkopíroval současný chaos do nového UI.

Doporučení: nejdřív provozní pravidla a konfigurace, integrace na e-mail/účetnictví až potom. Custom CRM jsme odmítli. Klient ušetřil rozpočet vývoje a dostal měřitelný provozní experiment na 60 dní.

To není ztracený obchod — je to důvěra. Stejný klient se později vrátil s integračním problémem, kde custom vrstva dávala smysl.

Build vs. buy vs. blend

Varianta	Kdy	Riziko
Buy (SaaS)	Obecný proces, rychlý start	Vendor lock, omezení procesu
Build (custom)	Diferenciace + kapacita provozu	Náklady údržby, zastupitelnost
Blend	SaaS jádro + custom/integrace kolem	Složitost hranic systémů

Většina rostoucích firem skončí u blend: hotový nástroj na obecné věci, custom nebo integrace tam, kde vzniká výhoda.

Otázky na dodavatele, než podepíšete custom

• Kdo vlastní repozitář a dokumentaci po ukončení spolupráce?
• Jak vypadá milník 1 a co záměrně nebude obsahovat?
• Jak měříme úspěch za 30 a 90 dní?
• Co se stane, když diagnostika / discovery ukáže, že custom není potřeba?

Pokud dodavatel neumí odpovědět na čtvrtou otázku, prodává kód — ne rozhodnutí.

Praktický experiment na 30 dní (než objednáte custom)

1. Změřte ruční kroky a chyby u procesu (hodiny / týden).
2. Zkuste maximální konfiguraci existujícího nástroje.
3. Oddělte „nice to have“ od toho, co skutečně ztrácí peníze.
4. Teprve pak rozhodněte buy / build / blend.

Když po 30 dnech čísla neklesají a konfigurace nestačí, custom má silnější case — a diagnostika bude kratší, protože už máte data.

Závěr a CTA

Custom systém dává smysl, když chrání konkurenční výhodu a máte kapacitu ho živit. Nedává smysl, když jen kopírujete obecný proces dražším způsobem.

Chcete rozhodnout custom vs. hotové na základě provozu, ne dojmu? Probrat diagnostiku.