Jsou no-code aplikace škálovatelné?
Firmy často začínají s no-code nástroji, které jim zjednodušují vytvoření procesu/služby/produktu a hlavně zrychlují vývoj. Čas pro uvedení produktu/služby na trh je v rámci no-code nástrojů v řádu dní, maximálně týdnů. Oproti tomu programování celého řešení zabere měsíce, kvartály a někdy i roky.
Proč je dobré využít no-code platformy jsme psali v tomto článku: FINN - z nuly na 100 milionů v prvním roce startupu

Když výhoda se stane brzdou
Pokud ale narazíte na limit no-code nástrojů, může se to pro vás stát brzdou v tom lepším případě. V horším celé řešení musíte zahodit a naprogramovat ho odznova - řádek po řádku.
Proto je hned od začátku důležité znát limity nástrojů, odhadnout čas, kdy se k limitům dostanete, a mít řešení, které současný systém nahradí či doplní.
3 kritické best practices, které zvažovat
- dobře navržený model databáze
- optimalizovaná logika a dotazování do databází
- funkční uživatelské rozhraní
Tyto 3 body je potřeba zvážit ať už volíte no-code nástroje, nebo si věci vyvíjíte sami.
U no-code platforem musíte zvážit i znalosti a dovednosti svých lidí. Nemusí být programátoři, ale musí mít “programátorské” myšlení, aby dokázali vytvářet funkční systémy. Tím je myšlena úroveň zhruba znalosti pokročilých funkcí v Excelu.

Příklad za všechny prachy
O FINNu a jeho růstu z nuly na 100 milionů korun během prvního roku jsem psal už minule. Díky no-code nástrojům byli zaměstnanci schopní testovat nové nápady téměř okamžitě. Tento růst si ale nese i svou daň v oblasti IT. Jejich senior software inženýr Ishtiaque Zafar o tom píše zde: No-code isn't scalable. Our learnings at FINN going from 1000 towards 100,000 car subscriptions.
Pro jednodušší pochopení překládám to hlavní.
- Limity databází (airtable) - dělat tisíc řádků v airtablu a dělat deset milionů řádků v airtablu je opravdu rozdíl
- Problémy se synchronizací
- Přemíra užívání nástrojů jako Make pro byznys-kritické procesy
- Extrémní závislosti na systémech navzájem - pokud owner jednoho systému něco upraví, musí udělat změnu i owner jiného propojeného systému
- Nedostatek ownershipu (vlastnictví) - kdo vlastní co
- Nedostatek u přístupu a kontrol změn v procesech
- Obtížné testování
Jak s tímto dále bojovali?
Odstranění chyb v databázi
Od začátku používali jako svou databázi airtable. Časem se dostali ale k tabulkám se 400 poli (sloupci) a to už začíná být hodně nepřehledné. Navíc airtable zavedl limit na 5 dotazů za sekundu, což byla limitace.
Tím se dostali k time-outům a potřebovali to upravit.
- identifikovali data, která moc nevyužívají a přesunuli je do separátní databáze
- zreplikovali data, která se využívají napříč firmou (data o autech a předplatných)
- zjistili čtecí procesy, které významně zatěžují dotazování a ty četli z databáze bodu 2
- zjistili upravovací procesy a ty optimalizovali (například aktualizovali jen konkrétní řádek u konkrétního auta, ale ne celou tabulku, pokud u ostatních nebyla žádná změna)
Díky tomu docílili stabilního systému s nulovým time-outem.

Získání víry ve svá data
Z důvodů různých dat na různých místech s různými ownery a kvalitou zavedli několik důležitých pravidel.
- Vlastnictví - týmy dostali na starosti různé data sety - akviziční tým měl na starosti dataset s leady, operations dataset s předplatnými atp.
- Kontrola přístupu - jen dedikované týmy měli přístup a možnost úpravy daných datasetů, případně vytvořili pravidla pro ostatní, kteří chtějí k datům přistupovat/upravovat.
- Definování, která data se vůbec můžou měnit a která budou “nastálo”. Například předání auta může být pouze poté, co je auto zaplaceno - předávací tým si zjistí, jestli je zaplaceno v datasetu financí a až pak ho předá. Toto pole přitom může měnit jen tým financí.
Začátek kodování
Výše uvedené problémy vedli k tomu, že dál už nepůjde škálovat. I s ohledem na expanzi do USA potřebovali spolehlivý systém. Rozhodli se vybudovat nový systém s již vyzkoušenými procesy a postupy. To vyvolalo potřebu udržet stávající procesy do té doby, než bude nový vlastní systém vytvořen.
První věcí bylo omezení rizika migrace na minimum. Začali s malými věcmi a postupně to škálovali. Začali s 10 novými auty a připravili systém, které to odbaví a zároveň bude schopný to navýšit na 100, poté na 1000 až na 100 tisíc aut. Tím si i vydefinovali správné praktiky, kterých se následně drželi.
Zavedení správných praktik
- Hlavně jednoduše - řešili dnešní problémy s vizí do budoucna aniž by řešili problémy budoucna hned od začátku
- Oslavuj chyby - chyby se stávají a je potřeba na to myslet, zjišťovat je a učit se z nich
- Viditelně - systém musí umět říct, co chce nebo nechce, musí komunikovat a notifikovat
- Komplexnost jiných řešit u nás - procesy partnerů a dodavatelů nejdou řešit u nich a musí se řešit interně - dát jim prostor jak jednoduše pracovat s FINN systémy
- Zákazník na prvním místě - zákazník musí mít jistotu, že FINN pracuje skvěle a musí mít ve spolupráci důvěru
- Dostupnost dat - lidé by měli mít přístup k datům a to by neměl být nikdy blocker
- Čistě je lepší než chytře - snažili se napsat kod, který je lehce pochopitelný pro kohokoliv a kdokoliv ho může měnit.

Snížení přerušení na minimum
Toto je klíčová věc. Jelikož FINN od začátku používal Integromat (nyní Make) a přitom přecházeli na systém, že ne každý má k datům/scénářům přístup, vytvořili vlastní custom-apps přímo v Make. Člověk tak může používat přímo endpointy, ke kterým má oprávnění a k datům, které může používat. Nebo si může volat procesy, které mu správná data dají.
Udělali si tak vlastně svou vlastní interní síť microapps, které mohli lidé ve FINN volat a získávat data o předplatných, autech a dalších věcech. Zároveň přidali Retool na správu podstatných věcí, kde běžní lidé (například ze supportu) mohli vidět to podstatné a nepotřebovali si o data “volat” přes Make.
Kam se dostali?
Díky výše uvedeným krokům se dostali úspěšně ke stabilnímu řešení.
Závěrem
No-code pomohl dostat se tam, kam potřebovali. Další fáze růstu ale znamená nevyhnutelnost kodování vlastních produktů/nástrojů s využitím současných zkušenosti z no-code nástrojů.
No-code systémy budou dále využívány pro své benefity (rychlost, úspora, spolupráce) s případnou úpravou nastavení jako u Make platformy, ale přidá se k tomu ještě samotný produkt, který bude naprogramován.
Odpovědí na úvodní otázku tak je, že do určité fáze je škálovatelnost možná. Pak už ale přichází na řadu i částečné kodování. Díky no-code aplikacím se ale dokáže oddělit to, co je podstatné a má být naprogramováno, od toho, co se dál může řešit no-code platformami.