Jdeme s dobou a vyvíjíme digitální řešení, která pomáhají firmám uspět.
V našem týmu se spojují špičkové technologie s hlubokou znalostí oboru. Díky tomu stavíme funkční řešení přímo na míru vašim potřebám.
Ať jste startup, nebo velká firma, která se chystá na změnu, jsme partner, se kterým z technologií vytěžíte maximum.
Orchestrátor vývojového procesu poháněný AI. Jediný pokyn spustí devět kroků: větev, architektura, kód, review, oprava, testy, e2e, dokumentace, merge.
AITM nenahrazuje Claude Code, Cursor ani jiný AI nástroj na programování. Řídí je. Ukážete mu na modely, které už platíte, a on kolem nich postaví celý proces, záchytnou síť a paměť projektu.
Přejít na aitm.cz
Vyvíjíme aplikace kompletně, od rozhraní v prohlížeči až po systémy, které běží na pozadí.
Full-stack znamená, že celou cestu od prohlížeče po databázi drží jeden tým. Nic se nepředává mezi dodavatelem frontendu a dodavatelem backendu a nikdo se nehádá, na které straně chyba vznikla. Postavíme rozhraní, služby za ním, datový model pod nimi i nasazení, které to všechno dostane do provozu. Za výsledek odpovídá jeden tým.
Na frontendu pracujeme s dnešním ekosystémem Reactu a TypeScriptu, ale konkrétní volba se odvíjí od produktu. Obsahový web a operátorská konzole mají jiné potřeby, a když se pro obojí zvolí stejný framework, projekt si naloží váhu, které se pak nezbaví. Víc než jak rozhraní vypadá v ukázce se třemi řádky nás zajímá, jak se chová nad skutečnými daty.
Backend obvykle tvoří několik dobře oddělených služeb, někde mezi jedním velkým blokem a třiceti drobnými. Většina firem nemá takový provoz, aby jim provozní náklady mnoha služeb za to stály, a ty, které ho mají, ho málokdy mají hned první den. Architekturu volíme podle problému, který máme před sebou, a necháváme prostor rozdělit ji později.
Nejvíc péče dáváme do datového modelu, protože je to jediné rozhodnutí, jehož změna je opravdu drahá. Schéma stavíme kolem otázek, které si firma bude klást, protože ty přetrvají déle než dnešní obrazovky. Migrace verzujeme a děláme je vratné a každá změna schématu jde do provozu spolu s kódem, který na ní závisí.
Začínáme krátkým průzkumem: co má systém umět, co nesmí udělat nikdy a která z uvedených omezení obstojí, když se zeptáme, proč vlastně platí. Ten rozdíl je důležitý, protože překvapivá část technických požadavků se ukáže být zvykem po předchozím dodavateli. Co jsme si dohodli, zapíšeme a ten dokument s prací dál žije.
Každá práce jde stejnou cestou: větev, automatická kontrola, testy a merge teprve tehdy, když všechno projde. Do provozu se nic nedostane proto, že si byl někdo jistý. Je to ta samá pipeline, kterou popisujeme u automatizace DevOps, a platí pro naši práci dřív, než ji začneme chtít po někom jiném.
Zdrojový kód máte od prvního týdne, ve svém repozitáři a pod licencí, která vám nic nesvazuje. Není tu žádná fáze na konci, kdy se kód předává proti poslední faktuře. Když se rozhodnete pokračovat s jiným dodavatelem, všechno, co potřebuje, už máte v ruce.
Dokumentace vzniká spolu se systémem, ne dodatečně po paměti. Každá služba má readme s tím, k čemu je a jak ji rozjet lokálně, a rozhodnutí, která ji zformovala, jsou zapsaná i s důvody. Nový člověk má být užitečný během několika dní.
Práce v krátkých cyklech, která drží krok s vašimi potřebami.
Agile je způsob, jak zlevnit omyl. Žádné zadání nepřežije kontakt se skutečnými uživateli, takže rozhoduje, jak rychle se plán dokáže změnit, když realita dorazí. Pracujeme v krátkých cyklech a každý z nich končí něčím, co si můžete otevřít a používat.
Cyklus trvá dva týdny. Začíná rozhovorem o tom, co je právě teď nejdůležitější, a končí funkčním softwarem na testovacím prostředí, kterým si můžete projít. Mezi těmito dvěma body je rozsah cyklu chráněný, protože tým, který se přeplánovává každý den, nikdy nic nedokončí.
Jako první se staví to, co nese největší riziko nebo největší hodnotu, podle toho, co je urgentnější. Věci příjemné, ale nikoli nosné, počkají. Zpočátku je to nepohodlné, protože vyladěné části přicházejí až později, ale znamená to, že drahá zjištění přijdou v době, kdy je na reakci ještě rozpočet.
Odhady dáváme jako rozsah a upravujeme je, jak tým poznává látku. Jedno sebevědomé číslo je téměř vždy fikce a brát ho jako závazek znamená udělat z prvního zdržení krizi. Radši řekneme, co ještě nevíme.
Práci vidíte, jak vzniká. Testovací prostředí se aktualizuje při každém merge a jste v něm vítaní kdykoliv. Většina oprav, na kterých záleží, vznikne tak, že si to někdo od vás zkusí a řekne: takhle my ale nepracujeme.
Každý cyklus končí krátkým shrnutím práce a ještě kratším shrnutím toho, jak nám šla spolupráce. To druhé se časem nasčítá nejvíc. Drobná zadrhnutí, o kterých nikdo nemluví, stojí za rok víc než jakékoli jednotlivé technické rozhodnutí.
Psaná zadání nezmizela, jsou jen krátká a udržovaná. Chování popisujeme příklady a akceptačními kritérii, která se dají otestovat, takže si obě strany můžou ověřit, na čem jsme se dohodli.
I agile potřebuje plán. Roadmapa existuje a má tvar, jen se k ní vracíme každý cyklus. Od tradičního plánu se liší tím, že se změny očekávají, takže je nikdo nebere jako selhání.
Rychlejší vývoj a nasazení díky automatizaci a CI/CD.
Nasazení má být nezáživné. Když je vydání složité, tým vydává zřídka, a zřídkavá vydání jsou velká, tím riskantní, a tým proto vydává ještě méně často. Rozseknout tuhle smyčku je většina toho, k čemu je práce na DevOps. Cílem je vydání tak malé, aby bylo nuda.
Každá změna jde stejnou automatickou cestou: build, statická analýza, unit testy, integrační testy a nasazení na testovací prostředí. Pipeline je jediná cesta do provozu. Ruční obejití neexistuje, protože obejití použité jednou se stane obejitím používaným ze zvyku.
Infrastrukturu popisujeme kódem a verzujeme spolu s aplikací. Prostředí se z toho popisu staví znovu, takže se testovací a produkční nemůžou potichu rozejít. Jak infrastruktura vypadá, si každý přečte.
Vrácení změny se navrhuje před prvním nasazením, ne improvizuje během první nehody. Databázové migrace píšeme tak, aby předchozí verze aplikace běžela i nad novým schématem. Právě to dělá z rollbacku něco, co se dá skutečně použít.
Nejdřív změříme, co je vlastně pomalé. Někdy jsou to testy, jindy schvalovací krok, o kterém si nikdo nepamatuje, kdo ho zavedl, a někdy je to jeden člověk, který je jediný, kdo umí nasadit. Náprava je v každém případě jiná a hádání stojí týdny.
Monitoring pokrývá to, co zajímá firmu, což se obvykle grafuje horší než procesor. Doby odpovědí a chybovost jsou důležité, ale stejně tak neúspěšné platby nebo fronta úloh, která se přestala hýbat. Alerty ladíme tak, aby alert znamenal, že někdo zasáhne. Kanál plný šumu si lidé ztlumí a pak monitoring nemáte.
Tajemství držíme mimo repozitář od prvního commitu, v pořádném trezoru a s rotací. Dodělávat to potom, co se přihlašovací údaje rozšíří po kódu a po historii chatu, je mnohem víc práce než udělat to hned.
Volíme radši nudné a dobře prozkoumané nástroje než cokoliv nového. Infrastruktura nás přežije a lidé, kteří ji zdědí, mají poznat, na co se dívají. Cokoliv chytrého se musí proti tomuhle měřítku obhájit.
Ověření nápadu dřív, než do něj vložíte větší peníze.
Prototyp má odpovědět na otázku a první práce je shodnout se, na kterou. Porozumí tomu lidé? Je to technicky zvládnutelné při našem objemu dat? Zaplatil by to zákazník? Každá z nich si žádá jiný prototyp, a když se postaví nesprávný, promarní se přesně ten čas, který měl ušetřit.
Na otázku o porozumění stačí klikací maketa. Vypadá jako hotová věc, reaguje na kliknutí a za ní není postavené nic. Vznikne během několika dní a ještě tentýž týden ji můžete dát lidem do ruky. Většina nedorozumění, která by build vykolejila, se objeví tady.
Na otázku o proveditelnosti stavíme úzký výsek, který vede až dolů: skutečná data, skutečná integrace, skutečná zátěž. Zvládne jednu cestu a nic jiného. Pokud má být složitá část složitá, je lepší to zjistit teď než v pátém měsíci.
Na otázku o poptávce často není prototypem téměř žádný software. Přistávací stránka, ruční proces za ní a možnost dát najevo zájem řeknou o ochotě zaplatit víc než hotový produkt.
Na začátku se dohodneme, jaký výsledek by znamenal nápad odložit. Prototyp, který nemůže dopadnout špatně, je ukázka, a ukázka se povede vždycky. Právě pojmenování podmínky selhání dělá z celého cvičení poctivou věc.
Prototypy stavíme tak, aby se zahodily, a říkáme to naplno. Kód si bere zkratky, které by v provozu byly nezodpovědné, protože to, co si necháte, je poznání. Povyšování prototypu do provozu je způsob, jakým firmy získávají svůj nejhorší technický dluh.
Poznání ale zapisujeme řádně. Každý prototyp končí krátkým textem: co jsme se ptali, co jsme udělali, co se stalo a co doporučujeme. Ten dokument je výstup.
Když prototyp build obhájí, začínáme naostro a nanovo, s tím, co jsme se naučili, a prototyp jde do koše. Architekturu volíme se vším, co nás prototyp naučil, a to je obvykle docela jiný návrh než ten, pro který bychom se rozhodli předtím.
Provázíme tým změnou a zaváděním nových postupů.
Většina agilních transformací skončí potichu. Rituály se drží, tabule se aktualizuje, slovník se přejme, a na tom, jak se rozhoduje, se nezmění nic. My pracujeme na rozhodování a rituály z něj necháváme vyplynout.
První týdny sledujeme, jak tým skutečně pracuje. Sedíme na schůzkách, které už existují, čteme tikety a hledáme, kde práce opravdu čeká. Úzké místo bývá jinde, než si organizace myslí, a téměř nikdy nejsou příčinou vývojáři, kteří píšou pomaleji, než by mohli.
Změnu zavádíme po jednom postupu a vždycky s důvodem. Tým, kterému nařídíte denní standup, ho bude držet a bude ho nesnášet. Tým, který sám dojde k tomu, že opakovaně tratí den na zablokované práci, o které nikdo neřekl, ho bude držet a bude mu k něčemu.
Pracujeme s lidmi, kteří tam budou i po našem odchodu. Každý nový postup musí mít vlastníka uvnitř firmy, jinak vydrží přesně tak dlouho jako naše spolupráce. Najít tyhle lidi a podpořit je je velká část práce.
Manažerům se věnujeme zvlášť, protože většina zaseknutých změn se zasekne nad týmem. Když se manažer u práce výslovně označené jako průzkumná pořád ptá, kdy to bude hotové, tým mu bude dál dávat sebevědomé odpovědi a potichu si je nadsazovat.
Měření držíme poctivé. Sledujeme, jak dlouho trvá cesta od požadavku do provozu, kolik věcí je rozdělaných zároveň a jak často změna selže. Neměříme výkon na vývojáře, protože to číslo se zlepší snadno a neznamená nic.
Když se lidé brání, obvykle vědí něco, co my ne, takže je posloucháme. Kdo má proti novému postupu výhradu, většinou chrání něco skutečného, co ten postup ohrožuje. Zjistit, co to je, vede zpravidla k lepšímu postupu, než byl ten navržený.
Spolupráce končí záměrně, zápisem o tom, co se změnilo, co ne a na co si dát pozor. Kouč, který zůstane natrvalo, selhal. Naším cílem je tým, který si svůj proces umí upravit sám.
Orchestrace, agenti a propojení.
Jazykové modely začnou být užitečné ve chvíli, kdy přestanou být okénkem na chat a stanou se krokem v procesu, který běží sám. To tady znamená orchestrace: daná posloupnost, každý krok s vlastní úlohou, kontroly mezi nimi a výsledek, který skončí někde, kde ho člověk uvidí.
Nejjasnější příklad je náš vlastní produkt AITaskManager. Z jediného pokynu vznikne větev, návrh architektury, implementace, review, opravy, testy, koncové kontroly a merge. Každý krok je samostatné volání modelu s vlastním kontextem a vlastní podmínkou úspěchu a pipeline se zastaví, když se výsledek vrátí špatný.
Agenty stojí za to použít tam, kde se úloha skutečně větví a další krok závisí na tom, co našel ten předchozí. Kde je cesta pevná, je obyčejná posloupnost levnější, rychlejší a mnohem snáz odladitelná. Velká část naší práce je tyhle dva případy rozeznat, protože agentní frameworky se často používají na problémy, které se nikdy nevětvily.
Nejvíc práce spolkne propojení. Model, který si neumí přečíst vaše data a nemá kam zapsat výsledek, je ukázka. Připojujeme modely k systémům, na kterých firma běží: k CRM, k ERP, k ticketům, k úložišti dokumentů, k interním databázím.
Každé propojení má výslovná oprávnění a plný audit. Model, který smí zapisovat do produkčního systému, potřebuje stejnou kontrolu jako zaměstnanec se stejným přístupem, a obvykle přísnější. Akce, které mění data, se logují včetně vstupu, který je vyvolal.
Selhání počítáme od začátku. Modely vrací rozbitý výstup, poskytovatel neodpoví a limit na počet dotazů dorazí v nejnevhodnější chvíli. Každý krok má daný postup pro případ, že volání selže, takže když se to zhorší, zhorší se to tak, jak někdo rozhodl.
Náklady jsou vidět už při stavbě, ne až na první faktuře. Každý krok hlásí, kolik tokenů spotřeboval, a cenu jednoho běhu známe dřív, než jde do denního provozu. Pipeline, která je v testech levná, umí v produkčním objemu překvapit.
O tom, co tahle technologie umí, mluvíme bez romantiky. Je silná v převádění textu, v hledání struktury v nepořádku, v návrzích, klasifikaci a shrnování. Je slabá v počtech, ve všem, co potřebuje záruku, a v rozpoznání toho, že se mýlí. Systémy stavíme s ohledem na obě poloviny.
Modely opřené o vaše dokumenty, s pojistkami a provozem u vás ve firmě.
Pod pojmem natrénovat model na našich datech se skrývají dvě různé věci a jejich záměna stojí opravdové peníze. Retrieval-augmented generation vaše dokumenty vyhledá v okamžiku dotazu a předá je modelu jako kontext; data zůstávají ve vaší databázi a dají se kdykoliv upravit nebo smazat. Doladění mění samotný model, aby přejal styl nebo formát. Téměř na každou poptávku po tom druhém odpovídá lépe to první.
Vyhledávání je výchozí volba, protože je opravitelné. Když je odpověď špatně, vidíte, který dokument ji způsobil, a dokument opravíte. Doladěný model, který si osvojil chybný fakt, žádnou takovou páku nedává a náprava znamená trénovat znovu.
Kvalita vyhledávání je víc problém hledání než modelu. Dokumenty se musí rozumně rozdělit, indexovat podle významu i klíčových slov a před předáním modelu přeřadit podle relevance. Když takový systém zklame, viníkem je zpravidla vyhledávání: najde nesprávné pasáže a model z nich věrně odpoví.
Doladění se vyplatí na ustálenou formu: firemní styl, pevná struktura výstupu, oborový slovník, se kterým si základní model neví rady. Učit jím fakta je špatná cesta, protože fakta se mění a modely se samy neaktualizují.
Pojistky určují, co systém smí. Vstupy se kontrolují, než dojdou k modelu, výstupy, než dojdou k člověku, a cokoliv, co se týká peněz, smluv nebo osobních údajů, se dá poslat člověku ke schválení. Kde nejde odpověď opřít o nalezený zdroj, je poctivé to říct, i když by model dokázal vytvořit něco, co se dobře čte.
Vyhodnocení dělá z hranic měřitelnou věc. Postavíme sadu testovacích otázek se známými správnými odpověďmi z vašeho skutečného materiálu a pouštíme ji na každou změnu. Bez toho se změna, která působí jako zlepšení, nedá odlišit od té, která potichu zhorší případ, na který nikdo nezkusil sáhnout.
Kde data nesmí opustit firmu, provozujeme open-weight modely na vašem hardwaru. Llama, Qwen, Mistral a jim podobné už na vyhledávání, klasifikaci, extrakci a návrhy textu stačí. Na složité usuzování se největším hostovaným modelům nerovnají a my rovnou řekneme, když je úloha nad jejich síly.
Provoz u vás je závazek v infrastruktuře a počítáme ho poctivě: GPU, paměť a někdo, kdo to udrží v chodu. U regulovaných dat nebo u vysokého stálého objemu to často vyjde levněji než platba za tokeny. U malého nebo nepravidelného objemu obvykle ne a řekneme to, než hardware koupíte.
Najdeme jeden opakovaný proces, zautomatizujeme ho a změříme, co ušetřil.
Hodně firem ví, že by měly s AI něco dělat, a nemá jak se rozhodnout co. Obvykle z toho vyjde pilot bez vlastníka a bez měření, který ani neuspěje, ani nespadne, a potichu spolkne rok. My začínáme z druhé strany: najdeme opakovanou ruční práci a teprve pak se ptáme, jaký nástroj na ni sedí.
Audit trvá dva až tři týdny. Jdeme za samotnou prací, sedíme s lidmi, kteří ji dělají, a počítáme, co jim bere čas. Nejčastěji vyjdou dokumenty, třídění požadavků na podporu a pravidelné reporty, ale konkrétní situace se liší dost na to, aby se vyplatilo nejdřív se podívat.
Každého kandidáta hodnotíme podle objemu, podle toho, co by stála chyba, a jak dobře je současný proces popsaný. Vysoký objem a nízká cena chyby dělají dobrý první cíl. Cokoliv, kde je chyba drahá, zůstává s člověkem ve smyčce, nejméně dokud měření neukáže něco jiného.
Pak vybereme přesně jednu věc a postavíme ji poctivě. Jediný funkční případ s reálnými čísly udělá pro přijetí ve firmě víc než pět současných pilotů, které všechny zůstanou rozdělané.
Než se začne stavět, změříme současný proces: jak dlouho trvá, jak často se pokazí, kolik stojí. Bez výchozího čísla není jak výsledek potom ukázat a každý další rozhovor se stane věcí názoru.
Když to běží, měříme znovu a ve stejných jednotkách. Někdy je úspora menší, než jsme čekali, a řekneme to. Změřený skromný výsledek má pro firmu podstatně větší cenu než nezměřený efektní, protože se z něj dá s klidem odhadnout, co bude dál.
Lidé, kterých se práce týká, jsou u toho od prvního týdne. Vědí, kde se skrývají výjimky, a jsou to oni, kdo rozhodne, jestli se systém bude používat, nebo se bude obcházet. Nástroj vnucený týmu se opustí do měsíce po skončení projektu.
O druhém případu se bavíme až po tom, co první obstojí v provozu. Firma pak má skutečný odraz pro to, co tyhle systémy stojí, co ušetří a kde potřebují dohled, a druhé rozhodnutí stojí na číslech.
Náklady, kvalita, dostupnost a dohledatelnost po spuštění.
O funkci s AI se po spuštění musí někdo starat. Poskytovatelé vám pod rukama mění modely, náklady se s rostoucím používáním posouvají a kvalita odpovědí klesá způsobem, na který se nikdy nevyhodí výjimka. Právě tady AI projekty potichu mizí, obvykle po nějakých šesti měsících.
Náklady sledujeme průběžně a přiřazujeme je k té části firmy, která je vytváří. Spotřeba tokenů se vykazuje po funkcích a po odděleních, s rozpočtem a alertem. Jedna špatně sestavená smyčka promptů umí měsíční účet znásobit a chcete ji zachytit tentýž den.
Kvalitu měříme proti pevné sadě referenčních případů, která běží podle rozvrhu. Sledujeme faktickou správnost proti známým odpovědím, ustálenost tónu a míru, s jakou systém tvrdí věci, které neumí podložit. Trend je důležitější než jedno číslo, protože ukáže posun, který se náhodnou kontrolou nepozná.
Poskytovatelé selhávají. Když volání vyprší nebo narazí na limit, provoz se automaticky přesune na záložního poskytovatele nebo na místní open-weight model. Která záloha je vhodná, závisí na funkci: návrh textu může sjet na menší model, zatímco extrakce, která plní finanční systém, se má zastavit a čekat ve frontě.
Aplikace mluví s naší vlastní tenkou vrstvou a ta mluví s poskytovatelem. Vyměnit model za nějakou funkcí je pak otázka konfigurace. Při tom, jak rychle se tohle pole hýbe, je aplikace zadrátovaná do jednoho dodavatele zátěží už ode dne spuštění.
Nové modely posuzujeme proti té samé referenční sadě, než je nasadíme. Novější model může být na vaší konkrétní úloze horší a výměna umí rozbít případ, který rok fungoval. Vyhodnocení to ukáže dřív, než to najdou vaši uživatelé.
Každá výměna se loguje: vstup, nalezený kontext, model, jeho verze, výstup a cena. Právě to umožní o tři měsíce později odpovědět na otázku, proč to systém řekl. Podle evropského nařízení o AI je to navíc čím dál víc něco, co musíte být schopni předložit.
Někdo drží pohotovost a v příručce je, co dělat. Na kterého poskytovatele přepnout, jak vypnout funkci bez toho, aby šla dolů celá aplikace, koho informovat. Většina AI nehod je tichá: pozvolné zhoršení, které nikdo nevlastnil. Vlastnictví je smyslem téhle práce.
Držíme se agilních principů a hodnot tak, jak je popisuje Agilní manifest, aby měly naše produkty hodnotu i kvalitu.
TC Dev tvoří IT profesionálové, kterým záleží na tom, aby zákazník dostal to nejlepší řešení. Každý z nás přináší jiný pohled a jiné schopnosti, takže problém řešíme z více stran a máme z čeho vybírat. Silný tým poznáte podle společného cíle a vize. U nás cílům každý rozumí a stojí za nimi, takže za výsledek cítíme odpovědnost všichni.
Firmu založili Ondřej Trochta a Paula Costa poté, co spolu dotáhli projekt průmyslové automatizace. Jejich schopnosti, zájmy, odlišné pohledy a shoda v tom, že tým má fungovat zdravě, otevřeně a ve spolupráci, byly semínkem, ze kterého firma vyrostla. Silný tým je základ úspěchu: umožňuje pracovat na maximum, přináší nové nápady a drží dobrou atmosféru.
„To nás vystihuje v jedné větě.“
Na větší projekty máme vlastní okruh IT specialistů v Česku i za jeho hranicemi. Věříme, že skvělá práce se dá odvést odkudkoliv, pokud u ní jsou správní lidé. Dobrý tým spojuje jednotlivce, kteří společně a efektivně míří ke stejnému cíli. Když se lidé dělí o znalosti a nápady a rozumí tomu, jak kdo pracuje, vznikají nová řešení a práce jde rychleji. Proto náš tým pracuje odtud, kde je doma. Víme, že ke skvělé práci patří dost odpočinku a pohodlí, a tak lidem dáváme možnost pracovat v klidu, s chutí a soustředěním, aby kvalita držela.
Jsme malá skupina lidí, která vyvíjí s pomocí AI. Modely přeberou opakovanou část práce, takže se produkt dostane od nápadu k běžícímu systému v týdnech místo čtvrtletí, a ušetřený čas věnujeme těm částem, které musí být přesné.
Rychlost a spolehlivost tu jdou ruku v ruce: každé další kolo zpřesní software, který už se používá, a nic se přitom nezahazuje. Bereme na sebe celou cestu, od první schůzky přes architekturu, kód a testování až po nasazení.
Máte-li v hlavě projekt, napište nám a probereme, co je možné.
Pošlete nám zprávu a ozveme se s otázkami, které bychom vám položili na prvním hovoru.
info@tcdev.czHledáme vývojovou práci: software od základů, rozšíření systémů, které už běží, i ruční rutinu předanou něčemu, co běží samo. Pokud se v tom poznáváte, krátký hovor je nejrychlejší způsob, jak zjistit, jestli si sedneme.
Webové aplikace, interní nástroje, API a integrace, od prvního nákresu až po provoz.
Opakovaná ruční práce, jako přenášení dat mezi systémy, reporty skládané v Excelu nebo schvalování dohánělo e-mailem, předaná něčemu, co běží samo.
Asistenti, zpracování dokumentů a privátní modely zapojené do systémů, které už používáte.
Nedokončený nebo zděděný kód projdeme, stabilizujeme a dotáhneme dál.
Na začátek nepotřebujete zadání ani hotový rozpočet. Napište nám, co má software dělat a kdo ho bude používat, nechte e-mail nebo telefon a my se ozveme s plánem, hrubou cenou a prvními kroky. Pokud je jednodušší si o tom promluvit, vyberte si níže termín hovoru.
Třicet nebo šedesát minut, podle toho, co se vám hodí. Obsazené časy se vůbec nezobrazují.
Pondělí až pátek, 9:00–17:00 pražského času, až týden dopředu. Vidíte pouze volné termíny, obsazené se vůbec nezobrazují.
Termín je pro vás držený. Otevřete zprávu, kterou jsme právě poslali na a projděte odkaz v ní — tím schůzku potvrdíte a zapíše se do kalendáře. Termín držíme .