Miért Csúszik El Ennyi Weboldal-Projekt?
A legtöbb vállalkozó három dolog alapján dönt: mennyire szép a portfólió, mennyibe kerül, és mennyire szimpatikus az értékesítő az első hívásban.
Mindhárom szempont legitim.
És mindhárom teljesen alkalmatlan arra, hogy megvédjen a valódi kockázatoktól.
Mert a projektek nem azon csúsznak el, hogy a fejlesztő nem tud lekerekített sarkot csinálni.
Hanem azon, hogy nyolc hónappal az élesítés után kiderül: a forráskód tulajdonjoga tisztázatlan, a domaint a fejlesztő nevére regisztrálták, senki nem definiálta előre a mérhető üzleti célokat, és a szerződés egy A4-es lap, amin a “karbantartás” szó szerepel mindenféle tartalom nélkül.
Ez a cikk egy másik utat kínál.
Kapsz egy 100 pontos, súlyozott értékelési keretrendszert, amivel a benyomás helyett számokkal hasonlíthatod össze a jelölteket.
Nem azért, mert a megérzés értéktelen, hanem mert dokumentálható döntést sokkal könnyebb megvédeni a cégen belül.
A jó webfejlesztő partner nem kivitelező. Az ötlettől a mérhető, továbbfejleszthető termékig vállal felelősséget, és pontosan ezért mond nemet bizonyos funkciókra.
A továbbiakban végigmegyünk azon, hogy a projekttípusod (weboldal, webshop, SaaS vagy mobilapp) milyen eltérő szempontokat követel, hogyan ellenőrizd a szakértelmet a portfólió mögött, hogyan pontozz objektíven, és mit kell mindenképp leírni a szerződésbe. Ebben a sorrendben.
Projekttípusod Más Szempontokat Igényel
Egy bemutatkozó weboldal és egy több ezer felhasználót kiszolgáló webalkalmazás annyira mást igényel, mint egy családi ház és egy raktárcsarnok.
Ugyanaz a szakma, teljesen más mérnöki gondolkodás.
Az első kérdés tehát nem az, hogy “ki a legjobb webfejlesztő cég”, hanem hogy ki a legjobb ehhez a konkrét projekttípushoz. Nézzük végig a négy leggyakoribb esetet.
Weboldal és Webshop Szempontjai
Ezeknél a projekteknél a látvány a legkönnyebben megvásárolható rész.
A pénzt máshol veszíted el.
- Bemutatkozó vagy marketing weboldal: Itt három dolog dönt. A technikai SEO alapok (szemantikus HTML, strukturált adatok, tiszta URL-struktúra, indexelhetőség), a betöltési sebesség és a konverzió. Kérdezd meg, milyen Core Web Vitals értékeket garantálnak élesítés után, és kérj mérési bizonyítékot korábbi projektről.
- Technológiai illeszkedés: Egy 12 aloldalas céges site-hoz nem kell nehéz keretrendszer. Statikus generátor (például Astro) villámgyors és biztonságos, WordPress CMS pedig akkor indokolt, ha a marketingcsapat naponta szerkeszt tartalmat. Ha valaki mindenre ugyanazt ajánlja, az gyanús.
- Mobiloptimalizálás mint alap, nem extra: A magyar forgalom nagy része mobilról jön. A reszponzív webdesign ne opcionális tétel legyen az ajánlatban, hanem beépített minimum, mobilon mért sebességgel együtt.
- Webshop: fizetés és készlet: Kérdezd meg konkrétan, mely fizetési szolgáltatókkal (Barion, SimplePay, Stripe) integráltak már élesben, és hogyan kezelik a készletszinkront a számlázóprogrammal vagy az ERP-vel. Az API-integráció itt nem apróság, hanem a projekt legdrágább része.
- Akadálymentesség mint üzleti kockázat: Az Európai Akadálymentesítési Irányelv 2025 utáni előírásai miatt a webshopok jelentős részére kötelező megfelelés vonatkozik. Kérdezd meg, dolgoztak-e már WCAG 2.2 AA szint szerint, és mivel tudják ezt igazolni (audit riport, tesztelési jegyzőkönyv).
- Konverziós logika: Jó partner nem csak megépíti a kosárfolyamatot, hanem javaslatot tesz a lépések számának csökkentésére és a mérésre (események, e-commerce tracking, esemény alapú riportok).
Webalkalmazás, SaaS és Mobilapp
Itt a jövőbeli fejlesztés költségét az első három hónap architekturális döntései határozzák meg.
Egy rossz adatmodell később hatszor annyiba kerül javítani, mint elsőre jól megtervezni.
- Backend architektúra: Kérdezz rá, milyen adatbázisra építenek, hogyan kezelik a hitelesítést és a jogosultságokat, és hol húzzák meg a szolgáltatások határait. A válasz legyen konkrét, ne “modern és skálázható”.
- Skálázhatóság reálisan: Nem az a kérdés, hogy elvisz-e egymillió felhasználót. Az, hogy mi történik 500 egyidejű felhasználónál, és milyen ponton kell újraírni bármit. A jó válasz megnevezi a szűk keresztmetszetet.
- API-tervezés: Dokumentált, verziózott API nélkül a mobilapp és a webes felület összeépítése rémálom. Kérdezd meg, kapsz-e OpenAPI dokumentációt átadásnál.
- Egyedi fejlesztés vagy meglévő rendszer: React alapú admin felület, kész auth-szolgáltatás, meglévő fizetési modul. A jó partner tudja, mit nem érdemes nulláról írni.
- CRM- és ERP-integráció: Ha a rendszernek beszélnie kell a vállalati folyamatokkal, kérdezz rá a hibakezelésre és az újrapróbálkozási logikára. Az integrációk 80%-a nem az induláskor, hanem az első kimaradásnál hasal el.
- Mobilapp: natív vagy cross-platform: Kérdezd meg, Flutter vagy React Native alapú cross-platform megoldást ajánlanak-e, vagy natív Swift/Kotlin fejlesztést, és miért. Cross-platform esetén jellemzően 30-40%-kal rövidebb a fejlesztési idő és egyetlen kódbázist kell karbantartani, natívnál viszont a hardverközeli funkciók és az animációk finomabbak.
- Biztonság: Kérdezd meg, ismerik-e és tesztelik-e az OWASP Top 10 szerinti sérülékenységeket. Webalkalmazás-biztonság terén a “majd az élesítés előtt megnézzük” válasz kizáró ok.
Nézz a Portfólión Túl
A portfólió a webfejlesztési piac legkönnyebben megszépíthető eleme. Egy screenshot nem mondja meg, hogy ki fejlesztette, mikor, mennyiért, és hogy a site három hónappal később is működött-e.
Nézz a Portfólió Mögé
Első kérdés, ami sok beszélgetést azonnal tisztáz: ez a referencia biztosan a ti munkátok? Kérj megnevezhető kontaktot a megrendelő oldaláról, vagy legalább írásos hozzájárulást a referencia használatához.
Utána jöhet a finomabb bontás.
Mely részt fejlesztették házon belül, és mely részt adták alvállalkozónak?
Egy háromfős csapat gyakran kiszervezi a designt vagy a backendet, ami teljesen rendben van, ha átlátható.
Akkor probléma, ha nem beszélnek róla.
Ellenőrizd magad is.
Nyisd meg a referenciát mobilon, futtass rajta egy sebességmérést, és nézd meg a Core Web Vitals értékeket.
Ha a bemutatott “díjnyertes” oldal négy másodperc alatt sem tölt be mobilon, tudod, hol tartanak a technikai minőségben.
Kérdezz rá a tényleges számokra is.
Mennyivel javult a konverzió az újraindítás után? Mekkora volt az organikus forgalom változása három és hat hónappal később?
Ha erre nincs adat, az azt jelenti, hogy senki nem mérte, tehát az üzleti célok és KPI-ok nem voltak részei a projektnek.
Végül nézd meg az akadálymentességi állapotot.
Egy gyors billentyűzetes végigkattintás és egy automatizált WCAG-ellenőrzés harminc másodperc alatt megmutatja, hogy a csapat gondolt-e erre egyáltalán.
Kérdések az Első Egyeztetésen
Az első hívás nem arról szól, hogy ők mutassák meg, mennyire jók.
Arról szól, hogy te ellenőrizd, hogyan gondolkodnak.
Tedd fel a legfontosabb kérdést: hogyan mérnék ennek a projektnek a sikerét?
A gyenge válasz: “elkészül határidőre, és tetszeni fog”.
Az erős válasz konkrét számokat nevez meg, például lead-mennyiség és leadminőség, aktivációs arány, kosárelhagyás csökkenése, organikus belépések aloldalankénti alakulása.
Kérdezd meg, milyen mutatókat rögzítenének írásban a projekt indulása előtt.
Ha egy csapat vállalja, hogy célszámokat tesz a weboldal specifikáció mellé, az komoly bizalmi jel.
A második, még többet elmondó kérdés: mikor mondanátok nemet egy funkcióra?
Aki mindenre igent mond, nem partner. Számlázó.
A jó fejlesztő cég adott ponton azt javasolja, hogy a tizennégy funkciós elképzelés helyett indulj egy négy funkciós MVP-vel, mérj két hónapot, és a valós használati adatok alapján döntsd el, mi épüljön tovább.
Ez rövid távon kevesebb bevétel nekik.
Hosszú távon ez az, ami megvédi a büdzsédet.
Kérdezz rá a folyamatra is: hogyan zajlik a UX/UI tervezés, kapsz-e kattintható prototípust a fejlesztés előtt, ki írja a webfejlesztési brief-et, és milyen minőségbiztosítás és tesztelés előzi meg az élesítést.
Ha erre csak általánosságokat kapsz, ott nincs kialakult folyamat.
A 100 Pontos Kiválasztási Checklist
A benyomás alapú döntés problémája nem az, hogy pontatlan.
Az, hogy nem összehasonlítható.
Három ajánlat után már nem emlékszel, melyik csapat mondott mit a garanciáról.
Ezért érdemes pontozni.
Súlyozott kategóriákkal, azonos kérdésekkel, írásban.
Súlyozott Értékelési Kategóriák
A 100 pont elosztása azt tükrözi, hogy a projektek valójában min buknak el. A releváns tapasztalat és a technikai megközelítés együtt 45 pontot ér, mert ez a két tényező határozza meg a végeredmény minőségének nagy részét.
| Kategória | Max. pont | Mit vizsgálj konkrétan | Kizáró jel |
|---|---|---|---|
| Releváns szakmai tapasztalat | 25 | Legalább 2 hasonló projekttípus és iparág, ellenőrizhető kontaktokkal; házon belüli vs. alvállalkozói arány | Nincs megnevezhető referencia |
| Technikai megközelítés és stack-illeszkedés | 20 | Indokolt technológiaválasztás, Core Web Vitals adatok, OWASP-szemlélet, tesztelési gyakorlat | Minden projektre ugyanaz a stack |
| Üzleti szemlélet és KPI-fókusz | 15 | Konkrét mérőszámokat javasol, priorizál, MVP-t mer ajánlani | Nincs mérési javaslat |
| Ár-érték és szerződési feltételek | 15 | Tételes ajánlat, mérföldkövek, tulajdonjogi és kilépési pontok írásban | Egy összeg, bontás nélkül |
| Kommunikáció és projektmenedzsment | 15 | Nevesített kontakt, riportolási ritmus, projektkövető eszköz, válaszidő | Egyhetes válaszidő már az ajánlati fázisban |
| Élesítés utáni támogatás | 10 | Garanciális idő, hibajavítási SLA, mentés és monitorozás, továbbfejlesztési kapacitás | Csak “karbantartás” szó, tartalom nélkül |
A pontozás akkor működik, ha minden jelölt ugyanazt a briefet kapja.
Különböző briefre adott ajánlatok összehasonlítása olyan, mint két különböző mértékegységben mért árat összevetni.
Ajánlatkérési Brief Sablon
Egy jó brief két oldal.
Nem több.
De ezt a hat blokkot tartalmazza:
- Üzleti cél és siker definíció: Mit szeretnél elérni számokban 6 hónap alatt (például havi 40 minősített ajánlatkérés, 25%-kal alacsonyabb kosárelhagyás).
- Célközönség és fő használati eset: Ki használja, milyen eszközön, milyen döntés előtt áll a látogató.
- Funkciólista prioritással: Kötelező, kívánatos és későbbi kategóriákba sorolva. Ez az egy lépés önmagában 20-30%-kal csökkenti az ajánlati szórást.
- Meglévő rendszerek: CRM, ERP, számlázó, hírlevélrendszer, jelenlegi tárhely és domain adatok.
- Határidő és költségkeret: Igen, írd bele a keretet. Aki azt mondja, hogy ezért kapsz drágább ajánlatot, félreérti: keret nélkül nem tud reális scope-ot tervezni senki.
- Elvárt átadási csomag: Forráskód, Git-repozitórium, dokumentáció, designfájlok, admin hozzáférések, tesztelési jegyzőkönyv.
Példa pontszámtábla három jelöltre, hogy lásd, hogyan válik szét a mezőny:
| Kategória (max) | “A” jelölt | ”B” jelölt | ”C” jelölt |
|---|---|---|---|
| Tapasztalat (25) | 22 | 18 | 12 |
| Technikai megközelítés (20) | 18 | 13 | 15 |
| Üzleti szemlélet (15) | 13 | 7 | 5 |
| Ár-érték és szerződés (15) | 11 | 14 | 9 |
| Kommunikáció (15) | 12 | 11 | 13 |
| Támogatás (10) | 9 | 5 | 4 |
| Összesen (100) | 85 | 68 | 58 |
Figyeld meg a “B” jelöltet: a legjobb árajánlat, mégis 17 ponttal lemarad.
Pontosan ezt a csapdát kerüli el a súlyozás.
Ár, Szerződés és Tulajdonjog
Itt dől el a projekt sorsa.
Nem a designban, nem a technológiaválasztásban.
A szerződés azon négy-öt bekezdésében, amit a legtöbb megrendelő átfut.
Fix Ár vagy Óradíj?
Nincs jobb és rosszabb modell.
Csak illeszkedés van.
- Fix ár akkor jó, ha a scope pontosan definiálható: marketing weboldal, landing oldal, jól körülhatárolt webshop, vagy egy előre lezárt funkciólistájú MVP. Előnye a kiszámíthatóság, hátránya, hogy minden változás külön ajánlatot igényel.
- Óradíj vagy sprint-alapú elszámolás akkor jó, ha a projekt iteratív és a scope várhatóan mozogni fog: SaaS termék, belső vállalati rendszer, folyamatos karbantartás és továbbfejlesztés. Előnye a rugalmasság, hátránya, hogy szigorú keretezés nélkül elszaladhat a költség.
- Sprint-alapú modell keretezése: Kérj fix sprinthosszt (jellemzően 2 hét), sprintenkénti költségplafont, és minden sprint végén demót plusz döntési pontot. Így a rugalmasság nem jelent kontrollvesztést.
- Hibrid megoldás: Az első fázis (felmérés, UX/UI tervezés, specifikáció) fix áron, a fejlesztés sprintekben. Ez a leggyakoribb működő kompromisszum közepes projekteknél.
- Amit mindkét modellnél kérj: Mérföldkövekhez kötött fizetés. Egyösszegű előre fizetés a teljes díjra veszélyes, a teljes utólagos fizetést pedig kevés komoly csapat vállalja. A 30-40-30 vagy mérföldkövenkénti bontás egészséges.
Kié a Kód és a Fiókok?
A leggyakoribb utólagos felismerés magyar kisvállalati projektekben: a megrendelő fizetett mindent, de semmit sem birtokol.
Ezt egy bekezdés megelőzi.
- Forráskód tulajdonjoga: Rögzítsd, hogy a teljes kifizetés pillanatában a forráskódra vonatkozó felhasználási és módosítási jogok korlátlanul, területi és időbeli megkötés nélkül a megrendelőhöz kerülnek.
- Git-repozitórium és dokumentáció: Ne zip-fájlt kérj. Kérd a teljes verziótörténetet a saját szervezeti fiókodba átadva, telepítési és üzemeltetési leírással együtt.
- Domain és tárhely: A domain a te cégnevedre legyen regisztrálva, a tárhely és a felhőszolgáltatói fiók (AWS, Google Cloud, Hetzner) a te nevedre nyitva, a fejlesztő pedig kapjon hozzáférést. Ne fordítva.
- Analitikai és marketing fiókok: Google Analytics, Search Console, Tag Manager, hirdetési fiókok. Ezek a te adataid, tulajdonosi hozzáféréssel.
- API-kulcsok és harmadik feles előfizetések: Fizetési szolgáltató, e-mail küldő, térkép, SMS. Legyen listád arról, mi kinek a nevén fut és mennyibe kerül havonta.
- Designfájlok és licencelt elemek: Kérd a szerkeszthető Figma-fájlokat, és kapj írásos listát a felhasznált licencelt sablonokról, ikonokról, fotókról és bővítményekről, a licenc típusával együtt.
Vendor Lock-in és Megfelelés
A vendor lock-in az a helyzet, amikor technikai vagy szerződési okból nem tudsz fejlesztőt váltani anélkül, hogy az egészet újraépítenéd.
Ez nem mindig szándékos rosszindulat, néha csak hanyagság.
A következmény ugyanaz.
- Négy kérdés, ami kiszűri: Exportálható-e minden adat standard formátumban? Dokumentált-e a kód és a telepítési folyamat? Széles körben ismert, szabványos technológiát használnak-e, vagy saját belső keretrendszert? Át tudná-e venni a projektet egy másik fejlesztő két hét alatt?
- Saját CMS-re épített oldal: Óvatosan. Ha a rendszer csak az ő szerverükön fut és nincs dokumentáció, minden jövőbeli módosítás náluk marad, áron, amit ők szabnak.
- Gyakorlati modell, ami működik: Mérföldkő-alapú elszámolás, kilépési garancia (bármely mérföldkő végén elválhatsz a addig elkészült és átadott munkával), és 100%-os kódátadás a végén. A CompletApp például pontosan ezt a hármas felállást alkalmazza, és ez jó benchmark, amihez a többi ajánlatot mérheted.
- Garancia és SLA konkrétan: Milyen hosszú a garanciális hibajavítás (3, 6 vagy 12 hónap)? Mi számít hibának és mi új igénynek? Mennyi a reakcióidő kritikus hiba esetén (például 4 munkaóra), és mennyi a normál hibáknál (2 munkanap)?
- Mentés és monitorozás: Milyen gyakran készül mentés, hol tárolják, mennyi ideig, és ki teszteli a visszaállítást? A mentés, amit soha nem állítottak vissza, nem mentés.
- GDPR és adatfeldolgozás: Írásos adatfeldolgozói szerződés kell, amiben szerepel a tárhely fizikai helye, az igénybe vett alvállalkozók listája, az adatmegőrzési idő és az incidenskezelési kötelezettség (értesítés 24-72 órán belül).
- Akadálymentességi megfelelés: Kérj konkrét vállalást WCAG 2.2 AA szintre, tesztelési módszerrel (automatizált ellenőrzés plusz kézi billentyűzetes és képernyőolvasós teszt), és rögzítsd, ki javítja a hibákat, ha később auditon fennakad valami.
Így Dönts Magabiztosan
A döntés két úton mehet, és a projekt jellege dönti el, melyiken.
Ha egyszerű, jól körülhatárolható marketing weboldalról vagy kisebb webshopról van szó, ne komplikáld túl.
Fix áras ajánlat, három jelölt, gyors pontozás, tulajdonjogi pontok ellenőrzése, döntés két héten belül.
A hosszú tender itt csak időt visz.
Ha komplex SaaS, belső vállalati rendszer vagy mobilapp a cél, más a képlet.
Sprint-alapú elszámolás, mélyebb technikai átvilágítás (architektúra, tesztelési gyakorlat, OWASP-szemlélet), és lehetőleg egy fizetett kisebb próbafeladat, mielőtt hosszú szerződést írsz alá.
Amit ma megtehetsz: vedd a jelenlegi három legjobb jelöltet, küldd ki nekik ugyanazt a kétoldalas briefet, és pontozd le őket a 100 pontos táblázat szerint, mielőtt bármelyiknek visszaigazolsz.
Egy óra munka.
Sokszor több millió forintos hibát előz meg.
És a legfontosabb szűrő, amit tarts szem előtt a végéig: a jó partner nem a legszebb portfóliót adja.
Hanem a saját munkájának mérhető eredményeit, a tulajdonjogot és a kilépés lehetőségét is átláthatóan garantálja.
Aki ezt írásban vállalja, azzal érdemes dolgozni.
