Hogyan válasszunk szoftverfejlesztő céget?
A Mesterséges Intelligencia Központ Kft. budapesti szoftverfejlesztő cég szerint a jó választás három kérdésen múlik: érti-e a fejlesztő a célt, ellenőrizhető-e az ajánlata, és kié lesz a kód és a rendszer az átadás után.
Lényeg: Írja le előbb a célt és a kötelező igényeket, és csak utána kérjen ajánlatot. Működő munkát, átlátható folyamatot és a kódhoz való hozzáférést érdemes kérni; az ajánlatokat ugyanarra a tételes specifikációra, lehetőleg mért méret alapján kell összevetni. A szerződésben a forráskódot és a felhasználási jogokat, a titoktartást, a hibajavítást, az üzemeltetést és a kilépés módját is rögzíteni kell.
Előbb a cél: mit kell tudnia a szoftvernek?
A legtöbb rossz választás nem a fejlesztőnél, hanem egy homályos megbízásnál kezdődik. Ha nincs leírva, mit kell tudnia a szoftvernek, minden ajánlat mást fog jelenteni, és nem lesz mihez mérni sem az árat, sem a kész munkát. Nem kell kész specifikáció, mert egy jó fejlesztő segít megírni, de néhány dolgot érdemes előre végiggondolni:
- Cél: milyen problémát old meg a szoftver, és miből látszik majd, hogy sikeres.
- Felhasználók: kik használják, belső munkatársak, ügyfelek vagy partnerek.
- Kötelező igények: ami nélkül nem indulhat el, külön a „jó lenne, ha” tételektől.
- Meglévő rendszerek: mihez kell kapcsolódnia (ERP, CRM, webshop, számlázó, bank).
- Adatok: milyen adatokat kezel, köztük személyes adatot is.
- Keretek: van-e kötött határidő, belső szabály, hosztolási vagy biztonsági elvárás.
Érdemes azt is eldönteni, hogy egyáltalán egyedi fejlesztés kell-e, vagy egy kész termék, esetleg kész termék és egyedi bővítés együtt is elég. Ebben az Egyedi szoftver vagy kész megoldás? cikk segít.
Szűkített lista: kiket érdemes megkeresni?
Nem kell sok céget megkeresni; néhány, gondosan kiválasztott jelölt jobb, mint sok felületes ajánlat. A szűkítés szempontjai:
- Hasonló munka: épített-e már hasonló méretű és jellegű rendszert, például üzleti szoftvert, webshopot, mobilalkalmazást vagy AI-integrációt.
- Technológiai illeszkedés: dolgozik-e azokkal a technológiákkal, amelyekhez a meglévő rendszereknek kapcsolódnia kell.
- Méretarány: a cég kapacitása illik-e a projekthez; egy nagy rendszerhez több szakterület kell, egy kis feladathoz kevesebb.
- Nyelv és elérhetőség: tud-e az Önök nyelvén, az Önök idősávjában egyeztetni.
Munkák és referenciák ellenőrzése
A legerősebb bizonyíték a működő szoftver. Kérje meg a jelölteket, hogy mutassanak olyan rendszert, amelyet ki is lehet próbálni, és mondják el pontosan, mi volt a saját részük benne. Sok ügyfélmunkát titoktartás véd, ezért nem mindig lehet nevet mondani. Ilyenkor egy névtelenített leírás, egy bemutató vagy a cég saját termékei is sokat elárulnak.
Ha referenciát ad egy korábbi megrendelő, érdemes konkrétan kérdezni: tartották-e a megbeszélt terjedelmet, hogyan kezelték a változásokat és a hibákat, megkapták-e a forráskódot, és dolgoznak-e még együtt. Egy általános „elégedettek voltunk” keveset mond; az, hogy a megrendelő az átadás után is velük üzemelteti a rendszert, sokat.
Szakmai beszélgetés
Egy-egy jelölttel érdemes egy szakmai beszélgetést tartani, lehetőleg az Önök oldaláról is egy technikai szakember jelenlétében. Nem a válaszok magabiztossága számít, hanem az, hogy a fejlesztő kérdez-e, és megnevezi-e a kockázatokat. Jó kérdések:
- Hogyan fognának hozzá, és mi lenne az első szakasz?
- Hogyan kötnék be a meglévő rendszereinket, és mit kell tudniuk róluk?
- Hogyan tesztelnek, és ki dönt arról, hogy egy rész kész?
- Ki dolgozik majd a projekten, és ki lesz a kapcsolattartónk?
- Hol fut majd a rendszer, és ki felel a biztonsági frissítésekért?
- Ha mesterséges intelligencia is lesz benne: milyen adat hová kerül, és mi történik, ha az AI téved?
Figyelmeztető jel, ha egy jelölt kérdés nélkül, az első beszélgetés után már pontos árat és határidőt mond.
Folyamat és kommunikáció
A szoftverfejlesztésben a meglepetések ritkán a kódban, sokkal inkább a kommunikációban születnek. Ezért érdemes megkérdezni, hogyan látja Ön menet közben a haladást. A jó gyakorlat ismérvei:
- Szakaszos fejlesztés: a munka szakaszokra bomlik, és minden szakasz végén működő szoftvert mutatnak be, nem csak beszámolót.
- Hozzáférés a kódhoz: a megrendelő az első naptól látja a kódtárat (repository), nem csak az átadáskor kapja meg.
- Követhető feladatlista: a feladatok, hibák és változások egy közös nyilvántartásban látszanak.
- Állandó kapcsolattartó: van egy ember, aki ismeri a projektet és dönteni tud.
- Változáskezelés: az új vagy módosult igényt leírják, megmérik vagy megbecsülik, és csak jóváhagyás után kerül a munkába.
Az ajánlatok összehasonlítása
Két ajánlat csak akkor vethető össze, ha ugyanarra a terjedelemre szól. Ezért minden jelölt ugyanazt a tételes leírást kapja, és kérje el tőlük, milyen funkciókra és mekkora méretre adták az árat. Ha a fejlesztő a szoftver funkcionális méretét szabványos módszerrel méri, például COSMIC funkciópontban, a méret ugyanabból a specifikációból ellenőrizhető; a módszert a Mi a COSMIC funkciópont? cikk mutatja be.
Ha két ajánlat között nagy a különbség, ezeket érdemes megkérdezni:
| Kérdés | Mit derít ki |
|---|---|
| Mekkora méretre és mely funkciókra szól az ár? | ugyanazt a terjedelmet árazták-e |
| Mi szerepel külön tételként? | integráció, adatátköltöztetés, grafika, üzemeltetés benne van-e |
| Milyen nem funkcionális követelményekkel számoltak? | teljesítmény, biztonság, akadálymentesség |
| Hogyan kezelik a változásokat? | mi történik, ha menet közben új igény jön |
| Mi a hibajavítás rendje az átadás után? | mi jár a díjért, és mi számít külön munkának |
| Kié lesz a forráskód, és milyen jogokat kapunk? | tovább lehet-e vinni mással a rendszert |
| Fix áras vagy ráfordításalapú az elszámolás? | ki viseli a terjedelem kockázatát |
A fix ár akkor működik jól, ha a terjedelem tételesen rögzített; a ráfordításalapú elszámolás rugalmasabb, de a terjedelem kockázata a megrendelőnél marad. Mindkét esetben az számít, hogy a terjedelem mérhető és követhető legyen. Hogyan árazunk mi, azt az Árazás oldal írja le.
A szerződés lényeges pontjai
A szerződés az, ami egy vita vagy egy váratlan helyzet esetén számít. Az alábbiak tájékoztatás, nem jogi tanács: a szerződést érdemes jogásszal is átnézetni.
Forráskód és felhasználási jogok
A magyar szerzői jogi törvény (1999. évi LXXVI. törvény, Szjt.) a számítógépi programalkotást forráskódban és tárgykódban is szerzői műként védi (1. § (2) bekezdés c) pont), és kimondja, hogy a szoftverre vonatkozó vagyoni jogok átruházhatók (58. § (3) bekezdés). A megrendelő tehát vagy a vagyoni jogokat szerzi meg, vagy felhasználási engedélyt (licencet) kap; a kettő nem ugyanaz.
Néhány szabály, amely miatt a pontos megfogalmazás fontos: a felhasználási szerződés csak kifejezett kikötés esetén ad kizárólagos jogot (43. § (1) bekezdés); ha a szerződés nem jelöli meg a felhasználás módjait és mértékét, az engedély a szerződés céljához elengedhetetlenül szükséges mértékre korlátozódik (43. § (5) bekezdés); ha a tartalom nem egyértelmű, a szerzőnek kedvezőbb értelmezést kell elfogadni (42. § (3) bekezdés); a felhasználó pedig csak a szerző kifejezett engedélyével adhat tovább engedélyt harmadik félnek (46. § (1) bekezdés). Érdemes ezért rögzíteni:
- a teljes forráskód és a dokumentáció átadását, szakaszonként is;
- hogy a megrendelő a vagyoni jogokat szerzi meg, vagy milyen terjedelmű engedélyt kap (kizárólagos-e, módosítható-e, továbbadható-e);
- hogy a fejlesztő rendelkezik a munkatársai és alvállalkozói által írt kód jogaival;
- a felhasznált nyílt forráskódú és harmadik féltől származó összetevők listáját és licencét.
Titoktartás (NDA)
Ha az ötlet vagy az üzleti adat bizalmas, a részletek előtt titoktartási szerződést (NDA) érdemes kötni. Rögzítse benne, mi számít bizalmas információnak, ki ismerheti meg, meddig tart a titoktartás, és mi történik az anyagokkal a munka végén.
Hibajavítás és jótállás
A szerződés mondja ki, mi számít hibának (eltérés a rögzített követelménytől), hogyan zajlik az átvételi teszt, milyen súlyossági szintek vannak, és melyik szintre milyen gyorsan reagál a fejlesztő. Rögzítse azt is, mennyi ideig javítja díjmentesen az átadáskor rejtve maradt hibákat, és mi számít már továbbfejlesztésnek.
Üzemeltetés és SLA
Ha a fejlesztő az átadás után is üzemelteti a rendszert, szolgáltatási szintű megállapodás (service level agreement, SLA) rögzíti a feltételeket: a vállalt rendelkezésre állást, a hibabejelentés módját, a reakció- és javítási időket súlyosság szerint, a karbantartási időablakokat, a mentéseket és a jelentéseket. Ami nincs leírva, az vitás helyzetben nem kérhető számon.
Kilépési terv
A kilépési terv arra a kérdésre felel, mi történik, ha a fejlesztővel nem folytatják, akár elégedetlenség, akár a fejlesztő megszűnése miatt. Elemei:
- naprakész dokumentáció a telepítésről, az architektúráról és az üzemeltetésről;
- a kódtár, a tárhely, a domain és a felhőfiókok a megrendelő nevén vagy legalább a megrendelő hozzáférésével;
- a jelszavak és hozzáférési kulcsok átadásának rendje;
- az adatok exportálhatósága szabványos formátumban;
- átadási együttműködés egy új fejlesztő felé.
Adatvédelem: adatfeldolgozói szerződés
Ha a fejlesztő a munka során személyes adathoz fér hozzá (például üzemelteti a rendszert, vagy éles adatokkal tesztel), a GDPR szerint jellemzően adatfeldolgozónak minősül, és írásos adatfeldolgozói szerződés kell vele (GDPR 28. cikk). Ennek rögzítenie kell többek között, hogy csak a megrendelő dokumentált utasításai szerint kezeli az adatot, gondoskodik a titoktartásról és a biztonságról, csak engedéllyel vesz igénybe további adatfeldolgozót, a szolgáltatás végén törli vagy visszaadja az adatokat, és lehetővé teszi az ellenőrzést.
Biztonsági gyakorlat
A biztonságot nem lehet utólag a szoftverre tenni, ezért érdemes megkérdezni, hogyan dolgozik vele a fejlesztő. Jó kiindulópont az OWASP Top 10, a webalkalmazások legkritikusabb biztonsági kockázatainak széles körben ismert listája; az aktuális kiadás az OWASP Top 10:2025 (ellenőrizve: 2026. október 17.). Az első három helyen a hibás hozzáférés-szabályozás, a hibás biztonsági beállítás és a szoftverellátási lánc hibái állnak. Kérdezze meg:
- Hogyan kezelik a jogosultságokat, és hogyan tesztelik, hogy egy felhasználó csak a saját adatait lássa?
- Hogyan frissítik a felhasznált külső könyvtárakat, és honnan tudják, ha egy közülük sérülékeny?
- Hol tárolják a jelszavakat és kulcsokat, és ki fér hozzájuk?
- Van-e kódellenőrzés (code review) és automatikus teszt?
- Hogyan készül mentés, és próbálták-e már visszaállítani?
Szabadúszó vagy fejlesztő cég?
Mindkettő jó választás lehet; a kérdés az, mekkora és mennyire hosszú életű a feladat.
| Szempont | Szabadúszó | Fejlesztő cég |
|---|---|---|
| Kommunikáció | közvetlen, egy emberrel | kapcsolattartón keresztül, több szakemberrel |
| Szakterületek | egy ember tudása | több szakterület: felület, háttérrendszer, mobil, üzemeltetés, tesztelés |
| Helyettesíthetőség | betegség vagy távozás esetén megáll a munka | a csapat át tudja venni egymás munkáját |
| Kapacitás | kisebb, jól körülhatárolt feladatokra | nagyobb rendszerekre, párhuzamos munkára |
| Szerződés | közvetlenül a szakemberrel | a céggel, amely a csapat munkájáért felel |
| Hosszú távú üzemeltetés | a szabadúszó elérhetőségén múlik | szervezetten vállalható |
Szabadúszó jól illik egy jól körülhatárolt feladathoz, különösen akkor, ha a megrendelőnek saját technikai vezetője van, aki irányítja és átveszi a munkát. Ha a rendszer a cég napi működésének része, több szakterületet igényel, és évekig üzemelni fog, a fejlesztő cég jellemzően kisebb kockázat. A kilépési terv és a forráskód átadása mindkét esetben ugyanúgy fontos.
Figyelmeztető jelek
- Pontos ár és határidő már az első beszélgetés után, kérdések nélkül.
- Nincs írásos specifikáció, vagy az ajánlat nem mondja meg, mire szól.
- A megrendelő nem láthatja a kódot, csak az átadáskor kapná meg.
- Homályos válasz arra, ki dolgozik majd a projekten.
- Nem egyértelmű, kié lesz a forráskód, és milyen jogokat kap a megrendelő.
- Elzárkózás az adatfeldolgozói szerződéstől vagy a titoktartási szerződéstől.
- Nincs bemutatható, működő munka.
Ellenőrzőlista
| Kérdés | Rendben, ha |
|---|---|
| Le van írva a cél és a kötelező igények? | van egy rövid, közösen értett leírás |
| Láttunk működő munkát? | kipróbáltunk legalább egy hasonló rendszert |
| Értik a feladatot? | kérdeztek, és megnevezték a kockázatokat |
| Látjuk majd a haladást? | szakaszos bemutatók, hozzáférés a kódtárhoz |
| Összevethető az ajánlat? | ugyanarra a tételes terjedelemre szól, a külön tételek látszanak |
| Rendezett a forráskód és a jogok kérdése? | a szerződés megnevezi az átadást és a jogok terjedelmét |
| Van titoktartási és adatfeldolgozói szerződés? | ahol kell, aláírták |
| Rögzített a hibajavítás és az üzemeltetés? | súlyossági szintek, reakcióidők, SLA |
| Van kilépési terv? | dokumentáció, hozzáférések, adatexport |
| Kérdeztük a biztonságról? | konkrét válasz a jogosultságokra, frissítésekre, mentésre |
Gyakori kérdések
Szabadúszó vagy fejlesztő cég?
Egy jól körülhatárolt, kisebb feladatra egy tapasztalt szabadúszó is jó választás lehet, különösen, ha a cégnek saját technikai vezetője van. Ha a rendszer a napi működés része, több szakterületet igényel és hosszan üzemel, a fejlesztő cég kisebb kockázat, mert a munka nem egyetlen emberen múlik.
Hogyan hasonlítsunk össze két árajánlatot?
Csak ugyanarra a tételes specifikációra adott ajánlatok vethetők össze. Kérdezze meg mindkét ajánlattevőt, mekkora méretre és mely funkciókra adta az árát, mi szerepel külön tételként, és hogyan kezeli a változásokat. Ha a méretet szabványos módszerrel, például COSMIC funkciópontban mérték, az ugyanabból a specifikációból ellenőrizhető.
Mit tartalmazzon a szerződés?
A terjedelmet (a tételes specifikációt), az árat és az ütemezést, a forráskód átadását és a felhasználási jogok terjedelmét, a titoktartást, az átvétel és a hibajavítás rendjét, az üzemeltetést és az SLA-t, a kilépési tervet, és ha személyes adat is érintett, az adatfeldolgozói szerződést. Ez tájékoztatás, nem jogi tanács.
Mi történik, ha a fejlesztő eltűnik?
Ha a forráskód, a dokumentáció és a hozzáférések a megrendelőnél vannak, egy másik fejlesztő át tudja venni a rendszert. Ezért érdemes a kódtárat az első naptól látni, a tárhelyet és a domaint a saját nevükön tartani, és a szerződésben kilépési tervet rögzíteni. Ha ezek hiányoznak, a rendszer továbbvitele nehéz és lassú lehet.
Kié lesz a forráskód?
Annak, akinek a szerződés szerint jár: a szerzői jogi törvény szerint a szoftverre vonatkozó vagyoni jogok átruházhatók, de ez nem automatikus. A szerződésben érdemes rögzíteni, hogy a megrendelő megkapja a teljes forráskódot, és pontosan milyen jogokat szerez rajta. A forráskódról és a felhasználási jogokról nálunk is a szerződés rendelkezik.
Hogyan segítünk?
Mi így dolgozunk: az első egyeztetés díjmentes, a specifikációt közösen írjuk meg, a szoftver méretét COSMIC funkciópontban mérjük, és ebből készül az ajánlat és az ütemterv. A fejlesztés szakaszokban halad, minden szakasz végén bemutatóval; kérésre titoktartási szerződést (NDA) kötünk, és az átadás után üzemeltetést és karbantartást is vállalunk. A forráskódról és a felhasználási jogokról a szerződés rendelkezik. A lépéseket a Hogyan dolgozunk, az árazás módszerét az Árazás oldal írja le.
Jelenleg is egy nagy ERP- és CRM-rendszert fejlesztünk; a saját, kipróbálható fejlesztéseinket a Munkáink oldalon mutatjuk be, a cégről a Rólunk oldalon, a gyakori kérdésekre a Gyakori kérdések oldalon olvashat. Ha fejlesztőt keres, írjon nekünk a Kapcsolat oldalon megadott elérhetőségeken.