Csúszik a weboldalad elkészítése, mikor szólj, és mikor válts fejlesztőt

Scheo · 2026-11-11 · olvasási idő ~10 perc · Szerző: Schmidt Péter

Ha a weboldalad hetek óta „majdnem kész”, először azt érdemes tisztázni, mi hiányzik még, és kinek a feladata pótolni. A csúszás sokszor kétoldalú. A fejlesztő vár a szövegekre, a képekre vagy egy döntésre, te pedig a következő verzióra. Ez a cikk lépésről lépésre végigvisz azon, hogyan derítsd ki, hol akadt el a projekt, hogyan rögzítsd írásban a nyitott tételeket, és mikor jön el az a pont, amikor a fejlesztőváltás kisebb kockázat, mint a további várakozás.

A szövegben külön jelölöm, mi számít hivatalos információnak, mi saját tapasztalat, és mi szakmai feltételezés. A jogi részek általános tájékoztatást adnak, egy konkrét vitában ügyvéd tud felelősen állást foglalni.

Hogyan derül ki, kin múlik a weboldal csúszása?

Abból derül ki, ha minden nyitott tételhez odaírod, kinél van a következő lépés, és mióta áll nála. Ha a lista nagyobb része nálad van, a csúszást te is okozod. Ha a fejlesztőnél, akkor az ő kapacitása vagy hozzáállása a gond.

Saját tapasztalat. Megrekedt projekteknél gyakori, hogy a megrendelő oldalán hiányzik valami, amiről a megrendelő nem is tud, mert senki nem kérte tőle egyértelműen. Tipikusan ilyen a végleges tevékenységlista, a bemutatkozó szöveg, a jogi szövegek (adatkezelési tájékoztató, ÁSZF), a logó vektoros változata, a fotók, vagy egy döntés a színekről. A fejlesztő ilyenkor vár, a megrendelő pedig azt hiszi, hogy közben dolgoznak az oldalon.

Ezért az első kérdés mindig az, hogy van-e közös, írásos lista arról, mi kell a befejezéshez. Ha nincs, egyik fél sem tudja alátámasztani, hogy a másik késik.

Hivatalosan igazolt. A Polgári Törvénykönyv (2013. évi V. törvény) együttműködési kötelezettséget ír elő a szerződő feleknek, és ismeri a jogosulti, vagyis megrendelői késedelem fogalmát is. Ha a megrendelő nem adja át időben azt, ami a teljesítéshez kell, az a vállalkozó határidejét is érintheti. A pontos következmény a szerződés szövegén és a konkrét tényeken múlik.

Mit nézz meg az állapotfelméréskor?

Nézd meg a tesztoldalt, a szerződést vagy az ajánlatot, és a teljes levelezést. A cél egy rögzített pillanatkép arról, mi készült el, mi van félúton, és mi nem is indult el.

Ezeket érdemes összeszedni:

• A vállalt kör. Mi szerepel az ajánlatban vagy a szerződésben? Hány aloldal, milyen funkciók (űrlap, foglalás, webshop, többnyelvűség), van-e benne szövegírás vagy fotózás.
• A tesztoldal állapota. Nyisd meg mobilon és gépen is. Kattints végig minden menüpontot, és jegyezd fel, hol van még mintaszöveg, hiányzó kép vagy működésképtelen gomb.
• A levelezés. Keresd ki, mit kért tőled a fejlesztő, és mit küldtél el neki. Sokszor kiderül, hogy egy kérés megválaszolatlanul maradt.
• A határidők. Volt-e írásban rögzített dátum, és módosult-e azóta, például mert menet közben új funkciót kértél.
• A kifizetések. Mit fizettél ki eddig, és ehhez a szerződés szerint milyen teljesítés tartozik.

Saját tapasztalat. A tesztoldal végigkattintása azért fontos, mert a szóban emlegetett készültség és a ténylegesen működő oldal között nagy lehet a különbség. Egy jól kinéző főoldal mögött is lehetnek üres aloldalak, be nem kötött űrlap vagy félkész mobilnézet.

Hogyan készíts hiánylistát, ami mindkét félnek egyértelmű?

Minden sor egy konkrét, ellenőrizhető tétel legyen felelőssel, állapottal és dátummal. A „még dolgozni kell a főoldalon” nem tétel. A „főoldal, második szekció, hiányzik a három fő tevékenység rövid leírása, a megrendelőtől várjuk” már az.

Egy egyszerű táblázat elég hozzá, akár megosztott dokumentumban. Ez a szerkezet a legtöbb projektre jól illeszkedik:

• tétel, például Kapcsolat oldal, űrlap
• mi hiányzik, például az űrlap nem küld értesítő levelet
• felelős, vagyis a megrendelő vagy a fejlesztő
• állapot, vagyis nem indult, folyamatban, ellenőrzésre vár vagy kész
• mióta áll, az utolsó lépés dátumával

Néhány minta sor

• Rólunk oldal, a bemutatkozó szöveg hiányzik, a megrendelő felel érte, még nem indult, a fejlesztő kérése óta három hét telt el.
• Kapcsolat oldal, az űrlap nem küld levelet, a fejlesztő felel érte, folyamatban van.
• Adatkezelési tájékoztató, a szöveg hiányzik, a megrendelő vagy a jogásza felel érte, még nem indult.
• Mobilnézet, a menü nem nyílik le, a fejlesztő felel érte, ellenőrzésre vár.

Írd bele a saját tartozásaidat is, őszintén. Ha a szövegek nálad vannak, az kerüljön a lista elejére, és pótold őket, mielőtt bármit számon kérsz. Így a fejlesztő nem hivatkozhat a hiányzó anyagokra, te pedig tiszta lappal kérdezhetsz.

Szakmai feltételezés. A pontosan megfogalmazott hiánylista önmagában is gyakran megmozdítja a projektet. A fejlesztő látja, hogy a megrendelő érti a helyzetet, és a feladat is kezelhetőbbnek tűnik, ha tételekre van bontva.

Hogyan tisztázd írásban a nyitott tételeket?

E-mailben küldd el a hiánylistát, és kérj rá tételes visszajelzést. A telefonos megbeszélés hasznos, de utána mindig írd le, miben állapodtatok meg, és kérd, hogy a fejlesztő erősítse meg.

A levél legyen nyugodt és tényszerű. Egy lehetséges felépítés:

1. Egy-két mondat a helyzetről, vagyis a tesztoldal mostani állapotáról és a szerződés szerinti eredeti határidőről.
2. A hiánylista a levélbe másolva vagy csatolva.
3. Amit te pótolsz, és mikorra.
4. A kérés, hogy a fejlesztő tételenként írja meg, mit vállal és milyen sorrendben.
5. Egy ésszerű válaszadási határidő, például öt munkanap.

Saját tapasztalat. A tételes válasz kérése sokat elárul. Ha a fejlesztő pontonként reagál, a projekt jó eséllyel menthető. Ha csak általánosságban ír („a héten ránézek”), vagy egyáltalán nem válaszol, az már figyelmeztető jel.

Kerüld a vádaskodást és a túlzó kifejezéseket. Egy későbbi vitában ezek a levelek lesznek a bizonyítékaid.

Mikor és hogyan küldj utolsó felszólítást?

Akkor, ha az írásos egyeztetés után sem történik érdemi előrelépés, és te a saját részedet már teljesítetted. Az utolsó felszólítás egy végső, ésszerű határidőt ad, és leírja, mi történik, ha az is eredménytelenül telik el.

Ez kerüljön az utolsó felszólításba:

• hivatkozás a korábbi levelekre, dátummal;
• a még nyitott tételek listája;
• egy végső határidő a teljesítésre;
• annak kimondása, hogy a határidő eredménytelen eltelte után megszünteted az együttműködést, és a munkát más fejezi be;
• kérés, hogy addig is adja át az elkészült munkát és a hozzáféréseket.

Hivatalosan igazolt. A Ptk. vállalkozási szerződésre vonatkozó szabályai szerint a megrendelő a munka befejezése előtt bármikor elállhat a szerződéstől, ilyenkor viszont meg kell térítenie a vállalkozó ebből eredő kárát. Más a helyzet, ha a vállalkozó esik késedelembe, akkor a szerződésszegés szabályai érvényesek. Hogy melyik esetről van szó, az a szerződés szövegén és a tényeken múlik, ezért nagyobb tétnél az utolsó felszólítás előtt érdemes ügyvéddel átnézetni a levelet.

Milyen jelek után érdemes fejlesztőt váltani?

Akkor érdemes, ha a fejlesztő tartósan nem válaszol, a vállalt tételek ismételten, indoklás nélkül csúsznak, vagy nem hajlandó átadni a hozzáféréseket. Egyetlen jel ritkán elég, több együtt viszont már döntési helyzet.

Saját tapasztalat. Ezek a jelek szoktak a leginkább árulkodni:

• két-három írásos megkeresésre sem érkezik érdemi válasz;
• a fejlesztő megígér egy dátumot, az szó nélkül elmúlik, és ez többször megismétlődik;
• a tesztoldalon hetek óta nem változik semmi, pedig az anyagaid már nála vannak;
• a hozzáférés kérésére kitérő válasz jön;
• az oldal olyan fiókokra és licencekre épül, amelyekhez csak ő fér hozzá, és nem tudod, mi a tiéd belőle;
• a hibák javítása újabb hibákat hoz, és a fejlesztő nem tudja megmondani, mi okozza őket.

Ha a lista nagyobbik része kész, és csak a tempóval van gond, egy utolsó, jól dokumentált egyeztetés még megérheti. Ha alapvető dolgok hiányoznak, vagy a szakmai minőség kérdéses, a váltás jó eséllyel kevesebb bosszúsággal jár.

Szakmai feltételezés. Egy új fejlesztő nem mindig a félkész munkát folytatja. Előfordul, hogy gyorsabb újrakezdeni, például ha a meglévő oldal elavult témára vagy nehezen karbantartható bővítménycsomagra épül. Ezt csak felmérés után lehet eldönteni.

Mit kell a kezedben tartanod, mielőtt váltasz?

A domain, a tárhely és az oldal adminisztrátori hozzáférése, valamint a tesztoldal teljes mentése, vagyis a fájlok és az adatbázis. Ezek nélkül az új fejlesztő nulláról indul, vagy a régire vársz tovább.

Belépések és fiókok

• Domain. Nézd meg, kinek a nevén van regisztrálva. A .hu domainek nyilvános adatai a domain.hu oldalon kereshetők. Ha a fejlesztő nevén van, kérd az átírását a te nevedre.
• Tárhely. Ha a tárhelyet ő fizeti a saját fiókjában, kérd az oldal átköltöztetését vagy a fiók átadását.
• Admin belépés. WordPress esetén egy saját, adminisztrátori szintű felhasználó a te e-mail-címeddel.
• Egyéb fiókok. Fizetős téma vagy bővítmény licence, Google Analytics, Search Console, Google Cégprofil és a céges levelezés, ha ezeket ő hozta létre.

Tesztoldal és fájlok

A tesztoldal mentése a fájlokat (téma, bővítmények, feltöltött képek) és az adatbázist jelenti. WordPress oldalnál, ha van parancssori hozzáférés, a WP-CLI eszközzel exportálható az adatbázis, például a wp db export mentes.sql paranccsal, a fájlok pedig a wp-content mappa tömörítésével menthetők. Ugyanez megoldható mentőbővítménnyel vagy a tárhely kezelőfelületéről is. Kérj mellé rövid leírást az egyedi kódokról és a fizetős elemekről.

Hivatalosan igazolt. A Google Search Central dokumentációja szerint a robots.txt nem alkalmas arra, hogy egy oldalt kizárj a Google találatai közül. A tesztoldal elrejtésére a jelszavas védelem vagy a <meta name="robots" content="noindex"> címke a megfelelő eszköz. Költözéskor ellenőrizd, hogy a tesztoldal ne váljon nyilvánosan indexelhetővé, az éles oldalon pedig ne maradjon bent a noindex.

Az addig elkészült munka

Rögzítsd képernyőképekkel a tesztoldal mostani állapotát, oldalanként. Ha vita lesz arról, mi készült el, ez lesz a legegyszerűbb bizonyíték. Gyűjtsd egy mappába a terveket (például a Figma-fájlt vagy a PDF-vázlatot), valamint a szövegeket és a képeket is, amelyeket átadtál.

Hivatalosan igazolt. A szerzői jogról szóló 1999. évi LXXVI. törvény szerint a weboldal grafikai terve és a forráskódja is szerzői műnek minősülhet, a felhasználás jogát pedig a szerződés rendezi. Ha a szerződés erről hallgat, érdemes a váltás előtt írásban rögzíteni, hogy a kifizetett munkát tovább használhatod és továbbfejlesztheted.

Mit tehetsz, ha a fejlesztő nem adja ki a fájlokat?

Először nézd meg, mi van a te kezedben, mert a domain és a tárhely gyakran már a tiéd. Ha nem, írásban, tételesen kérd ki, és nagyobb tétnél fordulj ügyvédhez.

Ha a tárhely a te nevedre szól, a tárhelycég a fiók tulajdonosaként neked is ki tud adni hozzáférést, és onnan a fájlok és az adatbázis lementhetők. Ha a domain is a tiéd, az oldal költöztetése a régi fejlesztő közreműködése nélkül is megoldható.

Saját tapasztalat. Az a helyzet a legnehezebb, amikor minden a fejlesztő fiókjában van, és a szerződés nem rendezi, kié az elkészült munka. Ilyenkor néha egyszerűbb a saját szövegeidből és képeidből új oldalt építeni, mint a régi kiadásáért hónapokig levelezni. A domainért viszont érdemes kitartani, mert a cégneved, a meglévő hivatkozásaid és sokszor a céges e-mail-címed is hozzá kötődik.

Mit rögzíts az új fejlesztővel, hogy ne ismétlődjön meg?

Írásban rögzítsd a vállalt kört, a megrendelői anyagok listáját és határidejét, azt, hogy kinek a nevére kerül a domain és a tárhely, és azt, hogy a kifizetett munkát szabadon felhasználhatod.

• Az ajánlat vagy a szerződés legyen tételes, aloldalanként és funkciónként.
• Legyen benne külön lista arról, mit adsz át te, és mikorra.
• A domain és a tárhely a te nevedre kerüljön, a fejlesztő meghívott felhasználóként dolgozzon rajta.
• Kérj közbenső ellenőrzési pontokat, amikor a tesztoldalt közösen végignézitek.
• Írjátok le, mi számít késznek, és ki hagyja jóvá az átadást. Saját tapasztalat. Sok elakadás abból indul, hogy ez sehol nincs leírva.

Kérhetsz segítséget a félkész projekt felméréséhez?

Igen, és egy külső szem gyorsan meg tudja mondani, mennyire menthető a meglévő munka, és mi kell a befejezéshez.

Ha elakadtál, a Scheo szívesen átnézi a félkész weboldaladat. Megnézzük a tesztoldalt, a hozzáféréseket és a hiánylistát, és elmondjuk, mi van már a te kezedben, mi hiányzik, és a folytatás vagy az újrakezdés tűnik-e ésszerűbbnek. A felmérésből nem kell azonnal döntést hoznod, arra jó, hogy tisztán lásd a helyzetet, mielőtt fejlesztőt váltasz.

Források és további olvasnivalók

• Google Search Central, Bevezetés a robots.txt fájlok használatába
• Google Search Central, Keresési indexelés letiltása a noindex használatával
• 2013. évi V. törvény a Polgári Törvénykönyvről, a vállalkozási szerződés szabályai
• 1999. évi LXXVI. törvény a szerzői jogról
• WordPress.org, WP-CLI parancsdokumentáció (wp db export)
• domain.hu, a .hu Domainregisztrációs Szabályzat