Varianty dalšího vývoje — přehled a srovnání¶

Stav k 2026-06-23.

Tento dokument shrnuje čtyři realistické varianty pro budoucnost e-shopu. Vznikl jako podklad pro rozhodnutí před zahájením případné realizace.

Rychlé srovnání¶

	Varianta 1 Sylius	Varianta 2 Vlastní headless	Varianta 3 Inkrementální	Varianta 4 Údržba
Investice	1 000–2 000 h	1 000–2 000 h	průběžně	minimální
První výstup	12–18 měsíců	3–4 měsíce (katalog)	1–2 měsíce	okamžitě
Čistota výsledku	vysoká	vysoká	vždy kompromis	status quo
Riziko projektu	vysoké	střední	nízké	nízké
Ekosystém	Sylius / Symfony	vlastní	vlastní	vlastní
Vhodné když	klient chce čistý výsledek	klient chce kontrolu a etapy	klient nechce risk	klient přežívá

Varianta 1 — Sylius (kompletní migrace)¶

Nahradit současný systém Syliusem. Kompletní přepis importní vrstvy, cenové pipeline, checkoutu, adminu a frontendových šablon.

Podrobnosti: analyza.md, migracni-rozsah.md, revize-rozsahu-realizace.md.

Výhody¶

Výsledek je čistá, standardní platforma — Symfony ekosystém, aktivní komunita, pluginy
Za Syliusem stojí firma a komunita, nový vývojář se v projektu zorientuje
Katalog, checkout, objednávky, zákazníci, RBAC — dostaneme hotové věci
Dlouhodobě udržitelné

Nevýhody¶

Big bang — systém se musí spustit celý najednou, ne po částech
12–18 měsíců vývoje bez jediného viditelného výstupu pro klienta
Realistický rozsah: 1 200–2 000 h (viz revize odhadů)
CMS, import vrstva a část adminu se stejně musí řešit mimo Sylius nebo jako custom rozšíření

Nebezpečí¶

Psychologický a finanční strop klienta: projekt za 1 000–2 000 h při omezené finanční kondici je existenční risk
Pokud se zadrhne Pohoda integrace nebo importní vrstva (červené riziko v dokumentaci), projekt stojí a fakturace běží
Scope creep: "Sylius to umí" ≠ nulová práce — konfigurace, mapování, testování jsou vždy hodiny navíc
1 000 h je reálné jen při explicitně ořezaném scopu — viz níže

1 000 hodin je hranice, ne záchrana

1 000 h je dosažitelných pouze pokud předem padnou tato rozhodnutí: rc-baterie.cz = přesměrování, historické objednávky = archiv, Meilisearch = fáze 2, admin ergonomie = minimální, checkout speciality = jen nutné (RP/PHE, SK DPH). Bez explicitního ořezu se projekt dostane na 1 400–1 800 h — roztažených neviditelně pod tlakem klienta.

Doporučení pro Sylius variantu

Fázovat kontrakt, ne jen projekt. Fáze 1 = funkční Sylius do 1 000 h s definovaným scopem. Fáze 2 = CMS, Meilisearch, admin ergonomie. Klient podepíše fázi 1, vidí výsledek, pak se rozhodne. Tím se řeší psychologický strop i finanční kondice.

Varianta 2 — Vlastní headless katalog¶

Postavit vlastní headless produktové API (eshop-products) inspirované osvědčenými koncepty:

Vendure — Product/Variant model, translation tabulky, search dokument
Medusa — price_set model, inventory per lokace, rezervace
Sylius — Option vs. Attribute (co tvoří variantu vs. co je jen popis)
Spree — REST API styl

Základ existuje: migrace 001–011, skeleton, základní GET endpointy. Chybí: admin API, Meilisearch worker, checkout/objednávky.

Architektura: PHP, PostgreSQL-first, SQL-first, bez ORM, bez velkého frameworku.

Výhody¶

Umožňuje strangler fig přístup — nejdřív katalog (3–4 měsíce), pak checkout, pak objednávky
Klient vidí výsledky průběžně, ne až po 18 měsících
Datový model přesně odpovídá potřebám projektu — žádné ohýbání frameworku
Cenová pipeline, flag neprepsat, importní vrstva — navrženo od začátku pro tento provoz
PostgreSQL-first = přímý SQL, čitelné queries, žádné ORM překvapení

Nevýhody¶

"Náš" systém — žádný ekosystém pluginů, žádná komunita
Onboarding nového vývojáře je dražší než u Syliusu
Checkout, objednávky, zákazníci, Pohoda export — vše se musí postavit nebo dočasně ponechat na starém systému
Celkový rozsah je srovnatelný se Syliusem, výhoda je v rozložitelnosti

Nebezpečí¶

Single point of expertise — systém zná jeden nebo dva vývojáři, odchod klíčového člověka je risk
Bez ekosystému se musí řešit věci, které Sylius má zdarma (payment gateway integrace, mailer, RBAC...)
Pokud se projekt zastaví uprostřed (finanční důvody), zůstane nedokončené API bez checkoutu

Varianta 3 — Inkrementální vylepšení současného¶

Nestrhávat, vylepšovat postupně. Každý krok přináší okamžitou hodnotu.

Konkrétní kroky s viditelným dopadem:

Meilisearch vyhledávání místo SQL LIKE — zákazník okamžitě cítí rozdíl
Importní vrstva přepsána jako čisté PHP třídy — stabilnější importy, laditelné chyby
Cenová pipeline jako explicitní pipeline místo roztroušeného SQL
Admin moduly postupně refaktorovány
Oddělení logiky — DB přístupy, service třídy, čitelný kód

Výhody¶

Okamžité výsledky, klient vidí průběžně co dostává za peníze
Žádný big bang, žádné přechodové období bez e-shopu
Každý vylepšený kus snižuje technický dluh i pokud se nikdy nedokončí
Nejnižší finanční risk

Nevýhody¶

Výsledek nikdy nebude čistá architektura — vždy kompromis
Technický dluh se snižuje, ale na nulu nikdy
Za 3–5 let může být situace opět podobná dnešní

Nebezpečí¶

Scope creep — "ještě jedno vylepšení" nikdy nekončí, bez jasného cíle se investice rozplývá
Chybí motivační milník — bez cíle je těžké udržet disciplínu refaktoringu
Opakované dotýkání starého kódu bez čisté hranice může přidávat nové bugy

Varianta 4 — Nechat umírat (pouze údržba)¶

Systém funguje. Opravovat jen co se rozbije, nepřidávat nové funkce, neinvestovat do architektury.

Výhody¶

Nulové investiční náklady
Nulové riziko big bang výpadku
Systém v současném stavu pravděpodobně vydrží 3–5 let

Nevýhody¶

PHP verze, závislosti a bezpečnostní záplaty vyžadují průběžnou pozornost — i "jen údržba" jsou hodiny ročně
Žádné nové funkce, žádné zlepšení pro zákazníky
Technický dluh roste pasivně

Nebezpečí¶

Bezpečnostní díry — stárnutí PHP verze a závislostí přináší zranitelnosti, které se musí řešit
Dodavatelé mění formáty importů — importní skripty se rozbijí a budou potřebovat opravu
Pokud se po 3 letech rozhodne pro migraci, dokumentace a znalost systému bude stará

Tato varianta dává smysl pokud klient plánuje prodat, výrazně zmenšit provoz, nebo prostě přežít dalších 3–5 let bez velké investice. Není to vzdání se — je to vědomé rozhodnutí.

Závěr¶

Žádná z variant není špatná — záleží na tom, co klient skutečně potřebuje a co unese.

Klíčová otázka není "který framework" — je to jak velký risk a jak dlouhou slepou etapu projekt unese.

Pokud je cílem čistý výsledek a klient to zvládne financovat: Varianta 1 (Sylius), fázovaný kontrakt.

Pokud je cílem průběžná viditelná hodnota a kontrola nad systémem: Varianta 2 nebo 3.

Pokud je primárním cílem přežít s minimální investicí: Varianta 4.