# DARWINAI VIBE CODING RULES 1.0
**Standard vibe coding követelményrendszer – a teljes szabálykönyv**

> Ezt a fájlt a coding agentnek (és neked) szánjuk. Egy konkrét projekthez nem kell mind: állítsd össze a hozzá illőket a Szabály-összeállítóval (https://darwinai.hu/vibe-coding/szabaly-osszeallito), vagy töröld ki a nem releváns szakaszokat. A kész fájlt tedd a projektmappa gyökerébe, és az első promptban kérd meg az agentet, hogy olvassa el.
>
> Verzió: 1.0 · 46 szabály · 2026. 10. 06.

© 2026 DarwinAI · Budaházy Szabolcs – darwinai.hu
Saját (és a szervezeted) projektjeihez és oktatási célra szabadon felhasználhatod és átszabhatod. Továbbadáskor, közzétételkor vagy átdolgozott változatnál a forrás megjelölése kötelező: „DarwinAI – darwinai.hu”.

---

## 0. ALAPELV

Amikor új szoftverfejlesztési projektet kezdesz, az ebben a dokumentumban szereplő elveket, funkciókat és ellenőrzési pontokat **alapértelmezett követelményként kezeld akkor is, ha a konkrét projektleírás külön nem említi őket**.

Csak akkor térj el tőlük, ha erre kifejezett utasítást kapsz, vagy az adott projekt jellegéből egyértelműen következik, hogy valamelyik pont nem releváns.

Ne csak a konkrétan kért funkciót készítsd el. Gondolkodj a **teljes termékben**:

- termék,
- UX/UI,
- technológia,
- üzemeltetés,
- biztonság,
- mérhetőség,
- dokumentáció,
- láthatóság,
- SEO és AI SEO,
- marketing,
- sales,
- kommunikáció,
- skálázhatóság,
- későbbi továbbfejleszthetőség.

A cél nem egy működő prototípus, hanem egy **publikálható, mérhető, kommunikálható és továbbfejleszthető digitális termék**.

## 1. PROJEKTINDÍTÁS

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.

## 2. UX/UI ÉS DESIGN

### 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. elemezd a high-level specifikációt;
2. elemezd a célcsoportot;
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. ne másold őket, hanem vond le a használható UX- és vizuális tanulságokat;
5. alakíts ki egy egyedi vizuális irányt;
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. 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.

## 3. RESPONSIVE ÉS PWA ALAPELVEK

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.

## 4. NYELVEK

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.

## 5. BRANDING

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.

## 6. USER MANAGEMENT

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.

## 7. B2B = MULTI-TENANT ALAPÉRTELMEZÉS

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.

## 8. ALKALMAZÁS-TUTORIAL

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.

## 9. LANDING PAGE / TERMÉKOLDAL

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ó.

## 10. TECHNIKAI ARCHITEKTÚRA

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.

## 11. GITHUB, BUILD ÉS DEPLOYMENT

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.

## 12. CI/CD

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ó.

## 13. ADATBÁZIS

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.

## 14. ANALYTICS

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.

## 15. PRODUCT ANALYTICS

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.

## 16. ERROR HANDLING

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.

## 17. LOGGING ÉS MONITORING

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.

## 18. BIZTONSÁG

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.

## 19. GDPR ÉS PRIVACY

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.

## 20. ACCESSIBILITY

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.

## 21. PERFORMANCE

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.

## 22. AI FUNKCIÓK

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.

## 23. KÜLSŐ API-K

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.

## 24. SEO + AI VISIBILITY

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.

## 25. SOCIAL SHARING

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.

## 26. PROJEKTBEJEGYZÉS (PORTFÓLIÓ)

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.

## 27. MARKETING ÉS SALES RÉTEG

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.

## 28. SOCIAL MEDIA TARTALOM

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.

## 29. HIRDETÉSEK

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.

## 30. MARKETING VIDEÓK

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.

## 31. MARKETING NAPTÁR

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.

## 32. LEAD GENERATION

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.

## 33. LEAD ADATGYŰJTÉS

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.

## 34. E-MAIL / eDM

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.

## 35. SPONSOR / PARTNER PAGE

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.

## 36. MARKETING ATTRIBUTION

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.

## 37. ASSET LIBRARY

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.

## 38. DOKUMENTÁCIÓ

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.

## 39. TESZTELÉS

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.

## 40. BROWSER ÉS DEVICE ELLENŐRZÉS

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.

## 41. TARTALMI MINŐSÉG

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.

## 42. LICENSE ÉS ASSET EREDET

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.

## 43. ADMINISZTRÁCIÓ

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.

## 44. FEATURE FLAGS ÉS KONFIGURÁLHATÓSÁG

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.

## 45. BACKUP ÉS RESTORE

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.

## 46. KÖLTSÉGKONTROLL

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.

## 47. DEFINITION OF DONE

A projektet ne tekintsd befejezettnek attól, hogy a fő funkció működik.

A projekt akkor kész, ha legalább:

- [ ] a core functionality működik
- [ ] a mobil UI kész
- [ ] a desktop UI kész
- [ ] a HU/EN működik
- [ ] a branding megfelelő
- [ ] az onboarding működik
- [ ] a landing page elkészült
- [ ] a repository rendezett
- [ ] a staging és a production működik
- [ ] az analytics működik
- [ ] a fő események mérve vannak
- [ ] az error state-ek működnek
- [ ] a loading state-ek működnek
- [ ] a biztonsági minimum ellenőrizve
- [ ] az adatvédelem / GDPR ellenőrizve
- [ ] az akadálymentesség ellenőrizve
- [ ] a teljesítmény ellenőrizve
- [ ] a SEO ellenőrizve
- [ ] a sitemap elkészült
- [ ] a robots.txt elkészült
- [ ] az OpenGraph elkészült
- [ ] a structured data elkészült
- [ ] a SEO + AI visibility minimum végig van ellenőrizve
- [ ] a projektbejegyzés elkészült
- [ ] a marketing CMS elkészült vagy előkészített
- [ ] az induló social csomag elkészült
- [ ] az induló hirdetési kreatívok elkészültek
- [ ] a marketing calendar elkészült
- [ ] az eDM-ek elkészültek
- [ ] a szponzor / partner oldal elkészült, ha releváns
- [ ] a README elkészült
- [ ] a környezet (environment) dokumentálva van
- [ ] az alapvető tesztek lefutnak
- [ ] nincs placeholder tartalom
- [ ] nincs nem működő CTA
- [ ] a backup megoldott

## 48. VÉGSŐ ÖNELLENŐRZÉS

A projekt lezárása előtt ne azt kérdezd:

> „Megcsináltam-e azt, amit a brief kért?”

Hanem ezt:

> „Ha ezt a terméket holnap nyilvánosan elindítanánk, mi hiányozna még ahhoz, hogy valódi emberek megtalálják, megértsék, használják, ajánlják, megvegyék, illetve hogy mi mérni, üzemeltetni és továbbfejleszteni tudjuk?”

Az így talált hiányosságokat vedd fel a checklistre és – amennyiben nem igényelnek üzleti döntést, fizetős szolgáltatás aktiválását vagy új credentialt – készítsd el automatikusan.

## FŐ MŰKÖDÉSI ELV

**Ne várd meg, hogy minden evidens szakmai részletet külön kérjek.**

Ha egy professzionális digitális termékhez egy elem logikusan szükséges, jelezd, tervezd meg és lehetőség szerint építsd be.

Ugyanakkor:

- ne építs értelmetlen funkciókat;
- ne növeld öncélúan a komplexitást;
- ne aktiválj fizetős szolgáltatást engedély nélkül;
- ne hozz üzleti vagy jogi döntést helyettem;
- ne publikálj vagy küldj kommunikációt automatikusan engedély nélkül.

A cél:

**a lehető legkevesebb utólag eszünkbe jutó „ezt még bele kellett volna rakni” típusú hiányosság.**

---

© 2026 DarwinAI · Budaházy Szabolcs – darwinai.hu
Forrás: DarwinAI – darwinai.hu/vibe-coding