Amit mindenki a sokadik körben kér
– kérd az elején

Mielőtt érdemi fejlesztés kezdődik, készíts egy rövid belső projektdefiníciót.

Határozd meg:

• mi a probléma;
• mi a megoldás;
• kik a célfelhasználók;
• mi az elsődleges use case;
• mi a legfontosabb user journey;
• mi számít sikeres használatnak;
• mi az MVP;
• mi kerül későbbi verzióba;
• milyen külső API-kra, adatokra vagy szolgáltatásokra van szükség;
• milyen technikai és üzleti kockázatok vannak.

Készíts egy folyamatosan frissülő PROJECT CHECKLISTET, amely tartalmazza mindazokat az elemeket, amelyeket a projekt során létre kell hozni.

A checklist ne csak programfunkciókat tartalmazzon, hanem például:

• alkalmazás;
• landing page;
• adminfunkciók;
• analytics;
• SEO;
• social preview;
• dokumentáció;
• marketinganyagok;
• sales anyagok;
• screenshotok;
• videók;
• eDM-ek;
• publikálás;
• domain;
• monitoring;
• backup;
• launch checklist.

A fejlesztés során ezt folyamatosan frissítsd.

Az alkalmazás legyen moduláris.

Kerüld a monolitikus, egyetlen fájlba vagy komponensbe zsúfolt megoldásokat.

Legyen világos:

• frontend;
• backend;
• API;
• database;
• service;
• component;
• configuration;
• integration

struktúra.

A kód legyen más fejlesztő vagy AI coding agent számára is könnyen értelmezhető.

Ne over-engineereld a projektet, de ne építs olyan MVP-t sem, amelyet később csak teljes újraírással lehet továbbfejleszteni.

Minden projektnél készüljön legalább:

README.md

amely tartalmazza:

• projekt célja;
• stack;
• architecture;
• install;
• run;
• environment variables;
• build;
• deploy;
• repository structure.

Ezen kívül legyen dokumentálva:

• külső API-k;
• database;
• fontos business logic;
• deployment;
• backup;
• restore.

Egy új fejlesztő vagy AI coding agent képes legyen a dokumentációból folytatni a projektet.

A változtatható üzleti paramétereket lehetőség szerint ne hardcode-old.

Ilyen lehet:

• AI model;
• email sender;
• feature enable/disable;
• limitek;
• pricing;
• tenant beállítás;
• campaign paraméter.

Ahol indokolt, használj konfigurációt vagy feature flaget.

Design nélkül ne kezdj vakon programozni

Ha nem kaptál kész designt vagy design systemet, akkor a fejlesztés megkezdése előtt készíts saját designkoncepciót.

Ehhez:

1. 1.elemezd a high-level specifikációt;
2. 2.elemezd a célcsoportot;
3. 3.keress aktuális, magas minőségű és lehetőség szerint díjazott vagy kiemelkedő, hasonló célú digitális termékeket;
4. 4.ne másold őket, hanem vond le a használható UX- és vizuális tanulságokat;
5. 5.alakíts ki egy egyedi vizuális irányt;
6. 6.készíts design mockupot/koncepcióképet a ChatGPT/OpenAI image API vagy más rendelkezésre álló képgeneráló rendszer segítségével;
7. 7.ez alapján alakítsd ki a UI design systemet.

A designban kerüld az AI-sablonosságot és a „design slopot”.

Kerüld az automatikusan alkalmazott:

• lila-kék gradienseket;
• indokolatlan glassmorphismot;
• mindenből kártyát készítő UI-t;
• túlzott lekerekítéseket;
• generikus SaaS landing page-eket;
• indokolatlan ikonhalmozást;
• óriási, üres hero blokkokat;
• sablonos stockfotókat;
• vizuális hierarchia nélküli dashboardokat.

Legyen felismerhető saját:

• formanyelv;
• kompozíció;
• tipográfia;
• térhasználat;
• ikonrendszer;
• színrendszer;
• animációs nyelv.

A design mindig a célközönséghez és a termék funkciójához igazodjon.

A publikus rendszerek alapértelmezés szerint:

magyar + angol

nyelven készüljenek.

A rendszer már architekturálisan is legyen lokalizálható.

Ne legyenek a UI-ban szétszórtan hardcode-olt magyar vagy angol szövegek.

Használj központi i18n/localization rendszert.

A nyelvváltás ne csak a navigációt, hanem:

• metadata;
• SEO;
• structured data;
• email;
• error message;
• notification;
• social preview

tartalmakat is kezelje, ahol ez releváns.

A rendszerben jól láthatóan jelenjen meg:

[Projektnév] by [a márkád / cégneved]

A branding legyen végig következetes.

A footerben szerepeljen a projekt jellegéhez illő megfogalmazásban, hogy:

Designed / Developed / Powered by [a márkád / cégneved]

vagy annak magyar megfelelője.

A branding ne legyen zavaró, de ne is legyen eldugva.

Ha külön nem kérem az ellenkezőjét:

Mobile First + Responsive Web App + PWA legyen az alapértelmezett megközelítés.

Ez azonban nem jelentheti azt, hogy az asztali változat csak egy felnagyított mobilnézet.

Külön optimalizáld:

• mobil;
• tablet;
• laptop;
• nagy desktop kijelző

használatára.

A PWA tartalmazzon, ahol releváns:

• manifestet;
• installálhatóságot;
• megfelelő app ikonokat;
• splash screent;
• offline fallbacket;
• service workert;
• verziófrissítési mechanizmust.

Offline működés csak ott készüljön, ahol értelmes.

Push notification csak akkor kerüljön bele, ha valódi funkcionális értéke van.

Az alkalmazás első használatakor induljon rövid onboarding.

A tutorial ne hosszú prezentáció legyen.

Használj:

• tooltipet;
• highlightot;
• hotspotot;
• contextual hintet.

Mutassa meg a rendszer 3–7 legfontosabb funkcióját.

A user bármikor:

• átugorhassa;
• bezárhassa;
• később újraindíthassa.

Ne csak happy path létezzen.

Minden fontos folyamatnál legyen:

• loading state;
• empty state;
• success state;
• error state;
• timeout kezelés;
• retry lehetőség;
• értelmezhető hibaüzenet.

A user ne kapjon nyers stack trace-t vagy értelmezhetetlen API hibát.

Az alkalmazás legyen lehetőség szerint WCAG AA közeli.

Minimum:

• megfelelő kontraszt;
• keyboard navigation;
• focus state;
• semantic HTML;
• alt text;
• label;
• megfelelő heading hierarchy;
• screen reader értelmezhetőség;
• reduced motion figyelembevétele.

Minden publikus rendszer esetén figyelj:

• image optimization;
• lazy loading;
• font loading;
• caching;
• bundle size;
• API response;
• database query;
• Core Web Vitals

értékekre.

Ne tölts le több megabájtos asseteket indokolatlanul.

Alapértelmezés szerint ne építs teljes user management rendszert, ha azt külön nem kérem.

Kivétel:

ha a rendszer működéséhez szükséges

• külön felhasználói adatok kezelése;
• személyes dashboard;
• jogosultság;
• szervezeti elkülönítés;
• fizetés;
• előfizetés;
• multi-tenant működés.

Ebben az esetben a szükséges minimális user/org managementet automatikusan építsd bele.

Ha a megoldás vállalatoknak vagy szervezeteknek szól, alapértelmezés szerint úgy tervezd, hogy később több egymástól független ügyfél is használhassa.

Ne építs olyan B2B rendszert, amely technológiailag egyetlen konkrét ügyfélhez van kötve.

Legyen elkülönítve:

• organization / tenant;
• user;
• tenant-adatok;
• tenant-beállítások;
• jogosultságok.

Az egyik szervezet felhasználója semmilyen körülmények között ne férhessen hozzá más szervezet adataihoz.

A multi-tenant modell lehetőség szerint már az adatmodellben is jelenjen meg.

Készülj fel:

• tenant adminra;
• tenant brandingre;
• tenant konfigurációra;
• adat exportjára;
• tenant törlésére;
• audit logra.

Ha egy rendszer működtetéséhez rendszeresen adatot kell:

• szerkeszteni;
• feltölteni;
• jóváhagyni;
• törölni;
• kategorizálni,

ne arra építs, hogy ezt később közvetlenül adatbázisban kell módosítani.

Készíts megfelelő admin UI-t.

A projekt forráskódjának GitHub repositoryban kell lennie.

A GitHub legyen a source of truth.

Alapértelmezett struktúra:

GitHub → build → container image → deployment → production.

Ha Docker image készül, azt lehetőség szerint GitHub Container Registryben / GHCR-ben tárold.

A Coolify deployment- és orchestration-rétegként működjön, ne elsődleges source/image repositoryként.

Legyen elkülöníthető:

• development;
• staging;
• production.

A repository ne tartalmazzon:

• API kulcsokat;
• jelszavakat;
• production credentialt;
• privát tokent.

Ezek environment variable-ként vagy secret store-ban legyenek.

A repository lehetőség szerint automatikusan ellenőrizze:

• lint;
• typecheck;
• test;
• build

lépéseket.

Production deployment előtt ne kerülhessen ki nyilvánvalóan hibás build.

Legyen visszaállítható korábbi stabil verzió.

Ha adatbázis szükséges:

• dokumentáld a sémát;
• használj migration rendszert;
• legyen backup;
• ne módosíts production adatbázist ad hoc módon;
• kezelj created/updated timestampet;
• multi-tenant rendszernél tenant ID-t;
• ahol releváns, soft delete vagy audit history mechanizmust.

A tesztadat ne keveredjen production adattal.

Production alkalmazásnál legyen:

• strukturált logging;
• kritikus hibák naplózása;
• health check;
• API hibafigyelés.

Komolyabb rendszernél használj error monitoring megoldást.

Az adminnak legyen lehetősége észlelni, ha:

• API nem működik;
• háttérfolyamat leáll;
• AI provider hibázik;
• email nem ment ki;
• adatimport meghiúsult.

Adatot tároló production rendszer esetén legyen:

• rendszeres backup;
• backup retention;
• restore eljárás.

Nem elegendő az, hogy „a VPS-en megvan”.

Legalább dokumentálva legyen, hogyan lehet katasztrófa után visszaállítani a rendszert.

Alapértelmezett biztonsági minimum:

• HTTPS;
• secret management;
• input validation;
• output escaping;
• megfelelő authorization;
• rate limiting ahol szükséges;
• biztonságos file upload;
• megfelelő CORS;
• session/token security;
• dependency-frissíthetőség;
• minimális jogosultság elve.

Soha ne bízz pusztán frontend oldali jogosultságellenőrzésben.

Multi-tenant rendszernél backend szinten is biztosítsd az adatok elkülönítését.

Publikus EU-s projektnél már tervezéskor gondolj:

• Privacy Policy;
• Cookie Policy;
• Terms / ÁSZF ahol szükséges;
• adatkezelési célokra;
• adattárolás idejére;
• adat törlésére;
• adatexportra;
• hozzájárulásokra.

Ne gyűjts olyan személyes adatot, amelyre nincs szükség.

Analytics és marketing tracking megoldásoknál kezeld megfelelően a hozzájárulást.

Ne használj olyan:

• fotót;
• fontot;
• ikont;
• videót;
• zenét

amelynek felhasználási joga nem egyértelmű.

Preferáld:

• saját asset;
• generált asset;
• megfelelően licencelt asset.

Tartsd nyilván az asset forrását/licencét, ahol szükséges.

Minden publikus projekthez kerüljön analytics.

Alapértelmezett választás lehet:

Umami

vagy más privacy-friendly rendszer.

Development környezetben ne szennyezze a production statisztikát.

A production analytics akkor aktiválódjon, amikor az oldal tényleges publikus domainre kerül.

Ne csak pageview-t mérj.

A fontos user actionökből legyen event:

• registration;
• CTA;
• tool start;
• tool finish;
• export;
• share;
• lead;
• conversion;
• error;
• fontos feature használat.

Már fejlesztéskor gondold végig:

Honnan fogjuk tudni három hónap múlva, hogy használják-e a terméket?

Határozd meg a releváns KPI-kat.

Például:

• látogatók;
• returning users;
• tool starts;
• completed workflows;
• conversion;
• engagement;
• lead;
• retention.

A marketinganyagok linkjei használjanak következetes UTM rendszert.

Mérhető legyen:

• honnan érkezett a látogató;
• melyik kampányból;
• melyik posztból;
• melyik hirdetésből;
• melyik eDM-ből.

A conversion eventek kapcsolódjanak ezekhez.

Ha a rendszer fizetős API-kat használ, legyen mérhető:

• API hívásszám;
• token;
• storage;
• email;
• image generation;
• video generation;
• külső service usage.

AI rendszernél lehessen legalább hozzávetőlegesen megmondani:

egy user / egy folyamat / egy hónap mennyibe kerül.

Kerüld az indokolatlan API hívásokat.

Ha AI API kerül a rendszerbe, az alkalmazást ne kösd szükségtelenül egyetlen szolgáltatóhoz.

Lehetőség szerint támogatható legyen több provider:

• OpenAI;
• Anthropic Claude;
• Google Gemini;
• DeepSeek;
• szükség esetén más provider.

Készíts provider abstraction layert.

A konfigurációból lehessen meghatározni:

• provider;
• model;
• temperature;
• token limit;
• fallback model.

Legyen lehetőség fallbackre, ha az elsődleges szolgáltatás nem működik.

A rendszer logolja legalább:

• provider;
• model;
• latency;
• token usage;
• hozzávetőleges költség;
• error.

A promptokat lehetőség szerint ne szétszórtan hardcode-old.

Legyen központi prompt/template rendszer és verziózás.

API integráció előtt ellenőrizd az aktuális hivatalos dokumentációt.

Ne találj ki endpointot vagy paramétert.

Ha valamely credential még nincs meg, készíts működő mockot vagy integration placeholdert, és dokumentáld pontosan, mi szükséges az aktiváláshoz.

Fizetős API-t vagy új fizetős szolgáltatást ne aktiválj automatikusan.

Minden önálló alkalmazáshoz készüljön saját publikus weboldal.

Ez különösen fontos akkor is, ha maga a termék egy tool.

A látogató ne közvetlenül egy ismeretlen alkalmazásba érkezzen.

A weboldal mutassa be:

• problémát;
• célcsoportot;
• megoldást;
• működést;
• legfontosabb funkciókat;
• képernyőképeket;
• előnyöket;
• használati példákat;
• FAQ-t;
• CTA-t.

Innen legyen elindítható maga az alkalmazás.

A landing page:

• designolt;
• responsive;
• HU/EN;
• SEO-optimalizált;
• AI-crawlerek számára jól értelmezhető;
• gyors;
• hozzáférhető

legyen.

A landing page akkor tekinthető késznek, amikor maga a termék is megfelelően bemutatható.

A SEO és az AI visibility minden publikus projekt kötelező része.

Az alábbi követelményeket:

• már projektindításkor;
• fejlesztés közben;
• launch előtt

is vedd figyelembe. Ha van külön láthatósági checklist vagy kézikönyv a projekthez, azt is kezeld kötelezőnek.

A SEO ne utólag hozzáadott plugin legyen.

Az oldalstruktúra, URL-ek, headingek és tartalmak már eleve ennek megfelelően készüljenek.

Minimum:

• semantic HTML;
• title;
• meta description;
• canonical;
• sitemap.xml;
• robots.txt;
• OpenGraph;
• social preview image;
• favicon;
• structured data / Schema.org;
• hreflang;
• megfelelő belső linkelés;
• crawlolható tartalom;
• gyors oldal;
• emberileg értelmes URL-ek.

Készüljön elő a rendszer:

• Google Search Console;
• Bing Webmaster Tools

használatára.

AI visibility szempontból legyen a tartalom:

• egyértelműen strukturált;
• entitások szerint értelmezhető;
• jól idézhető;
• informatív;
• egyedi;
• nem kizárólag JavaScript UI-ban elrejtett.

Ahol releváns, legyen:

• FAQ;
• glossary;
• how-it-works;
• use case;
• about;
• source/reference

tartalom.

Minden publikus oldal rendelkezzen jó minőségű:

• OpenGraph title;
• description;
• image

tartalommal.

Ha valaki LinkedInen, Facebookon, Teamsben vagy más platformon megosztja a linket, az eredmény vizuálisan professzionális legyen.

A projekt elkészülte után a rendszer készítsen saját magáról projektbejegyzést a portfólióhoz / referenciaoldalra. Ha van erre szolgáló skill, API vagy beküldő felület, használd azt; ha nincs, készíts kész, publikálható szöveget és képeket.

A bejegyzés legalább tartalmazza:

• projekt neve;
• rövid összefoglaló;
• probléma;
• megoldás;
• célcsoport;
• technológia;
• fő funkciók;
• screenshot;
• publikus URL;
• dátum;
• státusz.

Az alaptermék elkészülése után készüljön hozzá belső Marketing & Sales CMS.

Ennek célja nem pusztán a tartalomtárolás.

A rendszer segítsen végigvinni a termék teljes digitális kommunikációját.

A CMS tartalmazzon:

• content calendar;
• kampányokat;
• célcsoportokat;
• platformokat;
• asset libraryt;
• post szövegeket;
• képeket;
• videókat;
• hirdetéseket;
• eDM-eket;
• státuszokat;
• publikálási időpontokat;
• UTM paramétereket;
• kampányeredményeket.

Alapértelmezés szerint először draftokat készítsen.

Automatikus publikálást vagy küldést csak akkor végezzen, ha ehhez megfelelő hozzáférés és egyértelmű engedély van.

Készüljön kommunikáció legalább:

• LinkedIn;
• Facebook;
• Instagram;
• TikTok;
• YouTube Shorts

platformokra, amennyiben az adott terméknél relevánsak.

A platformokra ne ugyanazt a posztot másold.

A szöveg, képarány, videóhossz és CTA igazodjon az adott platformhoz.

Készüljön:

• post text;
• headline;
• description;
• hashtag/keyword javaslat;
• CTA;
• vizuál.

Készüljön induló kreatívcsomag:

• Meta;
• LinkedIn;
• Google Ads;
• YouTube;
• TikTok;
• adott esetben ChatGPT/AI platformokon elérhető hirdetési formák.

Az aktuálisan létező platformokat és formátumokat mindig ellenőrizd.

Készíts megfelelő képarányokat és méreteket.

A kreatívokhoz használhatsz:

• valódi screenshotot;
• device mockupot;
• UI részletet;
• generált key visualt;
• ezek kombinációját.

A projekthez készíts rövid bemutató videók előállítására alkalmas pipeline-t.

Lehetőség szerint a valódi alkalmazást automatizáltan használd, és abból készüljön screen recording.

A rendszer szimulálja a felhasználói interakciót.

Alkalmazható:

• zoom;
• crop;
• pan;
• gyorsítás;
• lassítás;
• cursor emphasis;
• transition;
• felirat;
• callout.

Készüljön többek között:

• 10–15 mp teaser;
• 30–60 mp social video;
• hosszabb product demo.

A videó ne keltsen megtévesztő képet nem létező funkcióról.

A termékhez készüljön legalább egy induló 4–8 hetes kommunikációs terv.

A calendar tartalmazza:

• dátum;
• platform;
• célcsoport;
• téma;
• formátum;
• szöveg;
• asset;
• CTA;
• státusz;
• kampány;
• UTM.

A projekthez létrehozott marketingelemek legyenek rendezett struktúrában tárolva.

Például:

/marketing /screenshots /social /ads /video /email /logos /mockups /press

A fájlnevek legyenek érthetők és verziózhatók.

A Marketing & Sales CMS tudjon potenciális célcsoportokat és leadeket kezelni.

Lehetséges kategóriák:

A. Végfelhasználók

Akik közvetlenül használhatják vagy megvásárolhatják a terméket.

Lehetnek:

• magánszemélyek;
• cégek;
• szervezetek;
• intézmények;
• szakemberek.

B. Közvetítők / szakmai szereplők

Akik nem feltétlenül vásárlók, de elérik a célcsoportot.

Például:

• szakmai szervezetek;
• egyesületek;
• média;
• influencerek;
• oktatók;
• szakértők;
• konferenciák;
• szakportálok.

C. Potenciális támogatók / szponzorok

Olyan cégek vagy márkák, amelyek saját célcsoportja részben megegyezik a termék célcsoportjával.

Leadgyűjtéskor lehetőség szerint gyűjts:

• cégnév;
• weboldal;
• kapcsolattartó;
• pozíció;
• publikus üzleti email;
• kapcsolat oka;
• célcsoport kategória;
• forrás;
• státusz;
• megkeresés ideje.

Kerüld:

• érzékeny személyes adatok gyűjtését;
• indokolatlan személyes adatgyűjtést;
• tiltott vagy nem jogszerű scrapinget.

Tartsd meg az adat forrását, hogy később visszaellenőrizhető legyen.

Legyen:

• duplicate detection;
• unsubscribe / do-not-contact státusz;
• suppression list.

A termékhez készüljön teljes email kommunikációs rendszer.

Ide tartozhat:

• lead outreach;
• Mailchimp kampány;
• saját mail server;
• transactional email.

Készüljön legalább:

• első kapcsolatfelvétel;
• follow-up;
• regisztráció megerősítés;
• welcome email;
• köszönő email;
• értesítések;
• unsubscribe.

Az emailek vizuálisan igazodjanak a termék designjához.

Személyes megkeresésnél az email ne generikus tömeges spamnek tűnjön.

Használja a címzett szervezetéhez és szerepéhez kapcsolódó releváns információt.

Minden olyan projektnél, amelynek lehet támogatója vagy szponzora, készüljön külön:

Partner / Sponsor Presentation Page.

Ez alapértelmezés szerint:

• nincs a fő navigációban;
• direkt URL-ről elérhető;
• designban a főoldalhoz illeszkedik.

Mutassa be:

• mi a projekt;
• kik használják;
• mekkora problémát old meg;
• miért releváns a célcsoport;
• milyen társadalmi / üzleti / kommunikációs értéket teremt;
• hogyan jelenhet meg a partner;
• milyen együttműködési lehetőségek vannak.

Használjon:

• screenshotokat;
• animált UI-részleteket;
• rövid demót;
• számokat;
• illusztrációkat.

Fontos:

A „nincs menüben” nem azonos a priváttal.

Ha az oldal valóban bizalmas, kapjon authentikációt.

Ha csak unlisted, de nem szeretnénk keresőben látni, használjunk noindex beállítást.

Ne tekints egy funkciót késznek csak azért, mert egyszer működött.

Teszteld legalább:

• fő user journey;
• input validation;
• API error;
• empty state;
• mobil nézet;
• desktop nézet.

A kritikus business logic kapjon unit/integration tesztet.

A legfontosabb end-to-end folyamatokat lehetőség szerint automatizált browser test ellenőrizze.

Nem cél a 100%-os tesztlefedettség.

A cél a regressziók és kritikus hibák korai felismerése.

Launch előtt ellenőrizd legalább:

• Chrome desktop;
• Chrome Android;
• Safari iOS;
• Edge desktop.

Vizsgáld:

• responsive layout;
• keyboard;
• touch;
• scroll;
• modal;
• form;
• menu;
• PWA.

Ne használj placeholdert production rendszerben.

Ne maradjon:

• Lorem ipsum;
• „Coming soon” indokolatlanul;
• fake testimonial;
• fake számadat;
• nem működő gomb;
• # link;
• placeholder kép;
• demo user adat.

Minden CTA működjön.