Fejlesztés átvétel

Egy szoftvert nem mindig ugyanaz a csapat fejleszti, aki elindította.

Tipikus helyzetek, amikor érdemes felkeresni minket:

• Az előző fejlesztő eltűnt. A kapcsolat megszakadt, a projekt félbemaradt, és a hiányzó funkciók lezárására hosszú távú partnerre van szükség.
• Beszállítóváltás előtt állsz. Tudni szeretnéd, milyen állapotban van a rendszer most, és van-e olyan eset, ahol az újraírás gazdaságosabb a folytatásnál.
• Mobilalkalmazás támogatása váltás előtt. iOS és Android natív app, vagy Flutter-alapú rendszer, ahol SLA-val álló partnert keresel a hibajavítás és a továbbfejlesztés mögé.
• Befejezetlen rendszer lezárása. A backend kész, néhány frontend funkció vagy automatizálás félbemaradt, és egy fix scope-ú befejezést keresel garanciával.
• Belső csapatra történő átállás. A meglévő külső fejlesztés átkerül a saját csapatodhoz, és a kódbázis végigjárása és a tudásátadás strukturált formára kerül.
• AI-val elindított projekt, ami elakadt. Egy rendszert AI-val vittél el egy darabig, de tudáshiány miatt a saját csapatod már nem tudja tovább vinni. A kód fut, de a következő lépés kockázatos, és mérnöki kézbe kell adni a stabilizálást és a továbbfejlesztést.

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." Forrás: 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ást reális számsorral kalkulálható meg, é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.

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?

• A kódbázis értékeléséről szóló jelentés architektúrából, kódminőségből, biztonságból, függőségekből és üzemeltetésből, vezetői összefoglalóval.
• Átvételi terv és deployment új környezetre, monitoring és naplózás, a régi és az új környezet párhuzamos futtatása az átállás idejére, domain átirányítás támogatással.
• Priorizált hibajavítási hullám az első 1-2 hónapban, ticketing rendszerrel és sprint szintű demókkal.
• Opcionális stabilizációs csomag: refaktorálás, automatizált tesztek, CI/CD pipeline, 1 hónapos hypercare, teljes funkcionális garancia.
• Opcionális frontend modernizáció (Vue 2 → Vue 3, vagy Blade + Livewire, vagy React portolás).
• Hosszú távú support és karbantartás SLA-val, dedikált support managerrel és havi riporttal.

Milyen stackeken?
Az erős stackjeink, amelyeken átveszünk és tovább viszünk rendszereket:

• Backend: PHP (Symfony, Laravel, Livewire), Python (FastAPI, Django), Java/Kotlin (Spring), Go.
• Frontend: Vue (2 és 3), React, Angular, valamint sablonalapú megoldások.
• Mobil: natív iOS (Swift), natív Android (Kotlin), Flutter.
• Adatbázis: PostgreSQL, MariaDB, MongoDB.

Ezeken is dolgozunk: Node.js (Express, Nuxt, Next), BaaS (Firebase, Supabase), React Native, Kotlin Multiplatform.

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.

• Nem vállalunk reverse engineering szolgáltatást olyan rendszerre, ahol a forráskód elveszett, vagy harmadik fél titoktartási megállapodás miatt nem adható át. Ezt a szakmai határhelyzetet a tanácsadási szakaszban kell rendezni.
• Nem garantáljuk a korábban elkészített funkciók hibamentes működését az alapcsomagban. A stabilizációs csomag erre a problémára való válasz; a két szint között az ügyfél a kockázattűrés és a büdzsé alapján választ.
• Nem javasoljuk feltétel nélkül a teljes átírást a saját preferált stackünkre. A stack megválasztása az ügyfél meglévő helyzetéhez igazodik, és a frontend modernizáció vagy a backend cseréje akkor jön szóba, ha a hosszú távú TCO erre mutat.
• Nem fejlesztünk azonnal az átvétel pillanatában. Az értékelési szakasz fix időkeretű, és az új fejlesztések ezt követik. A „kezdjünk el menet közben kódolni" megközelítés a tipikus átvételi projekt egyik leggyakoribb buktatója.

❓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 rendszeraudit 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 support szolgá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.