5,0 z 8 hodnocení na Googlu
Když vám šablona nestačí, postavím vám systém, který zvládne vaše procesy a ušetří čas.
Vedu projekt sám od návrhu po provoz. Jeden člověk přes celý stack, žádné předávání mezi agenturami.
// Sídlím v Mariánských Lázních, pracuji pro celý Karlovarský kraj, celou ČR i Německo a vzdáleně i dál.
S čím to stavím
01 · Služby
Návrh, kód i provoz mám na starost já sám. Bavíte se přímo s vývojářem, který to píše, ne s obchodníkem ani projektovým manažerem.
Postavím interní systém přesně na váš proces: rezervace, docházku, evidenci nebo sklad. Propojím ho s nástroji, které už používáte, přes API a zautomatizuju kroky, co dnes ťukáte ručně.
Napíšu klientské zóny, portály a dashboardy s přihlášením, právy a reportingem nad vašimi daty. Zvládnu i převzít rozjetý SaaS nebo cizí kód a dotáhnout ho do produkce.
Postavím mobilní aplikaci do vaší firmy: instalovatelnou PWA nebo nativní Android pro čtečky, terén a offline provoz. Nasadím ji přímo k vám přes MDM nebo interní APK, bez čekání na schválení v Google Play.
Naprogramuju firemní web nebo e-shop na WordPressu a WooCommerce. Hlídám rychlost načítání a technické SEO, napojím platby, dopravu i sklad a předám web, který si spravíte sami.
Navrhnu logo, vizuální styl a grafiku, která sedí k webu i k tisku. Grafiku i kód dělám já, takže značka drží pohromadě napříč webem, e-shopem i tištěnými materiály.
Postarám se o web, který už máte: aktualizace, zálohy, bezpečnost, monitoring dostupnosti a SEO správa s měsíčním reportem. Převezmu i web po jiném dodavateli.
02 · Software, který jsem postavil
Systémy, které denně běží ve výrobě, v energetice, v provozech i v terénu na mobilech. Klienty neuvádím jmenovitě, ale technický rozsah a výsledky jsou reálné.
Dvě propojené aplikace pro výrobce automotive komponentů: docházka pro evidenci směn a skladová webová aplikace s tiskem a skenováním čárových kódů. Operátor naskenuje štítek dílu ruční čtečkou a hned na displeji vidí, ke které objednávce díl patří a do které lokace ve skladu jde.
Naskladňování běželo na papírech a v Excelu. U každého dílu musel operátor ručně dohledat, ke které objednávce patří a kam ve skladu jde. Zdržovalo to na hale a vznikaly chyby, díly končily ve špatné lokaci nebo u špatné objednávky. Docházka se vedla zvlášť a podklady pro mzdy se na konci měsíce skládaly ručně.
Pracoval jsem napřímo s provozem a IT zákazníka. Backend jsem napsal v .NET nad MySQL, frontend kombinací Vue (skenovací obrazovka, fronty štítků) a jQuery. Skladová aplikace běží přímo v prohlížeči na stávajících ručních čtečkách s displejem, takže odpadl nákup hardwaru. Skenovací obrazovku jsem ladil na latenci, odpověď ze serveru se vrací v desítkách milisekund. Štítek nejde vytisknout bez vazby na objednávku a lokaci.
Řídicí systém v .NET, který sbírá data z měničů a baterií, řídí nabíjení i vybíjení a hlídá stav instalací. K němu servisní portál v Angularu a PHP pro vzdálený dohled, alarmy a evidenci zásahů. Systém dnes běží na instalacích v ČR i Německu.
Provozovatel spravoval rostoucí počet fotovoltaik s bateriovými úložišti, ale neviděl na jedno místo, co se v terénu děje. Měniče a baterie byly od různých výrobců, každá značka měla vlastní rozhraní. Poruchu technik zjistil až z telefonátu zákazníka, klidně s několikadenním zpožděním. Nabíjení a vybíjení se neřídilo centrálně, takže úložiště běžela pod svým potenciálem.
Rozdělil jsem to do dvou vrstev. Řídicí systém v .NET běží jako služba, přes Modbus TCP a API výrobců se připojuje k měničům a battery management systémům, sjednocuje data z různých značek do jednoho modelu a ukládá je do SQL. Nad daty běží logika: hlídá stav nabití, teploty a chybové kódy, podle pravidel a tarifu rozhoduje o nabíjení a vybíjení a vyhlašuje alarmy. Servisní portál je samostatná aplikace v Angularu nad PHP API, běží nezávisle na řídicí vrstvě a otevře se z mobilu i z kanceláře.
Vlastní rezervační systém pro síť wellness studií s několika pobočkami. Klienti se objednají online kdykoliv, personál má sdílený kalendář napříč pobočkami a připomínky chodí automaticky. Po nasazení klesly no-shows a většina rezervací se přesunula z telefonu na web.
Pobočky braly rezervace po telefonu a zapisovaly je do papírových diářů. Recepce strávila hodiny denně zvedáním hovorů a přepisováním termínů. Diáře byly oddělené, takže nikdo neviděl obsazenost přes celou síť. Největší ztráty dělaly no-shows: klient zapomněl, slot zůstal prázdný a personál se to dozvěděl, až když nikdo nepřišel.
Postavil jsem to jako jednu aplikaci se dvěma vrstvami: veřejnou rezervaci pro klienty a administraci pro personál. Backend běží na Laravelu nad MySQL. Volné termíny počítá server z délky služby, otevírací doby a směn konkrétního zaměstnance, takže dvojí obsazení slotu nevznikne. Rezervační frontend je ve Vue jako průvodce ve čtyřech krocích. Připomínky odbavuje fronta a naplánovaná úloha, takže běží na pozadí.
E-shop na WordPressu a WooCommerce napojený přímo na skladový a fakturační systém klienta. Ruční přepisování objednávek a stavů skladu nahradila obousměrná synchronizace přes pluginy, které jsem napsal na míru jejich API. Zpracování objednávky se z minut zkrátilo na sekundy a běží bez ručního zásahu.
Klient prodával rozsáhlý katalog, ale e-shop a interní systém spolu nemluvily. Sklad se přepisoval ručně dvakrát denně, takže na webu viselo zboží, které už nebylo skladem. Každou objednávku někdo ručně opsal do fakturace a založil zásilku u dopravce. V sezóně to bylo zdlouhavé a náchylné k chybám.
Místo univerzálního konektoru jsem napsal dva vlastní pluginy přímo na API klientova ERP. Synchronizaci skladu jsem postavil přírůstkově (posílám jen deltu podle časové značky) a doplnil row-level zámky v MySQL, aby se objednávka a import neprali o stejné SKU. Po zaplacení se objednávka automaticky pošle do fakturace, vystaví faktura a přes API dopravce vygeneruje štítek. Celé to běží idempotentně, takže opakovaný běh nezaloží duplicitu.
Interní systém, který firmě na zakázkovou výrobu nahradil několik Excelů a papírové průvodky. Zakázky, výroba, klienti i fakturace jsou na jednom místě a vedení vidí stav v reálném čase.
Zakázky se vedly v několika oddělených Excelech a na papírových průvodkách. Data se ručně přepisovala mezi obchodem, výrobou a fakturací, vznikaly duplicity a chyby. Nikdo neměl aktuální přehled, co je rozpracované a co po termínu. Když někdo onemocněl, jeho Excel uměl přečíst jen on.
Strávil jsem čas přímo ve výrobě a prošel reálnou cestu zakázky od poptávky po fakturu. Z toho jsem navrhl normalizovaný datový model v MySQL a postavil REST API v .NET s rolemi pro obchod, mistra a vedení. Frontend je v Angularu jako SPA. Stav zakázky se posouvá přes pevný workflow a každá změna se zapisuje do historie. Historická data jsem přenesl z Excelů importem a nasazoval po modulech.
Převzal jsem rozpracovanou interní aplikaci, kterou předchozí dodavatel opustil bez dokumentace a s pravidelně padajícím provozem. Během několika týdnů jsem ji stabilizoval, opravil kritické chyby a dopsal chybějící funkce, takže ji firma mohla nasadit do ostrého provozu.
Firma měla rozdělanou objednávkovou a fakturační aplikaci po dodavateli, který spolupráci ukončil. Běžela na PHP 7.2 a jQuery, bez dokumentace, bez verzování (zdroják se posílal přes FTP) a bez testů. V provozu padala několikrát týdně, generování faktur občas skončilo bílou obrazovkou a SQL dotazy se skládaly přímo z $_POST. Firma řešila, jestli projekt dodělat, nebo zahodit.
Přepis od nuly nedával smysl. Funkční jádro tam bylo, jen mimo kontrolu. Naskočil jsem do existujícího kódu: zprovoznil lokální prostředí, založil Git a zmapoval, co aplikace dělá a kde leží největší rizika. Pak jsem izoloval příčiny pádů, opravil je a teprve na stabilní základ navázal refaktorem a chybějícími funkcemi. Po menších krocích, s nasazováním do stagingu.
Nativní Android aplikace pro řidiče rozvozové firmy. Řidič má na firemním telefonu celou trasu, u předání naskenuje čárový kód zásilky, vyfotí doručení a nechá podepsat na displeji. Aplikace funguje i tam, kde není signál, a data dosynchronizuje, jakmile je řidič zpět online. Nasazená je jen do firmy přes MDM, ne přes Google Play.
Řidiči jezdili s papírovými rozpisy tras a doručení potvrzovali podpisem na papír. Dispečink neviděl v reálném čase, co je doručené a co ne, a stav se do systému přepisoval až večer z papírů. Na trase byla navíc hluchá místa bez signálu, takže jakékoliv webové řešení tam přestalo fungovat zrovna ve chvíli, kdy ho řidič potřeboval. Reklamace „balík nedorazil" se dohledávaly těžko, důkaz o předání chyběl.
Tohle byl případ, kde webová aplikace nestačí. Napsal jsem nativní Android aplikaci v Kotlinu, která je od začátku offline-first: pracuje nad lokální SQLite databází v telefonu a se serverem (.NET a REST API) se synchronizuje na pozadí, když je připojení k dispozici. Skenování čárových kódů běží přímo přes fotoaparát, podpis se kreslí na displej a foto doručení se ukládá lokálně a nahraje později. Aplikaci firma rozdistribuovala na služební telefony přes MDM, takže není a nemusí být v Google Play.
Progresivní webová aplikace pro techniky, kteří v terénu provádějí revize a servisní prohlídky. Technik si ji nainstaluje z odkazu na plochu telefonu, vyplňuje protokoly i bez signálu, přikládá fotky a po návratu k signálu se vše dosynchronizuje a vygeneruje PDF protokol. Jedna aplikace pro Android i iPhone, žádné čekání na schválení v obchodě.
Technici vyplňovali revizní protokoly na papír a večer je přepisovali do počítače. Přepis byl zdvojená práce a vznikaly v něm chyby, občas se protokol ztratil úplně. Firma zvažovala mobilní aplikaci, ale nechtěla řešit dvě verze pro Android a iPhone ani schvalování v obou obchodech a instalaci přes obchod na desítkách zařízení techniků. K tomu revize probíhají v kotelnách a technických místnostech, kde signál většinou není.
Zvolil jsem PWA, protože pokrývá obě platformy jedním kódem a nasazuje se odkazem, ne přes obchod. Frontend je ve Vue, offline zajišťuje Service Worker a rozpracované protokoly i fotky drží IndexedDB přímo v prohlížeči, takže technik pracuje bez signálu. Jakmile je zařízení online, data se odešlou na backend v Laravelu, který z nich vygeneruje PDF protokol a založí záznam. Aplikace se instaluje „přidat na plochu", chová se jako běžná appka a firma ji má jen pro své techniky.
03 · Weby
Vedle systémů dělám i klasické weby a prezentace. Tady jsou tři, na které se dá kliknout.
Web pro prodej pozemků s vlastní administrací parcel, galerií a dokumenty ke stažení.
Případová studie →
Prezentační web pro krejčovství: služby, ukázky práce a snadný kontakt.
Případová studie →
Web pro úklidovou firmu s poptávkovým formulářem a přehledem služeb.
Případová studie →04 · Recenze
Skutečná hodnocení od klientů, načtená živě z mého Google profilu.
05 · Kdo jsem
Jsem Jakub Podhaiský a dělám full-stack v PHP, Laravelu, .NETu, Angularu, Vue i jQuery. Bavíte se přímo se mnou, ne s obchodníkem, který kód jenom předává dál. Klidně naskočím do rozpracovaného nebo cizího projektu a dotáhnu ho. Sídlím v Mariánských Lázních, beru práci v celém Karlovarském kraji, po celé ČR, v Německu i vzdáleně.
Píšu kód a zároveň ho s vámi řeším. Žádný prostředník mezi námi není.
Zorientuju se v zděděném projektu a navážu na to, co už máte hotové.
Celý stack zvládnu sám, takže máte na všechno jeden kontakt.
06 · Postup
Čtyři kroky od prvního hovoru po běžící projekt. Po celou dobu jednáte přímo se mnou.
Probereme, co potřebujete, k čemu to má sloužit a v jakém stavu je případný stávající kód.
Navrhnu technické řešení, zvolím stack a dám vám konkrétní cenu i termín.
Vyvíjím v krátkých iteracích a průběžně posílám funkční ukázky. Vidíte postup a můžete korigovat směr.
Aplikaci nasadím do provozu a dál se o ni starám: úpravy, rozšíření, údržba.
// Úvodní konzultace je nezávazná a zdarma.
07 · FAQ
Na tyhle věci se mě lidé ptají nejčastěji. Pokud vám něco chybí, napište mi a odpovím napřímo.
08 · Kontakt
Napište mi v pár větách, co potřebujete. Podívám se na to a navrhnu, jak na to. Bavíte se rovnou se mnou, ne s formulářem.
// Odpovídám obvykle do 24 hodin. První konzultace nic nestojí.
