Mi történik az első 48 órában egy Nortinia tanácsadásnál

Az első 48 óra a legkritikusabb egy tanácsadói megbízásban. Nem azért, mert ilyenkor történik a legtöbb munka — hanem azért, mert ilyenkor dől el az ügyfél bizalma. Ha két nap után azt látja, hogy még mindig onboarding meeting-ek vannak és "megismerkedünk a kóddal", az bizalomvesztés. Ha két nap után staging-en egy működő prototípus fut, az bizalom-megerősítés.

Óra 0–4: Aláírás és azonnali hozzáférés

A szerződés aláírása után azonnal (nem másnap, nem hétfőn) megtörténik a technikai onboarding. Az ügyfél egy megosztott Notion dokumentumot kap, amiben már ott van: git repo hozzáférés checklist, staging environment credentials sablon, Slack/Teams csatorna meghívó, és a Nortinia Consulting App workspace linkje. Ha az ügyfél oldalán bármely hozzáférés késik, a mi csapatunk ezt az időt a publikus API dokumentáció, a CI pipeline és az adatbázis séma feltérképezésére használja.

Óra 4–12: Stack audit és első ADR

Amint van repo hozzáférés, a senior mérnök lefuttatja a standard stack audit-ot: dependency verzió check, TypeScript strict mód állapot, test coverage riport, docker-compose felépítés, és a deploy pipeline review. Ennek az eredménye egy 1 oldalas ADR (Architecture Decision Record), ami tartalmazza: mi az első modul amit építünk, miért pont azt, és mi az acceptance criteria. Ez az ADR az ügyfél jóváhagyása után azonnal a backlog tetejére kerül.

Óra 12–36: Első működő feature staging-en

A 12. és 36. óra között születik meg az első production-quality kód. Nem proof-of-concept, nem throwaway prototípus — hanem tesztelt, linted, review-zott kód, ami staging-en fut. Tipikusan ez egy egyszerűbb, de üzletileg azonnal hasznos modul: egy notification engine, egy import pipeline, egy riport endpoint, vagy egy admin CRUD. A cél nem az, hogy imponáljunk — hanem az, hogy az ügyfél lássa: ez a csapat nem beszél, hanem szállít.

Óra 36–48: Demo és következő sprint scope

A 48. óra végére van egy 15 perces demo hívás. Az ügyfél a staging URL-en maga is kipróbálhatja a modult. A demo után közösen meghatározzuk a következő 8 nap (a sprint hátralévő része) scope-ját. Ez a meeting általában 30 perc, mert addigra már van közös kontextus: a mérnök ismeri a kódot, az ügyfél látta az első eredményt, és mindkét fél tudja, mi a tempó.

• Óra 0–4: szerződés → hozzáférés → Consulting App workspace megnyitva
• Óra 4–12: stack audit → 1 oldalas ADR → ügyfél jóváhagyás
• Óra 12–36: első modul kódolás → code review → staging deploy
• Óra 36–48: demo → feedback → következő sprint scope-ja fixálva
• Nincs slide deck, nincs "megismerkedünk" hét, nincs üres standup

Miért működik ez — és miért nem csinálja mindenki

Azért működik, mert a Nortinia saját stack-en dolgozik (Netorigo platform), és a legtöbb modul-típust már megépítettük legalább egyszer a saját termékeinkben. Nem kell hetente felfedezni, hogyan működik egy notification engine vagy egy BullMQ queue — van rá kész, éles mintánk. Azért nem csinálja mindenki, mert ehhez saját platform kell, nem csak fejlesztői kapacitás. A legtöbb tanácsadó cég az ügyfél stack-jén dolgozik a nulláról — és ilyenkor reális, hogy az első hét valóban onboarding.

A bizalom nem a szerződésben születik — hanem az első staging deploy-nál. Minél hamarabb van ott, annál kevesebb a súrlódás a maradék 9 hónapban.