Superz
Superz

Superz illat-szintű szavazási platform

Egyedi Shopify alkalmazás · superz.eu + superz.com · Dawn / Online Store 2.0

A javasolt megoldás egy egyedi Shopify app, amely a termékoldalakon Fragrantica-jellegű közösségi visszajelzést jelenít meg, `fragrance_id` alapú katalóguslogikára épül, és kontrollált módon váltja ki a Judge.me jelenlegi szerepének egy részét. A scope már nem csak widgetfejlesztés: vásárlásalapú meghívólogikát, shared backend architektúrát, rich legacy importot és egy könnyű moderációs felületet is tartalmazó platformelemről beszélünk.

2026. márciusInteraktív ajánlat · az alapbeállítás a javasolt irányt mutatjaÉrvényesség: egyeztetés szerint

Aktuális ajánlati kép

közös backend · Judge.me migráció · mélyebb parity · compact blokk most

190–250 óra összesen

Ajánlati link:

Kiindulási helyzet és rögzített projektalapok

Az alábbiak a jelenleg ismert, rögzített projektalapok, amelyekre az ajánlat épül.

  • Mindkét store New Customer Accounts rendszeren fut, ezért élesben nem építünk klasszikus shortcut-auth megoldásra.
  • A validáció valós customer accountokkal történik; nincs megbízható Shopify teszt-user útvonal erre a projektre.
  • A két store közös backendből működik, szigorú store-szintű adatszétválasztással.
  • A Judge.me kezelésének alapja import + fokozatos kiváltás.
  • A legacy import gazdagabb, mélyebb mezőkezeléssel tervezendő, nem csak text-only alapon.
  • A jelenlegi scope része egy compact trust / star blokk, de ez nem teljes Judge.me storefront parity.
  • Az első verzió fő megjelenítése eloszlás + darabszámok, nem teljes review-rendszer parity.
  • Az „all seasons” külön választható opció marad, nem automatikusan származtatott állapot.
  • A felület teljesen locale-fájl alapú, így fordítható és Translate & Adapt kompatibilis marad.
  • A baseline accessibility része a fókuszsorrend, az ikonok megfelelő címkézése és a reduced-motion figyelembevétele.
  • A projekt végén rövid technikai adatkezelési / rendszerleírás adható a merchant jogi anyagának támogatására.
  • Csak valódi vásárlók kaphatnak meghívót és szavazhatnak; ezt order/fulfillment alapú jogosultsági réteg védi.
  • Az első verzió része egy minimális merchant dashboard a moderációhoz, show/hide kezeléshez és egyszerű szabályokhoz.

A pontos Judge.me / app block elhelyezés a Dawn theme editorban véglegesíthető, és önmagában nem jelent jelentős becslési kockázatot.

Nyitott aggregációs döntések

A fő kereskedelmi és műszaki alapok már rögzítettek, de az aggregáció pontos szintjét még a votelogikához és a legacy importhoz együtt kell lezárni.

Két összefüggő kérdést kell még közösen véglegesíteni, mert a kettő ugyanahhoz az aggregációs üzleti logikához kapcsolódik.

  • az új vote-ok maradjanak termék-szinten, vagy illat / család szinten gyűljenek,
  • a legacy review-k első körben maradjanak termék-szinten, vagy rögtön ugyanebbe az aggregációs logikába kerüljenek.
D14

Induló aggregációs modell

A kickoff előtt lezárandó kérdés, hogy az első fázisban a visszajelzések maradjanak-e termék-szinten, vagy azonos illathoz tartozó SKU-k közös aggregátumba kerüljenek. Ehhez igazodik a legacy review-k első körös megjelenítése is.

Üzleti célok

Mit kell a megoldásnak üzletileg és technikailag egyszerre teljesítenie?

Cél

Erős közösségi visszajelzés

Mit jelent ez a projektben?

Az érzelmi és viselési mintázatok láthatóvá tétele őszinte eloszlás-alapú megjelenítéssel, külön a klasszikus csillagos review-rétegtől.

Cél

Csak vásárlók vehessenek részt

Mit jelent ez a projektben?

A jogosultságot nem a storefront UI dönti el, hanem egy vásárláshoz és meghívóhoz kötött backend-flow, így a visszajelzés üzletileg védhetőbb.

Cél

Katalógus- és aggregációs logika

Mit jelent ez a projektben?

Ez jelenleg még nyitott üzleti döntés: a visszajelzés maradjon inkább termék-szinten, vagy azonos illathoz tartozó SKU-k közös aggregátumba kerüljenek. Ezt a legacy importtal együtt kell véglegesíteni.

Cél

Élesben stabil azonosítás

Mit jelent ez a projektben?

A New Customer Accounts környezethez igazított auth/session logika biztosítja, hogy a megoldás ne storefront workaroundokra épüljön.

Cél

Két store, kontrollált működés

Mit jelent ez a projektben?

A rendszer mind a `.eu`, mind a `.com` store-ban ugyanarra a közös alkalmazáslogikára támaszkodhat, így nem kell két külön megoldást párhuzamosan felépíteni és fenntartani. Ez alacsonyabban tartja az induló fejlesztési és üzemeltetési terhet, miközben az adatok store-szinten továbbra is elkülöníthetők, tehát a két piac működése kontrollált marad.

Cél

Moderálható és működtethető rendszer

Mit jelent ez a projektben?

A merchant egy minimális adminfelületen látja a review-kat, és tud show/hide vagy egyszerű szabályalapú láthatósági döntéseket hozni.

Szállítási tartalom

Mit tartalmaz az ajánlott alapprojekt, és mire épülhetnek a későbbi bővítések?

Egyedi Shopify alkalmazás

Backend API, adatmodell, aggregációk, rate limiting, deploy és technikai átadás egy üzletileg védhető scope-ban.

Theme App Extension megjelenítés

Dawn-kompatibilis termékoldali app blokk, amely merchant-placed módon illeszthető a jelenlegi theme felépítéshez.

Szavazási élmény

Érzelmi skála és viselési kontextus egyértelmű, gyors kitöltési folyamattal és bejelentkezéshez kötött szavazással.

Vásárlásalapú meghívó flow

Csak a vásárláshoz kötött, időzített meghívók nyitják meg a szavazás lehetőségét, így a jogosultság nem marad laza storefront-szinten.

Aggregációs modell

A kickoff előtt véglegesíteni kell, hogy a szavazatok és az importált legacy review-k termék-szinten maradjanak-e, vagy illat / család szinten kerüljenek összevonásra.

Moderációs felület

Könnyű merchant oldal a review-k áttekintésére, show/hide moderációra és egyszerű láthatósági szabályokhoz.

Migrációs és kiváltási réteg

Az architektúra a jelenlegi Judge.me import + fokozatos kiváltási irányt támogatja, rich legacy mezőkezeléssel.

Technikai megközelítés

Az ajánlott stack és annak hatása a választott scope-ra

Az aktuális konfiguráció fő műszaki következményei

  • Az ajánlott alapmodell egy közös app backend és adatbázis mindkét store számára, szigorú store-szintű szétválasztással.
  • A migrációs irány szerint a Judge.me exportált adatai az új rendszerbe kerülnek, kontrollált átmeneti logikával.
  • Az üzleti szabály szerint csak valódi vásárlók kapnak meghívót, és a szavazás jogosultsága order/fulfillment alapú eligibility réteggel védett.
  • A merchant számára könnyű moderációs felület készül a review-k áttekintésére, show/hide kezelésére és egyszerű szabályalapú láthatóságra.
  • A mélyebb legacy parity szélesebb mezőlistát, összetettebb adatmappinget és nagyobb QA-terhet jelent.
  • A scope tartalmaz egy könnyített trust / compact star blokkot is a megállapodott megjelenési pontokra.
  • Az első fázis egyszerűbb, termék-szintű aggregációval indulhat, és a magasabb szintű rollup későbbi bővítésként kezelhető.

Shopify réteg · Online Store 2.0, Theme App Extension, app backend

A storefront integráció tiszta marad, miközben a valódi üzleti logika az alkalmazásrétegben él.

Azonosítás · New-account-safe identity / session flow

Éles működésre alkalmas megoldás, amely nem függ törékeny proxy-paraméterektől önmagukban.

Adat és védelem · Postgres + Redis

Tartós szavazatok és legacy adatok külön kezelve a rövid életű session, state és rate-limit logikától.

Jogosultság és automatizmus · Order / fulfillment események + invite token flow

A vásárlási jogosultság, a meghívó küldés és a tokenes belépés app-oldali háttérlogikát igényel, nem csak storefront feltételes UI-t.

Merchant admin · Könnyű moderációs dashboard

A merchant itt tudja a megjelenítést kézzel vagy egyszerű szabályok mentén kontrollálni.

Hoszting · Fly.io + Neon + Upstash

Átlátható, usage-alapú induló költség és éles használatra alkalmas, fokozatosan skálázható infrastruktúra.

Kereskedelmi javaslat: az infrastruktúra külön, transzparensen kommunikálható, a support pedig külön szolgáltatási rétegként kezelhető.

Kizárások és scope-határok

Az ajánlat védhetősége érdekében ezek csak külön egyeztetéssel kerülnek be.

Teljes Judge.me feature parity, ha nincs külön scope-ban rögzítve.

Komplex CRM / marketing automation programok a minimális invite flow-on túl.

A merchant jogi dokumentumainak újraírása; mi technikai háttérleírást tudunk adni.

A Judge.me folyamatos üzleti / előfizetéses menedzsmentje.

A `fragrance_id` katalógusadatok manuális kitöltése a megállapodott handoff-formátumon túl.

A baseline szintet jelentősen meghaladó accessibility scope, ha nincs külön rögzítve.

Haladó riporting, dashboard-analitika vagy több szerepkörös admin workflow külön megállapodás nélkül.

Szükséges ügyféloldali inputok

Ezek a projekt gördülékeny indulásának legfontosabb feltételei.

Shopify hozzáférések

App install, admin és theme editor hozzáférés, valamint a szükséges teszt accountok biztosítása.

`fragrance_id` mapping

A termékekhez tartozó illat-azonosítók vagy azok egyértelmű képzési szabályainak átadása.

Judge.me mezőlista és mapping

A legacy importhoz szükséges mezők, termék- vagy illat/családszintű összerendelések és a kívánt parityszint jóváhagyása.

Elhelyezési döntések

A megjelenési pont(ok) jóváhagyása a termékoldalon, különösen a compact trust blokk és a Judge.me melletti vagy helyetti használat esetén.

Meghívó és moderációs szabályok

Az invite időzítése, a küldési csatorna, az esetleges emlékeztetők és az alap moderációs show/hide szabályok jóváhagyása.

Ajánlati struktúra és becsült ráfordítás

A csomagok közötti különbség elsősorban abban van, hogy mi kerül bele már az első szállításba, és mi marad külön követő scope-ra.

Kiválasztott csomag

Ajánlott főcsomag

Ez a jelenlegi információk alapján leginkább védhető végső ajánlat: nem csak a magplatformot tartalmazza, hanem a Judge.me migráció üzletileg fontos részeit is, így a kliens egy koherensebb, teljesebb első csomagot kap.

Magplatform

120–150 óra

Migráció

55–75 óra migrációs réteg

Kiegészítő réteg

15–25 óra add-on

Irányár

700 000 Ft

Becsült ráfordítás

190–250 óra összesen

A jelenlegi javasolt főcsomag sávja; a nyitott aggregációs döntés ezen belül még finomíthatja az összképet.

Tartalmazza

  • a teljes induló magplatform invite flow-val és moderációval
  • Judge.me export audit, rich import és legacy review mapping
  • compact trust / star blokk a jóváhagyott megjelenési pontokra

Még finomítandó pontok

  • a végső aggregációs szint: termék vagy illat / család
  • a legacy review-k első körös rollup logikája
  • az invite küldés pontos időzítése és üzleti szabályai

Mikor jó választás?

  • ha a kliens a mostani briefhez legközelebb álló, erős első verziót szeretné leszállítani külön későbbi áttervezés nélkül

Hogyan érdemes olvasni?

A fenti csomagkártyák nem soronkénti árazási táblák, hanem három eltérő szállítási csomag olvasatát mutatják meg. A kiválasztott kártya alatt mindig annak rövid, ügyféloldali összefoglalója és becsült ráfordítási képe jelenik meg.

Infrastruktúra és havi működési opciók

A projekt mögött külön app hoszting, adatbázis és Redis/session réteg áll, ezért érdemes a fejlesztési díjtól külön, átlátható havi működési opcióként kezelni az infrastruktúrát.

Az alábbi nézet azt mutatja meg, milyen managed és saját üzemeltetésű utak közül lehet választani a kívánt költségszint és működtetési teher alapján.

Havi működés

Infrastruktúra

kb. 20–40 USD / hó

A javasolt induló tartomány usage-alapú. Kampányidőszakban vagy erősebb forgalomnál kb. 30–60 USD / hó sávra emelkedhet.

Havi működés

Support / karbantartás

külön kezelve

Ajánlott külön választani az infrastruktúrától: vagy eseti óradíjas alapon, vagy könnyű havi retainerként.

Havi működés

Meghívó e-mail küldés

szolgáltatófüggő

A vásárlásalapú invite flow küldési oldala külön tranzakciós email szolgáltatót vagy meglévő CRM-folyamatot is igényelhet.

Ütemezés

Az indulás után a végső naptári terv a lezárt scope és az inputok gyorsasága alapján pontosítható.

Lehetséges indulás

A szükséges hozzáférések és a kereskedelmi jóváhagyás után.

Naptári hossz

A választott scope, a jóváhagyási ciklusok és az ügyféloldali handoff gyorsasága határozza meg.

5. Munka fázisok és ütemterv

Legkorábbi indítás: hozzáférések és kereskedelmi jóváhagyás után

5.1 Magas szintű ütemterv

FázisMit jelent?Várható időigény
Előkészítés / pontosításdöntési pontok lezárása, theme placement, fragrance_id handoff, invite szabályok és hozzáférések rendezésekb. 1–3 munkanap
Magplatform fejlesztésbackend, auth/session, eligibility, invite flow, adatmodell, TAE widget, moderáció, i18na fő fejlesztési sáv legnagyobb része
Judge.me migrációs rétegexport audit, rich import pipeline, legacy megjelenítés, compact trust blokkkülön, jelentős többlet a fő fejlesztésen felül
QA és bevezetésstaging, rollout, ellenőrzés, technikai átadáskb. 1–2 naptári hét, részben fejlesztéssel átfedésben

5.2 Részletesebb delivery lépések

LépésTartalomBecsült idő
Kickoff és scope-zárásA hozzáférések, a még nyitott döntések, a termék- és importlogika, valamint a jóváhagyási pontok lezárása.1–3 munkanap
Technikai előkészítésA rendszer alapjainak előkészítése: környezetek, adatstruktúra, jogosultsági logika és az integráció keretei.3–5 munkanap
Backend és üzleti logika fejlesztéseA szavazási logika, a vásárláshoz kötött jogosultság, az invite flow és a háttérfolyamatok felépítése.kb. 1–2 hét
Storefront megjelenítés kialakításaA termékoldali widget, a megjelenési blokkok, a fordítható feliratok és a két store-ba illeszkedő frontend réteg kialakítása.kb. 1–2 hét
Moderációs felület és merchant működésAz admin / merchant oldal alapfunkcióinak elkészítése: áttekintés, show/hide, egyszerű szabályok.3–5 munkanap
Judge.me migráció előkészítéseAz exportok áttekintése, a mezők egyeztetése, a mapping és az importstratégia véglegesítése.2–4 munkanap
Judge.me import és legacy megjelenítésAz import pipeline elkészítése, a legacy review-k betöltése és a megállapodott megjelenítési logika kialakítása.kb. 1–2 hét
Compact trust blokk és parity elemekA szükséges kisebb trust / star blokk és a jóváhagyott kiváltási elemek beépítése.2–5 munkanap
QA és finomhangolásStaging tesztelés, edge case-ek, tartalmi és működési ellenőrzések, javítások.3–7 munkanap
Élesítés és átadásRollout, végső ellenőrzés, rövid technikai átadás és működési összefoglaló.1–3 munkanap

Összefoglaló időigény: az ajánlott főcsomag esetén tipikusan kb. 6–10 naptári hét, feltéve hogy a szükséges inputok és jóváhagyások időben rendelkezésre állnak.

A naptári hossz végül a választott scope-tól, a hozzáférések gyorsaságától és a visszajelzési ciklusok tempójától függ.

Opcionális követő tételek

Olyan elemek, amelyeket célszerű külön szolgáltatásként vagy második fázisként kezelni.

Könnyű support csomag

opcionális havi retainer

Monitoring, kisebb hibakezelés és alap környezetellenőrzés külön havi szolgáltatásként.

2. fázisú dashboard és riporting

külön follow-up scope

Mélyebb moderációs szabályok, riportok, exportok vagy admin kényelmi funkciók külön második körben.

2. fázisú PDP-bővítések

külön follow-up scope

Mélyebb illat-szintű termékoldali funkciók vagy további review / trust megjelenítések második körben.

Szállítási biztosítékok

Az ajánlati logika célja, hogy a scope, a kockázat és a költség transzparens maradjon.

Fázisokra bontott ajánlat

Az alapplatform, a migráció és az add-on scope külön kezelhető, így a projekt később is védhető marad.

Staging-first bevezetés

A bevezetés ellenőrzött környezetben validálható, mielőtt éles hatása lenne.

Transzparens költséglogika

Az infrastruktúra külön kommunikálható a fejlesztési díjtól és a supporttól.

Technikai átadás

A projekt végén átadási és működtetési szempontból is használható összefoglaló készül.

Következő lépések

Az ajánlat jóváhagyásától a fejlesztés indulásáig vezető rövid út.

1

Konfiguráció jóváhagyása

A még nyitott aggregációs döntések lezárása vagy a kiválasztott ajánlati link megosztása.

2

Kereskedelmi feltételek véglegesítése

Az órasávok végleges ajánlattá, ütemezéssé és fizetési logikává alakítása.

3

Kickoff és handoff

App install, hozzáférések, `fragrance_id` inputok és a fejlesztés indítása.