Novinky a články. Z praxe, bez vaty.
Co se naučíme na projektech klientů i na vlastních produktech. SEO, umělá inteligence, bezpečnost a vývoj.
Nejnovější
Vývoj aplikací6. 11. 2026 · 8 min čtení
Customer development: Rozhovory se zákazníky krok za krokem
Než navrhneme nový produkt, potřebujeme rozumět situaci, kterou má vyřešit. V rozhovoru proto hledáme konkrétní zkušenost, současné řešení a jeho důsledky. Pochvala nápadu sama o sobě není zadáním pro vývoj.Číst článek →Mobilní design pro ovládání palcem: Jak navrhnout dotykové cíle
Na mobilu nestačí tlačítko vidět. Člověk ho musí pohodlně zasáhnout, nezvolit sousední akci a rozpoznat výsledek. Ukážeme, jak kontrolujeme dotykové cíle od návrhu po skutečný telefon.První publikace aplikace v App Store a Google Play: co připravit ke schválení
Aplikace funguje v telefonu vývojáře, ale do veřejného obchodu ještě vede několik kroků. Potřebujete správné účty, otestovanou verzi, úplné podklady a přístup pro kontrolora. Ukážeme, jak připravit první vydání pro App Store a Google Play, rozdělit odpovědnosti a řešit případné zamítnutí. Schválení na první pokus slíbit nelze, zbytečným prodlevám však můžete předejít.Mobilní aplikace k existujícímu webovému produktu: Co převzít a co navrhnout znovu
Provozujete webovou aplikaci nebo klientský portál a zákazníci chtějí pohodlně pracovat i z telefonu. Mobilní rozšíření může využít stejné účty, data a část pravidel. Nejdřív ale potřebujete rozhodnout, které úkoly do telefonu patří, zda je stávající systém dokáže obsloužit a jak budou web s aplikací fungovat vedle sebe.Produktová vize a strategie: jak dát týmu společný směr
Produktová vize popisuje, jakou změnu chcete zákazníkům přinést. Strategie vysvětluje, komu a jak ji nabídnete a čemu dáte přednost. Jejich hodnotu poznáte ve chvíli, kdy tým řeší dva konkurenční požadavky. Ukážeme, jak připravit srozumitelný směr, převést jej do ověřitelných rozhodnutí a udržovat jej v každodenní práci.Wireframy a interaktivní prototypy: Jak ověřit nápad dřív než kódovat
Než zaplatíte vývoj, ověřte nejslabší předpoklad návrhu. Wireframe ukáže uspořádání, interaktivní prototyp dovolí pozorovat konkrétní úkol. Ani jeden sám nedokazuje poptávku nebo technickou proveditelnost. Tento průvodce vás provede zadáním, přípravou testu a rozhodnutím na příkladu firemního schvalování nákupů.iOS nebo Android: jak vybrat první platformu aplikace
První platformu vybírejte podle lidí, kteří mají aplikaci skutečně používat, a úkolu, který jim má vyřešit. Rozhodnutí mezi iOS a Androidem ovlivní nábor do pilotu, technická omezení, testování i další provoz. Ukážeme, jak porovnat podklady a zvolit první krok, který přinese použitelnou odpověď.Výkon webové aplikace: jak zrychlit databázi, API i rozhraní
Webovou aplikaci zrychlíte tím, že nejdřív zjistíte, kde uživatel skutečně čeká, a upravíte příčinu. Pomalá obrazovka může čekat na databázový dotaz, externí API i JavaScript v prohlížeči. Každý problém vyžaduje jiný zásah. Projdeme jednu operaci od kliknutí po použitelný výsledek: co měřit, kdy pomůže index nebo mezipaměť a jak ověřit zlepšení, které neschová chyby ani nevrací nesprávná data. Srozumitelně pro vedení firmy i s technickými souvislostmi pro vývojový tým.Vlastní aplikace pro e-shop: vyplatí se, nebo stačí mobilní web?
Vlastní aplikace se e-shopu vyplatí tehdy, když zákazníkům opakovaně usnadňuje důležitý úkon a firmě přinese víc, než stojí její vývoj a provoz. Samotný podíl návštěv z telefonu ani aplikace konkurenta takovým důvodem nejsou. Projdeme rozdíl mezi mobilním webem, PWA a aplikací, využití při opakovaných objednávkách i v B2B a výpočet návratnosti, který nepovažuje každou objednávku z aplikace za nový obchod. Na konci budete vědět, co ověřit před zadáním vývoje.Škálování aplikace: co dělat, když roste počet uživatelů
Když aplikace roste, rozšiřujte kapacitu podle změřeného omezení a počítejte i s výpadkem části systému. Samotný počet registrovaných účtů vám neřekne, co pořídit. Potřebujete znát špičkovou zátěž, požadovanou kvalitu služby, ověřenou provozní hranici a termín dalšího růstu. Ukážeme, jak z těchto údajů sestavit kapacitní plán, podle kterého se domluví vedení firmy, obchod i vývojáři. Od nejbližší kampaně přes zátěžový test až po rozhodnutí o investici.Jak vybrat firmu na vývoj softwaru: 20 otázek před podpisem
Firmu na vývoj softwaru na míru vybírejte podle odpovědí, ne podle prezentace: kdo bude na projektu pracovat, jak vznikne pevná cena, komu bude patřit kód, kdo ponese odpovědnost za data a co se stane po spuštění. Sepsali jsme 20 otázek, které stojí za to položit každému dodavateli ještě před podpisem. U každé najdete, jaká odpověď je dobrá a co je varovný signál. Stav k 17. říjnu 2026.Metriky UX: Jak správně použít SUS, NPS, CSAT a dokončení úkolů
Dotazník vyšel dobře, ale lidé stále nedokončí objednávku. Každá metrika popisuje jinou část zkušenosti. Ukážeme, kdy použít SUS, NPS, CSAT a míru dokončení úkolu, jak je spočítat a co z výsledků skutečně smíte vyvodit.Přístupnost mobilní aplikace: VoiceOver, TalkBack a větší písmo
Tlačítko na obrazovce je, ale čtečka ho nepojmenuje. Po zvětšení písma zmizí potvrzení objednávky. Přístupnost rozhoduje, zda člověk úkol dokončí bez cizí pomoci. Ověřujte proto celé cesty na iPhonu i Androidu, se čtečkou, velkým textem a různými způsoby ovládání.Jak vybrat technologii pro webovou aplikaci: React, Node.js a alternativy
Jedna nabídka slibuje React, druhá Node.js a třetí rychlý vývoj v Pythonu. Jak je porovnat, když každá mluví o jiné části aplikace? Začněte potřebami uživatelů a provozu. Pak si nechte ověřit nejrizikovější scénář a spočítejte, kdo bude systém udržovat.Offline režim v aplikacích: Kdy je nutný a jak řešit synchronizaci
Obchodník připraví objednávku bez internetu. Mezitím kolega změní cenu a rezervuje poslední kus. Po připojení nestačí oba záznamy jen přenést. Aplikace musí určit, co platí, co čeká na potvrzení a co má člověk vyřešit. Správný offline režim začíná těmito pravidly.Jak vytvořit SaaS: Od nápadu po prvních 100 platících zákazníků
Aplikace funguje, registrace přibývají, ale platící zákazníky stále počítáte na prstech. Cesta k první stovce začíná dřív než vývoj: výběrem problému, ochotou za řešení zaplatit a jasnou cestou k opakovanému používání.20 pravidel UX, která dodržet při návrhu prototypu
Prototyp má pomoci rozhodnout, zda lidé zvládnou důležitý úkol. Nestačí propojit hezké obrazovky. Těchto 20 kontrol vám pomůže připravit srozumitelný návrh, užitečný test a předání, ze kterého vývojář pozná i chybějící rozhodnutí.Mobilní aplikace pro techniky: Co musí fungovat i bez signálu
Technik ve sklepní kotelně doplní materiál, vyfotí opravu a nechá zákazníka potvrdit výkaz. Signál se objeví až venku. Kancelář přesto potřebuje dostat celý podklad a technik musí vědět, jestli ho opravdu odeslal. Právě podle toho poznáte použitelnou aplikaci pro práci v terénu.Aplikace vytvořená pomocí AI funguje. Je připravená na zákazníky?
Prototyp už zvládne ukázku a první uživatelé se ptají, kdy dostanou přístup. Před spuštěním ověřte, zda aplikace ochrání jejich data, správně dokončí objednávku a půjde dál spravovat. Pomůže vám to rozhodnout, co ponechat a co ještě upravit.Předávací protokol k webu a aplikaci: Co převzít a jak to ověřit
Web už běží. Dokážete ale bez dodavatele upravit obsah, nasadit novou verzi nebo obnovit data? Předávací protokol má zachytit, co firma skutečně převzala a ověřila. Projděte s námi přístupy, dokumentaci, testy i odpovědnost za další provoz.Jak definovat MVP a neplýtvat rozpočtem
MVP se prodraží, když každá připomínka automaticky rozšíří první verzi. Vymezte jednu důležitou nejistotu, dokončitelnou uživatelskou cestu a rozhodnutí, které výsledek umožní. Minimum Viable Product má poskytnout použitelný důkaz pro další investici. Počet obrazovek ani malá cena samy o sobě tento účel nezajistí.ASO: jak zviditelnit aplikaci a získat správné instalace
Aplikace se může objevit ve vyhledávání, a přesto ji lidé nestáhnou. Jinou si stáhnou, ale nedokončí jedinou rezervaci nebo objednávku. ASO potřebuje rozlišit nalezení, rozhodnutí o instalaci a skutečný užitek. Začněte tím, pro koho produkt slouží a jaký úkol mu usnadní.Jak prioritizovat funkce v backlogu: metody, které dávají smysl
Backlog může obsahovat dobré nápady, a přesto nepomáhat při rozhodování. Každé oddělení chce svou funkci první, odhady nejsou srovnatelné a požadavky stárnou. Prioritizace má dát týmu srozumitelné pořadí práce a vysvětlit, proč teď řeší právě tento problém.Mobilní hry a gamifikace: Jak zapojit uživatele do běžných aplikací
Uživatel získává body za každé otevření aplikace, ale úkol, kvůli kterému přišel, stále nedokončí. Gamifikace má podpořit smysluplný pokrok. Před odznaky a žebříčkem proto rozhodněte, které chování pomůže člověku a jak poznáte jeho skutečný výsledek.Progresivní webové aplikace: Kdy PWA nahradí nativní aplikaci
Zákazník chce aplikaci, ale většinu práce zvládá v několika formulářích a přehledech. PWA může zpřístupnit takovou službu přímo z webu a nabídnout instalaci. Rozhodnutí však musí vycházet z potřebných funkcí a konkrétních telefonů, ne pouze z představy levnějšího vývoje.Produktová analytika: zjistěte, kde lidé v aplikaci ztrácejí cestu
Počet přihlášení neříká, zda uživatelé dokážou udělat práci, kvůli které aplikaci mají. Produktová analytika propojuje důležité činnosti s jejich výsledkem. Začněte jednou rozhodovací otázkou, popište události a ověřte, že znamenají totéž v aplikaci i v přehledu. Teprve potom hledejte místa, kde změna rozhraní nebo procesu může pomoci.Push notifikace: navrhněte retenční kampaň, která má důvod přijít
Dobrá push notifikace připomíná užitečný další krok, který člověk opravdu může udělat. Nepomůže, když pouze otevře aplikaci a vzápětí ji zase zavře. Pro retenční kampaň proto nejdřív určete potřebné chování, vyberte vhodné příjemce a stanovte, kdy zprávu neposlat. Úspěch posuzujte podle návratů k hodnotné činnosti, společně s dopadem na vypínání upozornění.Platby v aplikaci: Stripe, GoPay a předplatné bez zmatků v účtech
Zákazník zaplatil, ale aplikace mu službu neodemkla. Jinému přišly dva doklady. Podobné chyby obvykle nevznikají na tlačítku Zaplatit, ale mezi bránou, účtem, předplatným a účetnictvím. Bezpečnou integraci proto zadávejte jako celý proces.Dashboard plný dat, ale bez odpovědi? Navrhněte ho pro rozhodnutí
Na obrazovce je dvanáct grafů. Vedoucí přesto otevírá Excel, aby zjistil, které úkoly stojí. Přehledný dashboard musí ukázat význam čísla, rozsah dat a další akci. Velké množství podkladů není důvod zobrazit je všechny najednou.Více lidí, stejná rychlost? Jak škálovat produktový tým
Přibývají vývojáři, ale zákazník na změny čeká déle. Nový tým přebírá úkoly, které musí nejdřív schválit jiný tým, a každý má svůj seznam priorit. Růst potřebuje jasné hranice práce, rozhodovací pravomoc a společné ověření výsledku. Nábor je až jedna z možných odpovědí.Design systém: proč každé tlačítko ve firmě nemusí vznikat znovu
V jedné aplikaci se objednávka ukládá modrým tlačítkem, v druhé zeleným a v třetí ikonou bez popisku. Vývojáři opakují podobnou práci a uživatelé se učí nové chování. Design systém sjednocuje podobu i pravidla prvků, které týmy skutečně používají.Mapy a geolokace v aplikacích: 7 rozhodnutí, která neodkládejte na konec
Najít nejbližší pobočku a sledovat pohyb člověka celý den jsou dvě různé služby. Přesto mohou na první obrazovce vypadat stejně: mapa, modrý bod a tlačítko pro povolení polohy. Rozdíl se ukáže v oprávněních, spotřebě baterie, nakládání s údaji i účtu od mapového poskytovatele. Sedm rozhodnutí před vývojem vám pomůže určit, jaké údaje potřebujete a jak má aplikace fungovat, když je uživatel nesdílí.Agilní vývoj vs. waterfall: 7 otázek, které rozhodnou o vašem projektu
Aplikace může splnit celé zadání a přesto lidem přidat práci. Nebo se může každý týden měnit, aniž by se přiblížila ke spuštění. Při výběru mezi agilním vývojem a waterfallem proto řešte hlavně dvě věci: kolik toho o budoucím systému skutečně víte a jak rychle dokážete ověřit, že vzniká správné řešení. Sedm otázek vám pomůže zvolit postup a domluvit s dodavatelem pravidla, která udrží projekt pod kontrolou.Onboarding uživatelů: jak snížit odpad nováčků v prvních minutách
Nový uživatel se zaregistruje, projde tři úvodní obrazovky, aplikace se ho zeptá na polohu a notifikace a pak mu ukáže prázdný přehled. Za minutu je pryč a už se nevrátí. Každý z těch kroků někdo navrhl s dobrým úmyslem. Dohromady ale stojí mezi člověkem a důvodem, proč si aplikaci vůbec otevřel. Z doporučení a dat Applu, Googlu, Microsoftu, Nielsen Norman Group i českých úřadů jsme sestavili, co v prvních minutách po registraci opravdu pomáhá a co jen zdržuje.PostgreSQL, MySQL, nebo NoSQL? Jak vybrat databázi, abyste ji za tři roky nemuseli měnit
Výběr databáze patří k rozhodnutím, která se na začátku projektu udělají za odpoledne a pak se s nimi žije roky. Přechod na jinou databázi u běžící aplikace je velký projekt, jak ukazují příběhy Guardianu, Uberu nebo Discordu. Porovnali jsme PostgreSQL, MySQL a nejznámější NoSQL databáze podle aktuálních dat, ceníků a dokumentace k 29. září 2026. Najdete tu i to, co nabízejí české hostingy a kde vaše data fyzicky leží.Notifikace a e-maily v aplikaci: jak je nastavit, aby lidi neotravovaly a důležité zprávy přesto došly
Když aplikace píše moc často nebo o nepodstatných věcech, lidé jí notifikace vypnou a e-maily začnou mazat bez čtení. Pak jim nedojde ani zpráva, na které opravdu záleží, třeba upozornění na podezřelé přihlášení. Rozebrali jsme, podle čeho vybrat kanál, jak nastavit frekvenci a tiché hodiny, co přesně vyžadují Apple, Google, Gmail a Microsoft a kde končí servisní zpráva a začíná obchodní sdělení podle českého zákona.Jak udržet uživatele aplikace, aby ji po týdnu nesmazali: push notifikace a retence v praxi
Sedmý den po instalaci otevře typickou aplikaci sedm až deset lidí ze sta, třicátý den zhruba tři až čtyři. Rozhoduje se hned na začátku: jestli člověk v první minutě pochopí, k čemu mu aplikace je, kdy a proč ho požádáte o notifikace a jestli mu pak chodí zprávy, které chce číst. Ukážeme čísla za svět i za Česko, pravidla Applu a Googlu, co říká český zákon k obchodním sdělením a konkrétní plán na první měsíc.Škálovatelnost webové aplikace: jak připravit systém na statisíce uživatelů
Webová aplikace zvládne statisíce uživatelů, když se nejdřív změří, kde je úzké hrdlo, a teprve potom se přidává výkon. Většinou to není slabý server, ale databáze, pomalá externí služba nebo tisíce lidí, kteří přijdou ve stejnou minutu. Projdeme to na výpadcích eDokladů, sčítání lidu a registrace k očkování i na tom, jak rostly Notion, Figma nebo Shopify. Na konci najdete plán, co řešit při 1 000, 10 000 a 100 000 uživatelích.Aktualizace mobilní aplikace po spuštění: jak řídit verze, aby vás Apple ani Google nezaskočili
Když mobilní aplikaci po spuštění nikdo neaktualizuje, časem do obchodu nepůjde nahrát ani opravu a část nových uživatelů ji tam nenajde. Apple i Google každý rok zvedají povinné minimum, nové verze iOS a Androidu mění chování telefonů a vaši uživatelé aktualizují každý jinak rychle. Ukážeme, co vás letos čeká, jak číslovat verze, jak vydávat postupně, co sledovat po vydání a kdy má smysl aktualizaci vynutit.UX design webové aplikace: proč se uživatelé vracejí a proč odcházejí
Uživatelé z webové aplikace odcházejí hlavně ze tří důvodů: hned nepochopí, k čemu jim je, zdržuje je pomalé nebo zmatené rozhraní, nebo narazí na chybu a nevědí, jak dál. Vracejí se tam, kde rychle a opakovaně udělají to, kvůli čemu přišli. Ukážeme, co o tom říkají data z Česka, EU i z více než 10 600 digitálních produktů a jak zjistit, kde lidé odpadají právě u vás.Jak vydělat na mobilní aplikaci: předplatné, nákupy v aplikaci, nebo reklama?
Pro většinu aplikací, které lidé používají pravidelně, vydělává nejspolehlivěji předplatné. Nákupy v aplikaci se hodí tam, kde se platí za konkrétní věc, a reklama až u aplikací s opravdu velkým publikem. Velké aplikace jako Duolingo nebo Spotify přitom modely kombinují. Ukážeme, kolik vám z ceny skutečně zůstane po DPH a provizi Applu a Googlu, jaká čísla čekat a jak model vybrat.Jak naplánovat vývoj SaaS aplikace: od prvního wireframu po spuštění
Nejdražší chyby SaaS projektu nevznikají v kódu, ale v plánu. Aplikace na předplatné, kterou používá mnoho firem najednou, musí od prvního dne řešit věci, které u běžného webu řešit nemusíte: týmy a role, platby, oddělená data zákazníků a provoz bez výpadků. Projdeme cestu od prvního wireframu po spuštění krok za krokem, s harmonogramem, rozpočtem a checklistem.Nativní aplikace vs. multiplatformní vývoj: co se vyplatí pro váš projekt v roce 2026
Pro většinu firemních aplikací se dnes vyplatí multiplatformní vývoj: jeden kód pro iPhone i Android, jeden tým a zhruba poloviční práce na každé nové funkci. Nativní vývoj má smysl tam, kde aplikace stojí na výkonu, hardwaru telefonu nebo nejnovějších funkcích iOS a Androidu. Ukážeme, jak poznat, do které skupiny patří ta vaše.Od nápadu k MVP: jak ověřit, že o vaši webovou aplikaci bude zájem
Nejdražší chyba při vývoji aplikace? Postavit ji pro lidi, kteří o ni nestojí. Ukážeme, jak zájem ověřit za šest týdnů a za zlomek ceny vývoje, ještě než podepíšete smlouvu s programátory.Sdílet stránku
Máte nápad?
V krátkém hovoru zjistíme, co potřebujete, a navrhneme další krok. Pak dostanete nabídku s pevnou cenou a termínem.
+420 771 166 199Po až Pá 8:30 až 16:00 · info@listify.coolKdy vám máme zavolat?
Vyberte den a časové rozmezí. Zavoláme my, hovor trvá zhruba 15 minut.
Den