Web razvoj·03.04.2026·6 min čitanja

Kako gradimo web sisteme koji podnose kampanje i skaliranje

Next.js, TypeScript i jasna arhitektura od prvog dana — zašto dobar sistem znači da ne prepisuješ kod kada klijent naraste.

Svaki projekat koji počinjemo počinje istim pitanjem: kako će ovaj sistem izgledati za godinu dana kada klijent pokrene kampanju, napravi promociju ili doda novu uslugu? Odgovor na to pitanje određuje arhitekturalne odluke od prvog dana — i to je razlika između sajta koji podnosi rast i onog koji se sruši pod pritiskom.

Zašto arhitektura dolazi pre dizajna

Većina agencija počinje od Figma fajla. Mi počinjemo od strukture podataka, ruta i granica odgovornosti između klijentskog i serverskog koda. Kad znamo kako podaci teku kroz sistem, dizajn prirodno slijedi tu logiku — i implementacija ne iznenađuje nikoga.

Next.js App Router nam daje mogućnost da precizno odredimo šta se renderuje na serveru, šta na klijentu i šta se keš-ira na CDN-u. To nije tehnički detalj — to direktno utiče na LCP, TTFB i troškove infrastrukture kada saobraćaj poraste.

Tri nivoa skalabilnosti

1. Skalabilnost sadržaja

CMS integracija mora biti planirana od starta. Nije važno da li je to Sanity, Contentful ili custom admin panel — bitno je da dodavanje novog sadržaja, kategorije ili stranice ne zahtijeva deploy. Previše sajtova koje vidimo blokira klijente na developer-dependenciju za svaku izmenu teksta.

2. Skalabilnost saobraćaja

Statičke stranice sa ISR (Incremental Static Regeneration) mogu da serviraju milione posjetilaca sa minimalnom infrastrukturom. Dinamičke rute sa server komponentama se skaliraju horizontalno. Kada klijent pokrene Google Ads kampanju i saobraćaj poraste 10x u jednom danu, sistem mora da to podnese bez intervencije.

3. Skalabilnost koda

TypeScript nije opcija — to je osnova. Bez tipova, svaki novi developer koji uđe u projekat gubi dan razumijevanja strukture. Sa tipovima, onboarding je pitanje sati, a refaktoring je siguran jer kompajler hvata greške pre deploya.

Dobar web sistem nije onaj koji izgleda dobro danas — to je onaj koji je lak za mijenjanje za 18 meseci.

Konkretno: šta radimo drugačije

  • Feature-based struktura foldera umesto layer-based (components, hooks, utils po featuri, ne globalno)
  • Environment variables audit pre svakog deploya — nikad ne guramo tajne u git
  • Lighthouse CI u GitHub Actions — PR ne može da bude mergovan ispod 95 na svim metrikama
  • Error boundaries per sekcija — greška u jednoj komponenti ne ruši cijelu stranicu
  • Preview deployovi za svaki PR — klijent može da vidi izmjenu bez znanja o git-u

Zaključak

Arhitektura je investicija koja se vraća svaki put kada dodaš feature bez straha. Nije glamurozna, nije vidljiva korisniku, ali je razlika između projekta koji raste i projekta koji se prepravlja od nule svakih godinu-dvije. Mi biramo tu investiciju od prvog dana.

Imaš projekat u glavi?

Pričajmo o tome.

Pokreni razgovor
← Svi postovi