Interní systémy a administrace
Evidence, workflow, přehledy, schvalování, správa dat nebo nástroje, které nahrazují ruční práci v tabulkách a e-mailech.
Nejde o uzavřený katalog služeb. Tohle jsou typické situace, kde dává zakázkový vývoj smysl.
Evidence, workflow, přehledy, schvalování, správa dat nebo nástroje, které nahrazují ruční práci v tabulkách a e-mailech.
Serverová logika aplikace, datové rozhraní pro frontend nebo mobilní aplikaci, autentizace, oprávnění a zpracování dat.
Propojení aplikací přes API, synchronizace dat, importy a exporty nebo automatické předávání informací mezi službami.
Nové funkce, opravy problémů, refactoring problematických částí nebo převzetí rozpracovaného systému.
Úlohy, které dnes někdo opakovaně dělá ručně: zpracování dat, notifikace, reporty, synchronizace nebo dávkové operace.
Když běžný SaaS nástroj nesedí na způsob práce firmy a vlastní řešení má jasnou provozní hodnotu.
Vlastní software není automaticky lepší než hotová služba. Pokud existuje rozumný nástroj, který problém vyřeší levněji a bez vývoje, je často správná volba použít ho.
Zakázkový vývoj začíná být zajímavý ve chvíli, kdy současný proces stojí pravidelně čas nebo peníze, potřebujete propojit několik systémů, chybí důležitá funkce, nebo se firma musí přizpůsobovat softwaru místo toho, aby software podporoval její práci.
První krok proto není seznam funkcí, ale pochopení problému a hranic řešení.
U menšího zásahu může být celý proces výrazně kratší. U většího systému je naopak důležité nerozjet vývoj bez jasných priorit.
Stačí současný stav, co nefunguje a čeho chcete dosáhnout. Hotová technická specifikace není podmínkou.
Rozdělíme nutné funkce od věcí, které mohou počkat, a ověříme hlavní technická rizika.
Podle typu práce vznikne konkrétní zadání, odhad nebo menší první etapa.
U větších systémů je bezpečnější dodávat funkční části a průběžně ověřovat, že řeší skutečný problém.
Po předání může projekt skončit, nebo pokračovat dalšími etapami podle reálného používání.
Primárně backendový webový vývoj. Konkrétní architektura se odvíjí od projektu a od toho, do čeho se řešení napojuje.
Vývoj aplikační logiky, datových modelů, administrací a serverových částí webových aplikací.
Návrh dat, migrace, importy, exporty, validace a zpracování větších nebo nepravidelných datových toků.
Návrh vlastních rozhraní i napojení na služby třetích stran, včetně autentizace a chybových stavů.
Ne každý systém potřebuje přepis. Často je rozumnější odstranit největší problémy a modernizovat po částech.
Sídlím u Borovan v okrese České Budějovice. Zakázkový PHP a backendový vývoj řeším online, takže spolupráce není omezená lokalitou — dává smysl pro firmy z Českých Budějovic, Jihočeského kraje i celé České republiky.
Typicky jde o interní systémy, API a integrace, automatizaci procesů nebo převzetí a další rozvoj existující webové aplikace.
Ne. Pro první posouzení je důležitější popsat současný problém, kdo systém používá, co dnes zabírá čas a jak má vypadat lepší stav. Technické zadání lze zpřesnit až potom.
Ano, pokud je možné získat přístup ke zdrojovým kódům a provoznímu prostředí. Nejdřív je ale potřeba zjistit stav projektu a rozsah technického dluhu, protože ten se bez kontroly nedá spolehlivě odhadnout.
Primární zaměření je PHP a backendový webový vývoj. U integrací a existujících systémů je ale běžné pracovat i s dalšími technologiemi přes API, databáze a standardní webová rozhraní.
Bez znalosti zadání by konkrétní cena byla jen hádání. Malá úprava existující aplikace a nový interní systém jsou úplně jiné zakázky. Po prvním posouzení lze určit rozumný rozsah a způsob nacenění.
Ano. U nejistějšího nebo většího projektu je to často bezpečnější než objednat celý systém najednou. První etapa může ověřit technické řešení, integraci nebo nejdůležitější část workflow.
Poptávku lze poslat kdykoli. Konzultace a komunikace probíhají online po předchozí domluvě a na projektu můžeme spolupracovat bez ohledu na to, zda jste z Českých Budějovic, Jihočeského kraje nebo jiné části ČR.
Žádný dotaz neodpovídá hledání.
Nemusíte psát specifikaci. Stačí popsat současný stav, problém a očekávaný výsledek.
Popište problém. Pokud bude dávat větší smysl hotová služba nebo menší zásah do současného řešení, není důvod stavět aplikaci od nuly.