Co je low-code a no-code a kdy se firmě vyplatí

Skoro každý majitel firmy už ten slib slyšel. Aplikaci si postavíte sami, bez programátorů, za pár dní a za zlomek peněz. Stačí tahat políčka po obrazovce. Jmenuje se to low-code nebo no-code a obojí má svoje místo. Problém je, že se to často prodává jako řešení na všechno. Není. Pojďme si říct, co ty dva pojmy znamenají, kdy vám reálně ušetří čas a peníze a kdy si tím naopak zaděláte na průšvih.

Co znamená low-code a no-code

Obojí je způsob, jak postavit aplikaci převážně klikáním místo psaní kódu. Komponenty se skládají vizuálně, logiku nastavujete v menu, data se napojí přes formuláře. Rozdíl mezi nimi je v tom, kolik programování platforma stále potřebuje.

No-code je čisté klikání. Žádný kód nepíšete, nebo skoro žádný. Cílem je, aby aplikaci postavil běžný člověk z provozu, ne ajťák. Hodí se na jednoduché evidence, formuláře, sběr dat, interní seznam objednávek nebo dovolených. Příkladem jsou nástroje typu Airtable, většina funkcí v Microsoft Power Apps nebo jednoduché stavebnice webů.

Low-code je o stupínek výš. Většinu odklikáte, ale na složitější věci dopíšete kus kódu. Počítá se s tím, že u toho bude sedět někdo technický, klidně i profesionální programátor, který si jen zrychlí práci. Hodí se na větší aplikace, kde potřebujete vlastní logiku a napojení na ostatní systémy. Sem patří platformy jako OutSystems, Mendix nebo Microsoft Power Platform v náročnějším nasazení.

Hranice mezi tím není ostrá. Hodně nástrojů umí oboje. Pro vás je důležitější otázka než škatulka: postaví to člověk z provozu sám, nebo u toho musí být někdo technický?

Proč to celé tak letí

Důvod je prozaický. Programátorů je málo. IDC mluví o globálním nedostatku kolem 4 milionů vývojářů. Když na hotovou aplikaci od dodavatele čekáte půl roku a stojí to ranec, je lákavé dát nástroj do ruky lidem, kteří danou agendu znají nejlíp. Říká se jim citizen developers, tedy stavitelé z řad běžných zaměstnanců.

Čísla tomu dávají za pravdu. Gartner odhaduje, že trh s low-code nástroji dosáhne v roce 2026 zhruba 44,5 miliardy dolarů a do roku 2029 vyroste na 58,2 miliardy. Ještě výmluvnější je jiný odhad: do roku 2026 má být 75 procent nových firemních aplikací postaveno právě na low-code, oproti necelé čtvrtině v roce 2020. A 80 procent lidí, kteří na těchto platformách staví, má být mimo IT oddělení.

Pro malou a střední firmu v Česku je tahle logika ještě silnější. Vlastní vývojové oddělení nemáte, externí vývoj je drahý, ale spoustu věcí kolem provozu byste si chtěli zautomatizovat. Tady low-code a no-code opravdu pomáhají.

Kdy se to firmě vyplatí

Ne každý nápad je na low-code. Vyplatí se hlavně v těchhle případech.

• Interní nástroje a evidence. Sledování zakázek, schvalování faktur, evidence majetku, žádanky o dovolenou. Věci, které dnes řešíte v Excelu a e-mailech. Tady je no-code skoro vždycky dobrá volba.
• Rychlé ověření nápadu. Chcete si otestovat, jestli nová služba nebo proces vůbec dává smysl, než do toho nalijete velké peníze. Postavíte prototyp za pár dní a ověříte to v praxi, místo abyste platili měsíce vývoje za něco, co nakonec nikdo nechce.
• Formuláře a sběr dat. Přihlášky, dotazníky, objednávkové formuláře napojené rovnou do tabulky nebo systému. Klasická úloha, kterou no-code zvládá snadno.
• Automatizace opakované práce. Když se data přepisují z jednoho místa na druhé ručně, často to nahradí jednoduchý nástroj. Ušetří hodiny každý týden a ubude chyb z překlepů.
• Když nemáte vlastní IT. Pro firmu bez vývojářů je low-code způsob, jak dostat aplikaci do provozu bez najímání týmu. Člověk, který agendu zná, ji často postaví líp než externí dodavatel, co byznysu nerozumí.

Společné mají jedno: jasně ohraničený rozsah, vnitřní použití a snesitelnou míru rizika. Když se to pokazí, nepoloží to firmu.

Kdy se tomu radši vyhnout

Tady je druhá strana, o které se mlčí. Low-code a no-code mají strop a překročit ho bolí.

• Hlavní produkt firmy. Pokud je aplikace to, co prodáváte a na čem stojí byznys, nestavte ji na cizí platformě, ze které se těžko odchází. Potřebujete plnou kontrolu nad kódem.
• Velký objem a výkon. Nástroje dobře zvládnou desítky až stovky uživatelů a běžnou zátěž. Když potřebujete obsloužit statisíce požadavků nebo složité výpočty, narazíte na výkonový strop platformy.
• Citlivá data a regulace. GDPR, zdravotní nebo finanční údaje. Na cizí platformě nemáte plně pod kontrolou, kde data leží a jak jsou chráněná. U regulovaných věcí to bývá problém.
• Složitá vlastní logika. Čím víc výjimek, pravidel a napojení na okolní systémy, tím víc se klikání zadrhává. V určitém bodě by byl normální vývoj rychlejší i levnější.
• Když to staví každý sám a nikdo o tom neví. O tomhle za chvíli zvlášť, je to nejčastější tichý průšvih.

Tři rizika, která se nevyplatí podcenit

I tam, kde low-code dává smysl, je pár pastí. Tahle tři vidíme nejčastěji.

Závislost na dodavateli. Aplikaci postavíte uvnitř platformy a ven ji většinou nedostanete. Když dodavatel zvedne ceny, změní podmínky nebo skončí, jste v koncích. Než se do nástroje pustíte, zjistěte konkrétně: jdou data exportovat do běžného formátu, kolik za export chtějí a co z aplikace zůstane funkční, když smlouvu vypovíte. Když na to nedostanete jasnou odpověď, je to varování.

Stínové IT. Tohle je nejzákeřnější. Když si může aplikaci postavit kdokoli, brzy jich po firmě běhají desítky a nikdo neví, kde leží data, kdo k nim má přístup a co se stane, když dotyčný odejde. Pomůže jednoduchý seznam toho, co kde vzniklo, kdo to spravuje a jaká data v tom jsou. Stačí sdílená tabulka, hlavně ať existuje a ať ji někdo aktualizuje.

Skrytý dluh. Aplikace klikáním vzniká rychle, ale roste neuspořádaně. Po roce je z prototypu spleť, kterou nikdo nechce rozplétat. U věcí, co mají sloužit dlouho, si od začátku pojmenujte, kdo je vlastník, kam se ukládají data a jak by se to dělalo, kdyby platforma zmizela. Prototyp na týden tohle řešit nemusí, páteřní nástroj ano.

Jak se rozhodnout

Než se do něčeho pustíte, projděte si pět otázek.

1. Je to interní nástroj, nebo váš hlavní produkt? Interní věc klidně na low-code. Hlavní produkt radši ne.
2. Kolik lidí a kolik dat to obslouží? Malý a střední rozsah je v pohodě. Velký objem prověřte předem, ať nenarazíte na strop platformy v půlce nasazení.
3. Jsou v tom citlivá nebo regulovaná data? Pokud ano, zjistěte, kde budou fyzicky ležet a jestli to splní vaše povinnosti podle GDPR i oborových pravidel.
4. Dostanu z platformy data a logiku ven? Když ne, počítejte se závislostí na dodavateli a tu závislost si zahrňte do rozhodnutí, ne ji odsouvejte na později.
5. Kdo to bude po roce udržovat? Určete vlastníka hned na začátku. Aplikace bez majitele zestárne a stane se rizikem.

Když na první čtyři otázky odpovíte tak, že rozsah je malý, data nejsou citlivá a jde o interní věc, je low-code nebo no-code skvělá volba. Postavíte rychle, levně a často líp, než kdybyste úkol zadali ven. Jakmile ale mluvíme o hlavním produktu, velkém objemu nebo citlivých datech, vyplatí se zpomalit a zvážit normální vývoj. Není to buď, anebo. Spousta firem dělá obojí: drobné věci klikáním, to důležité pořádně. Klíč je vědět, do které škatulky váš konkrétní nápad patří.