Trampa: kako smo izgradili landing page i marketplace za razmjenu

Trampa je platforma FIN STUDIO-a za razmjenu predmeta bez novca; javna stranica trampa.app zasad prikazuje listu čekanja i najavljuje lansiranje „uskoro”, bez datuma (provjereno 6. 11. 2026.). Iza te stranice stoji izgrađena platforma s oglasima, prijedlozima razmjene, razgovorom uz svaku razmjenu, bodovima i ocjenama. Riječ je o našem vlastitom proizvodu, pa o njemu pišemo prema kodu.

Ovaj tekst opisuje odluke iza landing pagea i marketplacea prema stanju koda od 26. 10. 2026., uključujući ono što se pred lansiranje promijenilo. Isti obrasci ponavljaju se u commerce projektima: podaci koji od prvog dana žive u vlastitoj bazi, transakcija s više strana i povjerenje koje se gradi ocjenama nakon stvarnog posla.

Ukratko

• Landing page ima jedan cilj: u nekoliko sekundi objasniti razmjenu bez novca i skupiti prijave za listu čekanja.
• Lista čekanja živi u bazi platforme, s jedinstvenim ograničenjem na adresi i pravilom koje javnom ključu dopušta samo upis.
• Jezgra marketplacea je stanje razmjene: svaka razmjena ima jedno od pet stanja, od prijedloga na čekanju do razmjene koju su obje strane potvrdile.
• Bodove dodjeljuje samo baza, u vlastitim funkcijama i okidačima; aplikacija ih samo čita, pa ih korisnik ne može sam sebi upisati.
• Isti obrasci vrijede za commerce: B2B ponude s odobravanjem i marketplaceovi s više prodavatelja traže istu logiku stanja i reputacije.

Faza 1: landing page koji prodaje ideju

Razmjena stvari nije uobičajen način kupnje. Posjetitelj koji prvi put dođe na stranicu pita se kako to funkcionira i što zapravo može dobiti. Landing page zato mora odgovoriti na to pitanje odmah, prije nego što posjetitelj odustane, i tek onda tražiti adresu e-pošte.

Stranica je sastavljena od nekoliko dijelova s jasnom ulogom:

• Uvodni dio s prikazom aplikacije na mobitelu i jednim pozivom na akciju: prijava na listu čekanja.
• Animacije pri pomicanju stranice preko IntersectionObservera, bez teške biblioteke za animacije, kako ne bi usporavale prvo učitavanje.
• Mobilni izbornik koji se otvara preko cijele širine bez vodoravnog pomicanja stranice.
• Pravne stranice, politika privatnosti i uvjeti korištenja, već u fazi liste čekanja, jer se i tada prikupljaju osobni podaci.
• Strukturirani podaci (WebSite, Organization i FAQPage), s poljem creator na WebSite čvoru koje stranicu povezuje s FIN STUDIO-om.

Dizajn je kretao od mobitela. Za takvu stranicu mobitel je glavni uređaj.

Lista čekanja u vlastitoj bazi

Najvažnija tehnička odluka prve faze bila je gdje žive prijave. Umjesto vanjskog alata za newsletter, prijave od prve verzije idu u vlastitu PostgreSQL tablicu s jedinstvenom adresom. Prva verzija iz srpnja 2025. pisala je preko Prisme; od 25. 6. 2026. jedna serverska ruta upisuje adresu izravno u bazu platforme na Supabaseu, bez ORM-a, pa su adrese u istoj bazi u kojoj su i korisnički računi.

Običan INSERT i jedinstveno ograničenje

Na stupcu s adresom stoji jedinstveno ograničenje, a prijava je običan upis. Kad se ista adresa prijavi drugi put, PostgreSQL odbija upis s kodom pogreške 23505 (unique_violation). Ruta koja prima obrazac taj kod prepoznaje i umjesto pogreške vraća poruku da je adresa već prijavljena. Ponovljena prijava ne šalje novu poruku e-pošte. Pojednostavljeno:

-- jednom, pri izradi tablice
ALTER TABLE waitlist ADD CONSTRAINT waitlist_email_key UNIQUE (email);

-- svaka prijava
INSERT INTO waitlist (email) VALUES ($1);
-- ponovljena adresa: pogreška 23505, ruta odgovara „već prijavljeno”

Alternativa je INSERT … ON CONFLICT DO NOTHING, koji ponovljenu prijavu tiho preskoči. To je kraće, ali ruta tada ne dobiva pogrešku po kojoj bi prepoznala ponovljenu prijavu. Ni RETURNING ni navedeni stupac, ON CONFLICT (email), ovdje ne pomažu: prema dokumentaciji PostgreSQL-a tada redak mora proći i pravila za čitanje, a ova tablica takvo pravilo namjerno nema. Zato smo za listu čekanja odabrali varijantu s pogreškom: ruta razlikuje novu i ponovljenu prijavu i ne šalje drugu poruku dobrodošlice.

Javni ključ smije samo upisati adresu

Ruta koja prima obrazac upisuje adresu javnim ključem (u ovom projektu još stari anon ključ), koji je u Supabaseu namijenjen kodu u pregledniku i ne smatra se tajnom. Zato tablica ima uključen Row Level Security s jednim pravilom: javni ključ smije dodati redak, a nema pravila za čitanje, izmjenu ni brisanje. Pojednostavljeno:

ALTER TABLE waitlist ENABLE ROW LEVEL SECURITY;
CREATE POLICY waitlist_insert ON waitlist
  FOR INSERT TO anon, authenticated WITH CHECK (true);

Za broj prijava postoji zasebna funkcija u bazi koja vraća samo taj broj, nikad adrese. Da se broj čitao izravno iz tablice, tablica bi trebala pravilo za čitanje, a s njim bi svatko s javnim ključem mogao preuzeti cijeli popis.

Poruka nakon prijave i privola

Nakon prijave korisnik dobiva poruku zahvale s adresom za odjavu u zaglavlju List-Unsubscribe, a uz adresu se sprema i vrijeme prijave. Politika privatnosti adresu s liste namjenjuje isključivo obavijesti o lansiranju. To je važno zbog privole: Zakon o elektroničkim komunikacijama (NN 76/22, 14/24, 45/26), članak 50., dopušta izravnu promidžbu e-poštom samo uz prethodno pribavljenu privolu. Za pravne osobe to pravilo ne vrijedi (stavak 4.). Druga iznimka, iz stavka 2., odnosi se na vlastite slične proizvode i adrese pribavljene od vlastitih potrošača u svrhu prodaje. Sud EU je u predmetu C-654/23, tumačeći članak 13. stavak 2. Direktive 2002/58/EZ koji ta iznimka prenosi, u to ubrojio i besplatan račun na platformi koja nudi i plaćeni sadržaj, ali nije odlučivao o listi čekanja. Prijava na Trampinu listu ne otvara račun i ne daje pristup usluzi prije lansiranja, pa se na tu iznimku ne oslanjamo. Kako to postaviti na webshopu, razlažemo u tekstu o newsletteru i privoli.

Faza 2: marketplace u kojem je jezgra stanje razmjene

U webshopu kupac prihvaća cijenu i plaća. U razmjeni se dvije strane dogovaraju, pa je jezgra sustava stanje razmjene: tko je što ponudio, što je prihvaćeno i je li se primopredaja stvarno dogodila.

Pet stanja razmjene

Svaka razmjena u bazi ima jedno od pet stanja, a dopuštene vrijednosti čuva ograničenje na samoj tablici:

• Na čekanju: korisnik je za tuđi predmet ponudio svoj ili je vlasniku oglasa poslao poruku s ponudom.
• Prihvaćena: primatelj je prijedlog prihvatio, a strane se dogovaraju u razgovoru vezanom uz tu razmjenu.
• Odbijena ili otkazana: razmjena se zatvara bez završene primopredaje.
• Završena: obje strane potvrdile su primopredaju.

Poruke se spremaju uz razmjenu, pa dogovor ostaje uz transakciju na koju se odnosi.

Potvrda primopredaje i bonus za istu lokaciju

Kad se korisnici nađu, svaki potvrđuje primopredaju. Tek kad potvrde obje strane, razmjena postaje završena i svaka strana dobiva 100 bodova. Ako su obje potvrde poslane s lokacija udaljenih najviše jedan kilometar, svaka dobiva još 25 bodova kao bonus za razmjenu potvrđenu na istoj lokaciji. Razmjena se može završiti i kad GPS nije dostupan ili je netočan. Iznimka je administratorska konzola, koja prihvaćenu razmjenu može završiti u ime obiju strana; tada nema bonusa za lokaciju.

Tri zaštite sprječavaju napuhavanje bodova: bodovi za završenu razmjenu dodjeljuju se istom paru korisnika najviše jednom u 30 dana, svaki korisnik bodove dobiva za najviše 10 razmjena u 7 dana, a sve bodove upisuju isključivo funkcije i okidači u bazi. Aplikacija bodove samo čita.

Bodovi, rangovi i ocjene

Nakon primopredaje strane se međusobno ocjenjuju ocjenom od 1 do 5. Ocjenu može dati samo sudionik razmjene, jednom po razmjeni, a baza to provjerava istim pravilima kao i aplikacija. Ako je korisnik za tu razmjenu dobio bodove za završetak, primljena ocjena donosi mu 10 bodova, a ocjena 5/5 još 50. Bodovi vode kroz šest rangova: Početnik, Cjenkač (500 bodova), Posrednik (1.000), Trgovac (2.500), Kolekcionar (5.000) i Tramper (10.000). Uz to postoje ljestvica po bodovima i izazovi u kojima korisnik bilježi niz razmjena prema cilju koji je sam opisao.

Oglasi, pretraga i karta

Slike oglasa spremaju se u vlastitu pohranu platforme na Supabaseu, do 5 MB po slici, a neiskorištene fotografije periodički se brišu. Oglasi se mogu filtrirati po udaljenosti od odabranog mjesta ili korisnikove lokacije i pregledati na karti (Leaflet s OpenStreetMap kartama). Uz to dolaze favoriti, praćenje korisnika i spremljene pretrage.

Korisnička prijava ide preko Supabase Autha, sa sesijom koju provjerava server, a pravila pristupa podacima zapisana su u samoj bazi. Stack je TypeScript, Next.js i PostgreSQL na Supabaseu, uz Zod za provjeru ulaznih podataka; kad takav stack ima smisla za commerce, a kad nema, opisujemo u tekstu o headless e-commerceu. Pregled projekta je u studiji slučaja Trampe.

Što se pred lansiranje promijenilo

Prototip se mijenjao dok se pripremao za javnost, a opis funkcija mora pratiti kod. U odnosu na ranije verzije ovog teksta, u kodu od 26. 10. 2026. vrijedi sljedeće:

• Lokacija donosi bonus. Ranije je verifikacija tražila obje potvrde unutar 500 metara; sada se razmjena završava potvrdama obiju strana, a potvrde unutar jednog kilometra donose dodatnih 25 bodova.
• Peto stanje. Završena razmjena ima vlastito stanje i vrijeme završetka, pa se ne izvodi iz drugih polja.
• Slike u vlastitoj pohrani, umjesto u vanjskom servisu za slike.
• Bez nekih ranijih funkcija. Automatske procjene vrijednosti predmeta i ocjene kvalitete oglasa u kodu više nema, a spremljene pretrage nemaju obavijesti e-poštom.

Što iz Trampe vrijedi za commerce projekte

Marketplace za razmjenu izgleda daleko od webshopa, ali tri obrasca iz njega stalno se vraćaju u commerce sustavima:

• Transakcija kao stanje, ne kao gumb. B2B narudžba koja čeka odobrenje, ponuda koja ide naprijed-natrag između prodaje i kupca ili povrat koji prolazi više koraka imaju istu strukturu kao prijedlog razmjene koji druga strana prihvaća ili odbija. Kako to izgleda u prodaji tvrtkama, opisujemo na stranici B2B webshop.
• Povjerenje iz stvarnih transakcija. Ocjena koju može dati samo sudionik stvarnog posla vrijedi više od otvorenog obrasca za recenzije. Što propisi traže od recenzija na webshopu, razlažemo u tekstu o lažnim recenzijama.
• Pravila zapisana u bazi. Dopuštena stanja, tko smije čitati podatke i tko dodjeljuje bodove ili popuste zapisani su u bazi, pa ih ne može zaobići ni pogreška u sučelju ni zahtjev poslan mimo njega.

Performanse planiramo kao budžet: LCP do 2,5 s, INP do 200 ms i CLS do 0,1 na mobitelu, mjereno na 75. percentilu učitavanja kako preporučuje Google, s animacijama koje ne smiju blokirati prvo učitavanje.

Gradite marketplace ili multi-vendor commerce?

Više prodavatelja, obračun prema vašim pravilima, reputacija i narudžbe podijeljene po prodavatelju spadaju u sustave koje gradimo od prazne stranice. Marketplace s katalozima drugih prodavatelja vodimo kao Enterprise projekt, a kako planiramo Enterprise projekte, opisujemo na stranici enterprise e-commerce. Razgovarate izravno s osobom koja projektira i gradi sustav. Opišite proces ili pošaljite postojeću arhitekturu i javit ćemo se unutar 24 sata radnim danom.