Technológia
Átvesszük más csapat által elkezdett, félbehagyott vagy gazdátlanná vált szoftverprojekted, és végigvisszük. Először nem fejlesztünk, hanem értékelünk: a meglévő kódbázist AI-támogatott elemzéssel és senior architekt szintű manuális vizsgálattal végigjárjuk, és közérthető jelentésben mondjuk meg, mi vihető tovább, mi a rejtett kockázat, és mikor érdemesebb folytatni, mint újraírni. Őszintén közelítünk a témához: ha az újraírás gazdaságosabb, azt is megmondjuk. 19 év, 100+ IT-szakember, 120+ megvalósult projekt.
Egy szoftvert nem mindig ugyanaz a csapat fejleszti, aki elindította.
Tipikus helyzetek, amikor érdemes felkeresni minket:
A nyitószakasz nem a kódolás, hanem az értékelés. Ezt a lépéset egy senior szoftver architekt vezeti, AI-támogatott statikus elemzéssel és manuális vizsgálattal.
Sokan azt hiszik, hogy más csapat kódját nem lehet átvenni, mert a forráskód az eredeti fejlesztők nélkül nem sokat ér. Ez a félelem korábban jogos volt: egy ismeretlen kódbázis megértése emberi erővel hetekig tartott, garancia nélkül. Az AI ezt megváltoztatta. Az AI-támogatott statikus elemzés a függőségi gráfot, az architektúrát és a rejtett kockázatokat szisztematikusan, a korábbinál lényegesen rövidebb idő alatt tárja fel, így az átvétel ma megismételhető mérnöki folyamat, nem hőstett.
Mit nézünk meg?
Az eredmény
Strukturált jelentés a megrendelőnek: melyik rész erős, melyik kockázatos, milyen forgatókönyv reális a folytatáshoz, és milyen indikatív becsléssel az erőforrásokra. A jelentés vezetői összefoglalót is tartalmaz, hogy az ügyfél döntéshozói és pénzügyi oldala is megértse, mire vállalkozik.
Az értékelési fázis végén egy fontos kérdést teszünk fel: a folytatás vagy az újraírás a reálisabb?Az egyedi fejlesztő cégnek a folytatás üzletileg jobban jön, mert nagyobb scope-ot ad, és ezért is fontos, hogy a választ ne ez vezérelje.
„Hiába foglalkozom egyedi szoftverfejlesztéssel, azt mondom, ha valamilyen problémádra elérhető termék a piacon, akkor vedd meg azt és ne kezdj egyedi szoftver projektbe."
Máriás Zsigmond, LogiNet CEO
Ugyanez érvényes arra a kérdésre, hogy folytassuk vagy újraírjuk. Ha a meglévő kódbázis menthető, és az értékelés ezt mutatja, folytatjuk. Ha az architektúra rugalmatlan, a függőségek deprecated szintűek, a biztonsági rétegek hiányosak, és a karbantartási sebesség drámaian romlik, az újraírás költsége reális számokkal kalkulálható, és összevethető a folytatás várható kumulált költségével.
Fontos, hogy nem az újraírás felé tolunk. Az újraírás beszállítóként is drága és kockázatos, ezért nekünk is az az érdekünk, hogy azt használjuk fel, ami van, ott, ahol menthető. Nem önzetlenségről van szó: az őszinteség és a saját érdekünk egy irányba mutat.
A leggyakoribb harmadik út: stabilizációs fázis. AI-támogatott refaktorálás, automatizált tesztcsomag és néhány kritikus modul cseréje együtt sok esetben elegendő ahhoz, hogy az újraírás elhalasztható vagy elkerülhető legyen.
Az átvétel nem egyetlen aktus, hanem több szakasz, amelyek egy szerződésen belül futnak. Egyetlen csapat, egyetlen elszámolás, egyetlen support manager végig.
Új környezetre telepítés:Rendszergazda, devops szakember, architekt és projektmenedzser együttes munkája. Az új környezetet előkészítjük, a kódbázist áttelepítjük, monitoring-ot és naplózást építünk rá, a régi és az új rendszer párhuzamos futtatása megindul az átállás idejére, a domain átirányításhoz segítséget adunk. Jellemző átfutás: 1-3 hét.
Hibajavítások első hulláma:A priorizált hibalistát kis csomagokban élesítjük. Az érintett kódrészen alacsonyabb prioritású, könnyen javítható hibákat is végigvisszük a hatékonyság érdekében. Folyamatos kommunikáció, ticketing rendszerből transzparens állapot. Jellemző átfutás: 5-6 hét.
Opcionális stabilizációs csomag:A meglévő kódbázis részleges refaktorálása modern bevált gyakorlatok mentén, automatizált tesztek (unit, integration, end-to-end) a kritikus üzleti logikára, CI/CD pipeline felállítása, és 1 hónapos hypercare periódus az élesedés után. Ezzel teljes funkcionális garanciát vállalunk az egész rendszerre, nemcsak az új fejlesztésekre.
Opcionális frontend modernizáció: Ahol az átvétel utáni hosszú távú működés indokolja, a frontend modernizáció (Vue 2 → Vue 3, Blade + Livewire, React portolás) beilleszthető. Önállóan is futhat, de a stabilizációval együtt gazdaságosabb.
A LogiNet stacktől függetlenül vesz át rendszereket.Full-stack mérnöki csapat áll az átvétel mögött, több backend nyelvvel, több frontend kerettel és natív, illetve crossplatform mobillal, így a te rendszered állapotához igazodunk, nem egy előre kiválasztott technológiához.
Mit szállítunk?
Milyen stackeken?
Az erős stackjeink, amelyeken átveszünk és tovább viszünk rendszereket:
Ezeken is dolgozunk:Node.js (Express, Nuxt, Next), BaaS (Firebase, Supabase), React Native, Kotlin Multiplatform.
Az átvétel végeredménye nem egy kézhez adott kódbázis, hanem egy futó rendszer és a mögötte álló csapat.Egykézből dolgozik tovább az átvételi és a támogatási oldal, nincs újabb tudásvesztés.
A support és üzemeltetés szerződéses szinten fut tovább:
Választható:a támogatás nálunk marad, vagy egy későbbi ponton a dokumentáció átadásával átkerül a saját csapatodra.
Ez a szolgáltatás fókuszált.Az átvétel feltételezi, hogy a forráskód, a futtatási környezet és a hozzáférések rendelkezésre állnak, vagy szerződéses szinten megszerezhetők.
A teljes szoftveréletciklus 60-70 százaléka az üzemeltetés és karbantartás körüli munka. Ezt a részt sok fejlesztőcég struktúrából rosszul látja el, mert a saját fejlesztőik mindig egy új, jellemzően csúszó projekttel vannak elfoglalva.
A LogiNet külön támogatási csapatot tart fent: dedikált support manager, akihez beosztva dolgozik a fejlesztői csapat. Vannak ügyfeleink, akiket 8-15 éve támogatunk folyamatosan, és ahol az eredeti kódot nem is mi írtuk. Nagyvállalati ügyfeleink (Auchan, Vodafone) mellett közepes méretű cégeknek is hosszú éveken át szállítunk fejlesztést és supportot.
Full-stack mérnöki csapat vagyunk, és a PHP/Laravel-vonalon külön mélységünk is van: a magyar piacon az egyik legnagyobb PHP-fejlesztő csapatot tartjuk fent, közel 30 senior szintű Laravel fejlesztővel, és a vezető szakembereink az ELTE programtervező informatikus képzésen szerveroldali programozás tárgyakban tanítják a Laravel keretrendszert. Az átvételi projektekben ez konkrét mérnöki előny a régi PHP-kódbázisoknál: a régi kód mintáit gyorsabban érti meg az, aki a keretrendszer mélystruktúráját napi szinten oktatja. A többi stacken ugyanígy senior kompetenciával dolgozunk.
100+ IT-szakember, 19 év folyamatos piaci jelenlét, 120+ megvalósult projekt. Magyar tulajdonú cég, magyar mérnöki csapattal. Fix költségvetést és betartott határidőket vállalunk, kompromisszum és túligéret nélkül.
Ha kíváncsi vagy a fejlesztési filozófiánkra, nézd meg a tanácsadás szolgáltatásunkat vagy a rendszer auditot.
❓Mi a különbség a fejlesztés átvétel és a rendszer audit között?
A rendszer audit önálló, független értékelés a meglévő szoftvered állapotáról, ami a megrendelőé marad, és bármilyen döntéshez használható (folytatás a meglévő csapattal, beszállítóváltás, újraírás). Részleteket a rendszer audit szolgáltatás oldalán találsz. A fejlesztés átvétel ezzel szemben átvállalja a teljes utat: a felmérés, az új környezetre telepítés, a hibajavítás és a hosszú távú support egyetlen szerződésben fut. A két szolgáltatás kombinálható: érdemes először auditot kérni, és ennek eredménye alapján dönteni az átvételről.
⚡ Mennyi időt vesz igénybe egy átvétel?
A komplexitástól függ. Egy közepes méretű rendszer kódbázisának értékelése 1-1,5 hét, az új környezetre telepítés és deployment 1-3 hét, az első hibajavítási hullám 5-6 hét. A teljes átvételi projekt (értékelés + átállás + hibajavítás első hullám) tipikusan 2-3 hónap. Az opcionális stabilizációs csomag plusz 1-2 hónap, az opcionális frontend modernizáció ennél is nagyobb mértékben függ a mérettartománytól. Az értékelési szakasz után indikatív ütemtervet adunk a scope pontosítást követően.
♾️ Mi van, ha a meglévő kódbázis menthetetlen, és az újraírás a jobb út?
Az értékelési szakasz egyik fontos kimenete pont ez. Ha a vizsgálat azt mutatja, hogy az architektúra rugalmatlan, a függőségek deprecated szintűek, és a karbantartási sebesség drámaian romlik, az újraírást reális számsorral kalkulálható meg, és összevethető a folytatás várható kumulált költségével. A döntés a megrendelőé. Itt is őszinték vagyunk: az egyedi fejlesztő cégnek a folytatás üzletileg jobban jön, ezért is fontos, hogy a válasz ne ezt szolgálja. A leggyakoribb harmadik út a stabilizációs csomag, ami sok esetben elegendő ahhoz, hogy az újraírás elhalasztható vagy elkerülhető legyen.
⚓Vállaltok garanciát a meglévő kódra is, vagy csak az új fejlesztésekre?
Az alapcsomagban a saját új fejlesztéseinkre vállalunk 90 napos funkcionális garanciát, a korábban elkészített funkciók hibáira nem. Ennek oka egyszerű: nem tudjuk minden esetben kizárni, hogy az átadott kódbázisban rejtett hibák ne maradjanak. A megoldás a stabilizációs csomag: AI-támogatott refaktorálás, automatizált tesztek és code quality eszközök integrálása, 1 hónapos hypercare az élesedés után. Ezzel teljes funkcionális garanciát vállalunk az egész rendszerre, és lényegesen csökkennek az „egymásra mutogatós" helyzetek. Az ügyfél a kockázattűrése és a büdzséje alapján választ a két szint között.
☎️ Mobilalkalmazás átvétele iOS és Android oldalon hogyan zajlik?
A mobilalkalmazás átvétele sajátos technikai feladat. Az onboarding flow fix időkeretű (jellemzően 20-30 óra az első hónapban): a kódbázis elérése (Swift, Kotlin), backend-API megismerése, kiadói fiókok (App Store, Google Play) átállítása, a build és release folyamat újrafelépítése az új csapat eszközein. A korábbi fejlesztővel néhány technikai egyeztetés tisztázza a release folyamat egyedi lépéseit (signing, store metaadatok, jailbreak detektálás). Az ismerkedési fázisban próbajellegű hibajavítások és első support feladatok futnak. Az élesedés után SLA-val fedett support megy tovább, ahol a kritikus hibára 2 órán belüli első válasz és 2 munkanapon belüli végső megoldás a vállalási tartomány. Flutter és React Native átvételére hasonló folyamat érvényes, a stackre jellemző eltérésekkel.
⚙️ A meglévő ERP-mmel és a külső integrációkkal mi történik?
Maradnak. Az átvétel az alkalmazás rétegére fókuszál, az integrációk működése folyamatosan biztosított, és a régi és az új környezet párhuzamos futtatása a fizetési, ERP-szinkron és partner integrációk minimális kockázati szinten történő átállását célozza. A meglévő integrációk az értékelési szakasz egyik kifejezett vizsgálati pontja, és a kockázati jelentés külön szakaszt szentel nekik. Ha új integrációs réteg vagy middleware fejlesztés is szükségessé válik, az a fejlesztési hullámba beilleszthető.
⚖️ Milyen árazási modellben dolgoztok?
A komplexitástól függ. A kódbázis értékelésének szakasza fix óraszámon megy (jellemzően 24 óra körül), az átvétel és az első hibajavítási hullám fix scope-on és időkereten alapul, time & material elszámolással a 15 százalék feletti túllépésre. A hosszú távú support több modellben fut: havi lekötési modell (előre fizetett órakeret kedvezményesebb óradíjjal, fel nem használt órák egy hónapig átvihetők, dedikált support manager) vagy használatalapú (best effort SLA-val). Az értékelési szakasz lezárása után fix scope-ú ajánlatot adunk a továbbvitelre, és a megrendelő világosan látja, miért fizet.
☠️ Mi van, ha a régi fejlesztő nem hajlandó vagy nem tud együttműködni az átvételben?
Az átvétel első hetében jellemzően szükség van a korábbi fejlesztői és üzemeltetési csapat támogatására (forráskód biztosítása, hozzáférések biztosítása, felmerülő technikai kérdés esetén egyeztetés). Ha ez nem áll rendelkezésre, az átvétel attól még megvalósítható, de a kockázat magasabb, és az értékelési szakasz kifejezett figyelmet fordít a hiányzó tudás kompenzálására. Az AI-támogatott statikus elemzés ilyenkor különösen értékes, mert a kódbázis felépítését és a függőségi gráfot szisztematikusan tudjuk feltárni. A scope ilyen esetben rugalmasabb és nagyobb bufferrel kalkulált, a kockázattűrés és a büdzsé függvényében.
✅A projekt után ki üzemelteti a rendszert?
Választható. Vagy az üzemeltetés és supportszolgáltatásunk fut tovább transzparens SLA-val (több rendszerünket 8-10-15+ éve támogatjuk, az átvettek között is), vagy a saját csapatod veszi át a dokumentáció átadásával és tudásátadási folyamattal. Az átvétel során épített dokumentáció pontosan ezt a kettősséget szolgálja: bárhonnan folytatható.
Írd le, milyen rendszer átvételéről van szó, hol akadt el a fejlesztés, és mire lenne szükséged. Rövid időn belül jelentkezünk egy személyre szabott javaslattal.
Dokumentáció, technikai adósság és kódminőség → ezek mutatják meg, milyen kockázatokkal folytatható a rendszer fejlesztése. A fejlesztés átvétele előtt pontos képre van szükség a rendszer működéséről, technológiai állapotáról és karbantarthatóságáról. Az IT audit feltárja a kódbázis komplexitását, a függőségeket, a hiányzó dokumentációt és a technikai adósságot, így megalapozott döntés születhet a folytatásról, a refaktorálásról vagy az újraírásról.
Megnézem →
Üzleti szabályok, elfogadási kritériumok és működő prototípus → ezek adnak közös alapot az új fejlesztőcsapatnak. Egy félbehagyott vagy gazdátlanná vált projektben gyakran nemcsak technikai tudás vész el, hanem az is bizonytalanná válik, mit kellene befejezni. A szoftver specifikáció feltárja a meglévő működést, rendezi a hiányzó követelményeket, és prototípussal teszi kipróbálhatóvá a tervezett folyamatokat. Így az új csapat már tisztázott scope és ellenőrizhető elvárások alapján folytathatja a fejlesztést.
Megnézem →
Dedikált csapat, SLA és folyamatos karbantartás → így lesz az átvett kódbázisból hosszú távon működő rendszer. A fejlesztés átvétele nem ér véget az első hibák kijavításával. Az átvett szoftver mögé olyan supportfolyamat kell, amely kezeli a hibajegyeket, figyeli a rendszer működését, követi a technológiai változásokat és biztosítja a továbbfejlesztési kapacitást. A dedikált support manager, a fejlesztői csapat és a mérhető SLA kiszámítható keretet ad a hosszú távú működéshez.
Megnézem →
MarQR Tracking rendszer átvétel és újraépítés Félkész web- és mobilalkalmazás újraépítése auditálható eszközkövetéssel és QR-kódos azonosítással.
Részletek →
GLOBUS nyelviskolai adminisztrációs rendszer átvétele és befejezése Örökölt és félkész rendszerek egyesítése egy modern, közös adatbázisú vállalati alkalmazásban.
Részletek →Ajánlatkérés
Írd le az elképzeléseidet és a céljaidat, mi pedig rövid időn belül jelentkezünk, hogy megnézzük, hogyan tudunk segíteni.
