A fejlesztési döntés, ami sokba kerülhet
A legdrágább szoftver nem az, amelyik sokba kerül.
Hanem az, amelyik elkészül, aztán senki nem használja.
Az egyedi szoftverfejlesztés azt jelenti, hogy egy konkrét üzleti igényre, saját kódbázissal épül egy alkalmazás, ahelyett hogy egy kész, tömeggyártott terméket vásárolnál előfizetéses konstrukcióban. A különbség olyan, mint a méretre szabott öltöny és a konfekció között: az egyik a te alakodra készül, a másik az átlagra.
Magyarországon ez a döntés különösen éles. Az Európai Bizottság Digital Decade országjelentése szerint a magyar vállalkozások digitális intenzitása tartósan az uniós átlag alatt marad, és a KKV-k jelentős része még az alapszintű digitális eszközöket sem használja ki. Az Eurofound KKV-digitalizációs elemzései ugyanezt két okra vezetik vissza: tőkehiány és belső digitális készséghiány.
Vagyis a magyar döntéshozó nem csak azzal küzd, hogy melyik technológia a jó. Hanem azzal is, hogy honnan legyen rá pénz, és ki fogja használni a bevezetés után.
Egy szoftverprojekt nem akkor sikeres, amikor élesedik. Akkor sikeres, amikor a szervezet tényleg átáll rá, és mérhetően gyorsabban vagy olcsóbban működik.
Ez a cikk nem azt fogja bizonygatni, hogy az egyedi fejlesztés mindig jobb.
Sok esetben nem az.
Egy jól kiválasztott dobozos rendszer, egy no-code platform vagy két meglévő szoftver közé húzott API-integráció gyakran a töredékéért oldja meg ugyanazt a problémát.
Amit viszont kapsz: objektív döntési keret.
Végigmegyünk azon, hogyan határozd meg a scope-ot user story-kkal és MoSCoW-priorizálással, mi a különbség a prototípus, az MVP és a teljes termék között, hogyan bomlik le valójában egy fejlesztési ajánlat, mi a teljes tulajdonlási költség az első számla után, hogyan számold ki a megtérülést, és mit kell írásban rögzíteni a forráskódról.
A cél egyszerű.
Hogy amikor legközelebb ajánlatot kérsz, ne az árat nézd először, hanem azt, hogy egyáltalán ugyanarról a termékről beszéltek-e.
Egyedi fejlesztés vagy kész megoldás?
A legtöbb cégvezető binárisan gondolkodik: vagy veszünk valamit, vagy fejlesztetünk valamit. A valóságban négy fokozat létezik, és a középső kettőt szinte mindenki átugorja.
Dobozos, no-code és egyedi szoftver között
Érdemes spektrumként nézni, ahol a rugalmasság és a költség együtt mozog felfelé. Minél egyedibb a megoldás, annál nagyobb a szabadságod, és annál nagyobb a felelősséged is.
- Dobozos (SaaS) szoftver. Havi vagy éves előfizetés, azonnali indulás, alacsony belépési költség (jellemzően 3 000 és 30 000 forint között felhasználónként havonta). Cserébe a te folyamatodat kell a szoftverhez igazítani, nem fordítva. Ideális könyveléshez, e-mail marketinghez, alap CRM-hez, HR-adminisztrációhoz.
- No-code és low-code platform. Airtable, Make, n8n, Bubble és társaik. Néhány hét alatt működő belső eszközt kapsz, gyakran 500 000 forint alatti bevezetéssel. Kiváló belső folyamatokra, űrlapokra, jóváhagyási láncokra. A korlát a skálázás és a platformfüggőség: ha a szolgáltató árat emel vagy funkciót szüntet meg, nincs hova menekülni.
- Integrációs réteg. A meglévő rendszereidet kötöd össze egyedi kóddal vagy iPaaS eszközzel. Nem építesz új szoftvert, csak megszünteted a kézi adatátmásolást. Tipikus költség 800 000 és 4 000 000 forint között, a rendszerek számától és az API-k minőségétől függően.
- Teljesen egyedi fejlesztés. Saját kódbázis, saját adatmodell, saját szoftverarchitektúra. A legdrágább és a leglassabb út, viszont teljes kontroll, tulajdonjog, és nincs korlát a funkciókban. Egy komolyabb rendszernél 8 000 000 forinttól indul.
Mikor elég egy integráció?
Ha a fájdalom nem az, hogy hiányzik egy funkció, hanem az, hogy három rendszer nem beszél egymással, akkor nem új szoftver kell.
Egy híd kell.
Konkrét jelek, hogy integrációval megúszod:
- A munkatársaid CSV-fájlokat exportálnak és importálnak naponta vagy hetente, mert a webshop nem szinkronizál a készletrendszerrel.
- A meglévő CRM vagy ERP 90 százalékban lefedi a folyamatot, és a hiányzó 10 százalék adatátadás, nem üzleti logika.
- Mindkét rendszernek van dokumentált, stabil REST API-ja vagy webhook támogatása. Ha van hivatalos API-dokumentáció, a projekt kockázata drámaian csökken.
- A hiba, amit meg akarsz szüntetni, elgépelésből vagy elmaradt adatrögzítésből fakad, nem hiányzó funkcióból.
- Nem kell új felhasználói felület. A kollégák ugyanabban a rendszerben dolgoznának tovább, csak jobb adatokkal.
Egy 15 fős kereskedelmi cégnél láttunk példát arra, hogy két API végpont összekötése heti 12 kézi munkaórát szüntetett meg.
Ugyanezt egy egyedi ERP-vel is meg lehetett volna oldani, tizenötszörös áron.
Mikor indokolt az egyedi fejlesztés?
Az egyedi út akkor éri meg, ha a szoftver maga a versenyelőnyöd része, nem csak háttérinfrastruktúra. Néhány tipikus jel:
- Egyedi üzleti folyamat. A működésed lényege eltér az iparági standardtól, és éppen ez a különbség hozza a pénzt. Ha a folyamatot a dobozos szoftverhez igazítod, feladod a különbségedet.
- A szoftver maga a termék. Startupként az alkalmazás a bevételi forrás. Itt nincs alternatíva.
- Ügyfélélmény mint megkülönböztető. Ha az ügyfeleid közvetlenül használják a felületet, és a márkaélmény számít, a template-alapú megoldás visszafog.
- Skálázási fal. A no-code megoldásod működött 500 rekordig, de 50 000-nél összeomlik, vagy a felhasználónkénti licencdíj gyorsabban nő, mint a bevétel.
- Licencköltség-küszöb. Amikor az éves SaaS-díj eléri az egyedi fejlesztés árának 30-40 százalékát, a matek 3 éves horizonton átfordul.
- Adatszuverenitás. Szabályozott iparágban (egészségügy, pénzügy, közszféra) az adatkezelés helye és módja nem lehet kompromisszum tárgya.
Ez üzleti kérdés, nem technológiai divat.
Attól, hogy egy technológia népszerű, még nem lesz a te problémádra válasz.
Így zajlik egy fejlesztési projekt
A projektek többsége nem a kódolásnál bukik el.
Hanem ott, hogy három hónap múlva kiderül: az ügyfél és a fejlesztő két különböző terméket képzelt el ugyanarra a szóra.
Igényfelmérés és a scope meghatározása
A szoftveres igényfelmérés nem funkciólista-írás.
Célok, szerepkörök és prioritások rögzítése, ebben a sorrendben.
- Rögzítsd az üzleti célt számokban. Ne azt írd, hogy “hatékonyabb működés”, hanem azt, hogy “a rendelésfeldolgozás átfutási ideje 3 napról 4 órára csökkenjen”. A mérhető cél később az átvételi kritérium alapja lesz.
- Térképezd fel a felhasználói szerepköröket. Adminisztrátor, értékesítő, raktáros, végfelhasználó, könyvelő. Minden szerepkörnek más jogosultsága és más napi rutinja van, és ez határozza meg a képernyők számát, ami az egyik legerősebb költségtényező.
- Írj user story-kat. A formátum egyszerű: “Raktárosként szeretném vonalkóddal beolvasni a terméket, hogy ne kelljen cikkszámot gépelnem.” Egy közepes rendszer jellemzően 40-120 user story-ból áll. Ha ezt megírod ajánlatkérés előtt, összehasonlítható ajánlatokat kapsz.
- Priorizálj MoSCoW-módszerrel. Must (nélküle nem indul a rendszer), Should (fontos, de kerülhet a második körbe), Could (jó lenne), Won’t (most nem). Az egészséges arány: a Must maximum a story-k 50-60 százaléka.
- Rögzítsd a nem funkcionális követelményeket. Válaszidő, egyidejű felhasználók száma, rendelkezésre állás, adatmegőrzési idő, biztonsági szint, akadálymentesség. Ezek gyakran nagyobb hatással vannak az architektúrára és az árra, mint maguk a funkciók.
- Készíts funkcionális specifikációt. A funkcionális specifikáció és a hozzá tartozó adatmodell az a dokumentum, ami alapján a fejlesztő fix árat mer adni. Ha ez hiányzik, minden ajánlat becslés.
MVP, prototípus és teljes termék
A három fogalom keverése az egyik leggyakoribb oka annak, hogy irreális funkciólistával indul egy ajánlatkérés.
- Prototípus (kattintható makett). Nem működő szoftver, hanem interaktív UX/UI terv. Célja a koncepció bemutatása befektetőnek vagy belső döntéshozónak, és a prototípus és validáció gyors elvégzése valós felhasználókkal. Tipikusan 1-3 hét, 600 000 és 2 500 000 forint között.
- MVP (minimum életképes termék). Valóban működő, éles adatokkal használható szoftver, amely egyetlen fő értékígéretet teljesít. Nem félkész termék. Kevés funkció, de azok készen vannak. Célja a piaci validáció és az első fizető felhasználó.
- Teljes termék. Az MVP tanulságaira épülő, kiterjesztett funkcionalitás, jogosultságkezelés, riportok, integrációk, adatmigráció a régi rendszerből, adminfelület és skálázható felhőalapú infrastruktúra.
A sorrend nem esztétikai kérdés.
Ha a teljes terméket építed meg először, a hibás feltételezéseidet is beleépíted, teljes áron.
Példa: fix áras MVP-modell
Jó gyakorlatként érdemes megnézni, hogyan működik a fix scope-ú, fix árú MVP-modell. A CompletApp például 4 hetes MVP-fejlesztésben dolgozik: a scope és az ár a munka megkezdése előtt írásban rögzül, a fejlesztés heti demókkal halad, és az első mérföldkő után az ügyfél fizetési kötelezettség nélkül kiszállhat, ha nem elégedett.
Ez a felállás három dolgot old meg egyszerre.
Kiszámítható a költség, hetente látod a haladást, és a kockázat nem csak nálad van.
A heti demó egyébként önmagában is minőségi jelzés. Ha egy fejlesztő nem tud hetente működő verziót mutatni, akkor vagy túl nagy csomagokban dolgozik, vagy nincs mit mutatni.
Platformválasztás: mobil, web vagy mindkettő?
A platformválasztást a legtöbb cikk technológiai kérdésként tárgyalja.
Valójában felhasználói és üzleti kérdés.
- Nézd meg, hol vannak a felhasználóid. Ha irodai munkakörnyezetben, asztali gép előtt dolgoznak napi 8 órát, a webalkalmazás nyer. Ha terepen, mozgásban, egy kézzel használnák, akkor mobil.
- Kell natív eszközfunkció? Push értesítés, kamera, GPS-háttérkövetés, offline működés, Bluetooth, biometrikus azonosítás. Ha igen, mobilalkalmazás kell. Ha nem, a reszponzív webalkalmazás olcsóbb és gyorsabban frissíthető.
- Számolj a kódbázisok számával. Külön iOS és külön Android natív fejlesztés jellemzően 60-80 százalékkal drágább, mint egyetlen kódbázis. A cross-platform alkalmazásfejlesztés (például Flutterrel) egy kódból ad natív minőségű iOS és Android alkalmazást.
- Tudd, mikor indokolt mégis a natív. Nagy teljesítményigényű grafika, komplex AR, mélyszintű OS-integráció, vagy ha platformspecifikus SDK-tól függsz, amelynek nincs megbízható cross-platform kötése.
- Építsd be az akadálymentességet követelményként. A WCAG 2.2 konkrét, tesztelhető kritériumokat ad kontrasztra, billentyűzetes navigációra, célterület-méretre és fókuszjelölésre. Ez nem jótékonyság: közszférás vagy nagyvállalati beszerzésnél gyakran kizáró feltétel.
- Védekezz a scope creep ellen. A scope creep, vagyis a terjedelem észrevétlen dagadása, heti demókkal, írásos döntési naplóval, előre rögzített átadási kritériumokkal és formális változáskezelési eljárással kordában tartható. Minden új kérés kap becslést és ár- vagy határidőhatást, mielőtt bekerül.
Mennyibe kerül, és mikor térül meg?
Ha egy ajánlat egyetlen összeget tartalmaz bontás nélkül, az nem ajánlat.
Az egy tipp.
Mi rejtőzik egy ajánlat mögött?
A valós költség hat-nyolc tételre bomlik, és a legdrágább meglepetések általában a lista alján lakoznak. Az alábbi táblázat egy közepes komplexitású, 2026-os magyar piaci üzleti alkalmazás tipikus bontását mutatja.
| Költségtétel | Tipikus arány a teljes projektből | Jellemző összeg (MVP) | Gyakran kimarad az első ajánlatból? |
|---|---|---|---|
| UX/UI tervezés, user flow-k | 10-15% | 700 000 - 2 000 000 Ft | Részben (gyakran csak wireframe szintig) |
| Frontend fejlesztés (web vagy mobil) | 25-35% | 2 000 000 - 5 000 000 Ft | Nem |
| Backend, adatmodell, jogosultságok | 25-30% | 1 800 000 - 4 500 000 Ft | Nem |
| Harmadik féltől származó integrációk (fizetés, számlázás, ERP) | 8-15% | 500 000 - 2 500 000 Ft | Igen, integrációnként külön árazandó |
| Automatizált tesztelés és QA | 10-15% | 600 000 - 2 000 000 Ft | Igen, gyakran “belefér” ígéretként |
| Adatmigráció régi rendszerből | 5-15% | 400 000 - 3 000 000 Ft | Szinte mindig kimarad |
| Dokumentáció, átadás, betanítás | 3-7% | 250 000 - 900 000 Ft | Igen |
| Biztonsági audit, GDPR-átvizsgálás | 3-8% | 300 000 - 1 500 000 Ft | Igen |
Az adatmigráció a leggyakoribb csendes költségrobbanás.
Ha 12 éves Excel-táblákból és egy régi Access-adatbázisból kell tiszta adatot előállítani, az önmagában lehet többhetes munka.
Fejlesztési költség és teljes tulajdonlási költség
A fejlesztési díj az első számla.
A teljes tulajdonlási költség (TCO) az, amit három év alatt tényleg kifizetsz.
| Tétel | Mikor merül fel | Éves nagyságrend (közepes rendszer) | Mitől függ |
|---|---|---|---|
| Felhőalapú infrastruktúra, tárhely | Élesítéstől folyamatosan | 240 000 - 1 800 000 Ft | Felhasználószám, adatmennyiség, forgalom |
| Harmadik fél API-díjak (fizetés, SMS, térkép, AI) | Használatarányosan | 150 000 - 3 000 000 Ft | Tranzakciószám, AI-tokenfogyasztás |
| Monitoring, hibakövetés, logolás | Élesítéstől | 100 000 - 600 000 Ft | Rendszerkritikusság, SLA |
| Hibajavítás garancián túl | Garanciaidő után | A fejlesztési díj 10-20%-a | Kódminőség, tesztlefedettség |
| Verziófrissítés (OS, keretrendszer, könyvtárak) | Évente 1-2 alkalommal | 300 000 - 1 200 000 Ft | Platformok száma, függőségek |
| Továbbfejlesztés, új funkciók | Igény szerint | Változó, tervezz keretet | Üzleti növekedés |
Ökölszabály: az első év üzemeltetése és karbantartása a fejlesztési díj 15-25 százaléka. Mobilalkalmazásnál a felső sávval számolj, mert az iOS és Android éves nagyverziói kényszerfrissítést hoznak.
Hogyan számítsd ki a megtérülést?
A ROI és megtérülés számítása nem igényel pénzügyi végzettséget. Négy forrásból jöhet a haszon, és mindegyik forintosítható.
- Megspórolt manuális munkaóra. Heti óraszám × 52 × teljes órabér (bruttó bér és járulék együtt). Példa: heti 15 megszűnő óra, 6 000 forintos teljes óraköltséggel, évi 4 680 000 forint.
- Hibaköltség csökkenése. Hány rossz rendelés, téves számla vagy elveszett ügyfél volt tavaly, és mennyibe került egy eset? Havi 8 hibás rendelés, esetenként 25 000 forint javítási költséggel, évi 2 400 000 forint.
- Átfutási idő javulása. Ha az ajánlatadás 3 napról 4 órára csökken, több ajánlat megy ki, és nő a nyerési arány. Számold ki a jelenlegi nyerési arányt, becsülj konzervatívan 5-10 százalékos javulást.
- Konverziónövekedés vagy új bevétel. Webshopnál vagy ügyfélportálnál 0,5 százalékpontos konverziójavulás is milliókat érhet éves szinten. Új bevételi forrásnál (előfizetéses modul, partnerhozzáférés) az összeget inkább becsüld alá.
A képlet: (éves haszon − éves TCO) osztva a kezdeti fejlesztési költséggel.
Ha az eredmény 0,5 fölött van, a projekt két éven belül megtérül.
Ha 0,2 alatt, gondold újra a scope-ot vagy nézz kész megoldást.
Kockázatok, biztonság és tulajdonjog
A biztonsági hibák 100-szor drágábban javíthatók éles üzemben, mint tervezési fázisban. Ez az egyik legjobban dokumentált iparági összefüggés, mégis a legtöbb projekt élesítés előtti pipálásként kezeli a témát.
Adatvédelem már tervezéskor
A GDPR és adatvédelem nem jogi függelék a projekt végén.
A rendelet kifejezetten előírja a beépített és alapértelmezett adatvédelmet, ami tervezési döntéseket jelent: milyen adatot gyűjtesz egyáltalán, mennyi ideig tárolod, ki férhet hozzá, és hogyan törlöd.
A NIST Secure Software Development Framework ugyanezt technikai oldalról fogalmazza meg. A biztonsági követelményeket a fejlesztési életciklus elejére kell helyezni, nem a végére.
Gyakorlati minimum, amit már a specifikációban rögzíteni kell: szerepköralapú jogosultságkezelés, titkosítás átvitel közben és nyugalmi állapotban, auditnapló az érzékeny műveletekről, adatmegőrzési és törlési szabályzat, valamint az adatfeldolgozói szerződés a felhőszolgáltatókkal.
Ha az adatok EU-n kívülre kerülnek, arról külön döntés kell.
A CI/CD és DevSecOps gyakorlat ezt automatizálja: minden kódmódosítás lefuttatja az automatizált tesztelés csomagot, a függőségek sebezhetőségi vizsgálatát és a statikus kódelemzést, mielőtt bármi élesbe kerülne.
Ez nem extra szolgáltatás.
Ez alapelvárás 2026-ban.
Az AI-integráció buktatói
Az AI-integráció ma a legdivatosabb tétel az ajánlatokban, és a legkevésbé átgondolt.
Egy nyelvi modell beépítése technikailag két nap.
Megbízhatóvá tenni négy hét.
Amivel valóban számolni kell:
- Adatminőség. Ha a bemeneti adataid rendezetlenek, az AI gyorsabban ad rossz választ, mint eddig bárki. A modell nem javítja a káoszt, felnagyítja.
- Hallucináció kezelése. Kritikus folyamatban (árajánlat, jogi szöveg, orvosi adat) a modell kimenetét forráshoz kell kötni, és emberi jóváhagyási pontot kell beépíteni. Ez terméktervezési döntés, nem prompt kérdése.
- Költségkontroll. Az API-díjak token alapúak és lineárisan skálázódnak a használattal. Kérj becslést felhasználónkénti havi tokenfogyasztásra, és építs be limitet, gyorsítótárazást és automatikus átváltást olcsóbb modellre.
- Mit küldhetsz el. Személyes vagy üzleti titkot tartalmazó adatot csak megfelelő adatfeldolgozói feltételekkel és lehetőleg anonimizálva. Rögzítsd írásban, hogy a szolgáltató tanít-e a bemeneteiden.
- Mérhető haszon. Az AI-funkciónak is legyen KPI-ja. Ha nem csökkenti a kezelési időt vagy nem növeli a konverziót, díszlet.
Szerződés, forráskód és garanciák
A forráskód-tulajdonjog az a pont, ahol a legtöbb magyar KKV utólag döbben rá, hogy nem birtokolja azt, amit kifizetett. A magyar szerzői jog alapértelmezésben a szerzőnél hagyja a vagyoni jogokat, ha a szerződés nem rendelkezik másként.
Kérd be és rögzítsd írásban a következőket, még aláírás előtt:
- Vagyoni jogok teljes átruházása a teljes vételár kifizetésekor, kifejezett kikötéssel a forráskódra, a tervekre és a dokumentációra.
- Repository-hozzáférés a te szervezeti fiókodban, a projekt első napjától. Ne a fejlesztő privát tárhelyén éljen a kód.
- Licencelt komponensek listája (open source és fizetős egyaránt), licenctípussal és éves díjjal. Egy copyleft licenc rossz helyen komoly jogi kockázat.
- Hozzáférések listája: felhőfiókok, domain, tanúsítványok, app store fejlesztői fiókok, API-kulcsok. Mindegyik a te nevedre.
- Technikai dokumentáció: architektúradiagram, adatmodell, telepítési útmutató, környezeti változók leírása.
- Garanciaidő pontos definícióval: mi számít hibának, mi új igénynek, mennyi a válaszidő. Jellemző piaci gyakorlat 3-6 hónap.
- Továbbfejlesztési feltételek: óradíj, rendelkezésre állás, felmondási idő. És egy exit-forgatókönyv arra az esetre, ha másik fejlesztőre váltasz.
Ha egy fejlesztő nem hajlandó írásban vállalni a kódtulajdonjog átruházását, az önmagában elég ok a továbblépésre.
Mielőtt ajánlatot kérnél
A döntési szabály egy mondatban: ha a folyamat egyedi és versenyelőnyt ad, kezdj egyeztetést egyedi fejlesztőkkel; ha a folyamat általános, először nézz körül a kész és no-code megoldások között.
Amit ma megtehetsz, mielőtt bárkitől ajánlatot kérsz: írd össze a fő felhasználói szerepköröket, hozzájuk 15-30 user story-t, és priorizáld őket MoSCoW szerint.
Egy A4-es oldal is elég.
Ez a dokumentum azonnal összehasonlíthatóvá teszi az ajánlatokat, és megvéd a scope creeptől.
Mellé írd le egy mondatban a mérhető üzleti célt és a jelenlegi kiindulási számot. Enélkül nincs mihez képest sikeres a projekt.
És egy utolsó szűrő: a jó ajánlat átlátható scope-ot, funkciónkénti bontást, fix árat, üzemeltetési költségbecslést és írásos tulajdonjogi garanciát tartalmaz. Ha ezek közül bármelyik hiányzik, kérd be, mielőtt aláírsz.
