DEV Community: Maksim Baranov

Kako vaš oglas na rsale.net dolazi do Google-a: SEO jednostavnim rečima

Maksim Baranov — Sun, 03 May 2026 11:31:01 +0000

Postavili ste oglas. Šta dalje? U idealnom slučaju pronaći će ga ne samo posetioci sajta, već i ljudi koji guglaju „prodaje se iPhone 14 Pro Beograd” ili „iznajmljivanje bicikla Novi Sad”. Da bi to funkcionisalo, nije dovoljno samo objaviti proizvod, potrebno je da ga Google razume, indeksira i prikaže u pravom trenutku.

U ovom članku, bez tehničkog žargona, objasniću šta tačno rsale.net radi za vas kako bi vaši oglasi bili pronađeni u pretrazi, i šta vi sami možete da uradite da biste dobijali više poziva i poruka.

Zašto je SEO za oglase uopšte bitan

Kada čovek želi nešto da kupi, retko ide direktno na sajt. Prvo gugla. I od toga na kojoj će se strani rezultata pojaviti vaš oglas direktno zavisi da li će ga uopšte videti. Razlika između prve i druge strane pretrage je razlika između desetina poruka i tišine.

Dobra vest: na rsale.net mi automatski radimo većinu SEO posla. Loša vest: preostalih 20% rešava sve, a tih 20% zavisi od vas.

Šta radimo za vas (čak i ako ne razmišljate o tome)

Automatski prevod na tri jezika. Vi pišete oglas na srpskom, a on se automatski pojavljuje u katalogu na ruskom i engleskom. To znači da vaš proizvod vidi tri puta više ljudi: i lokalni Srbi, i ekspati koji govore engleski, i rusofona dijaspora. Google indeksira svaku jezičku verziju zasebno, kao tri različite strane koje vode ka istom proizvodu.

Razumljive adrese strana. URL vašeg oglasa ne izgleda kao /listing/12345, već kao /listing/12345-prodajem-iphone-14-pro-odlicno-stanje. To je važno iz dva razloga: Google voli čitljive URL-ove i uzima u obzir ključne reči u njima, a čovek u rezultatima pretrage vidi smislen naslov i razume na koji link klikće.

Mapa sajta i hreflang za Google. To su tehničke stvari, ali ukratko: automatski šaljemo Google-u kompletnu listu svih vaših oglasa sa oznakom „ova strana je na srpskom, ova je na ruskom, ova na engleskom, sve govore o istom proizvodu”. Google se ne zbunjuje i prikazuje korisniku verziju na njegovom jeziku.

Strukturirani podaci o proizvodu. Svaki oglas označavamo kao Product po standardu schema.org. To znači da Google ne vidi samo tekst, već strukturiranu karticu: naziv, cenu, fotografiju, stanje (novo/polovno), dostupnost, prodavca. Zahvaljujući tome, vaš oglas u pretrazi može izgledati sa fotografijom, cenom i zvezdicama recenzija, a takav prikaz dobija 2–3 puta više klikova.

Brzina i mobilna optimizacija. Sajt radi brzo (Lighthouse Performance 95+), a i to je faktor rangiranja: Google snižava spore sajtove u rezultatima. Da se naša početna strana učitava 5 sekundi, vaši oglasi prosto ne bi stizali do vrha.

Šta zavisi od vas (i donosi pravi rezultat)

1. Naslov je polovina uspeha.

Loše: „Ajfon nov jeftino”
Dobro: „iPhone 14 Pro 256 GB Space Black, nov, garancija Apple Beograd”

Princip je jednostavan: zamislite šta čovek kuca u Google. On ne piše „ajfon nov jeftino”. On piše „iPhone 14 Pro 256” ili „iPhone 14 Pro Beograd cena”. Što tačnije vaš naslov ponavlja stvarni upit, veće su šanse da uđete u rezultate.

Šta uključiti u naslov:

Tačan model i karakteristike (boja, kapacitet memorije, godina)
Stanje (novo, polovno, kao novo)
Grad ili kvart, ako je proizvod lokalni
Brend

Šta izbegavati: emodžije, VELIKA SLOVA, „hitno!!!”, „najbolja cena!!!”. Google to ignoriše ili snižava, a kupci doživljavaju kao spam.

2. Opis za čoveka, a ne za algoritam.

Ranije je radila šema „nabacaj ključne reči i izađi u vrh”. Danas je Google pametniji, i pobeđuje onaj ko opisuje proizvod onako kako bi pravi prodavac ispričao kupcu.

Dobar opis odgovara na pitanja koja će kupac postaviti pre nego što vam piše:

Zašto prodajete?
Koliko godina/meseci u upotrebi?
Šta je u kompletu?
Postoji li račun, garancija, kutija?
Da li ste spremni na cenkanje, zamenu?
Da li je moguća dostava?

Što kupac ima manje pitanja nakon čitanja, to više poruka, i to više Google podiže vaš oglas: algoritam vidi da ljudi pročitaju do kraja i kliknu, a ne da odmah odu.

3. Fotografije su važnije nego što izgleda.

Minimum 5–7 fotografija, prva je najbolja. Slikajte pri dnevnom svetlu, na neutralnoj pozadini, bez filtera. Pokažite proizvod sa svih strana, posebno defekte ako ih ima, posebno komplet. Oglase sa jednom mutnom fotografijom algoritam snižava: niska angažovanost = niske pozicije.

Bonus: automatski generišemo umanjene verzije različitih veličina (preko sharp) i srcset, pa se vaše fotografije brzo učitavaju i na mobilnom 4G i na laptopu. To utiče na brzinu strane, a brzina utiče na rangiranje.

4. Tačna kategorija i grad.

Izbor kategorije nije formalnost. Ako prodajete bicikl i postavite ga u „Sport”, a ne u „Bicikli”, nećete se pojaviti u katalogu /category/bicikli, a to je posebna strana koju Google indeksira upravo za upit „bicikli Srbija”. Isto sa gradom: oglas u Beogradu se rangira u lokalnoj pretrazi „kupiti ... Beograd”, ali samo ako je grad eksplicitno naveden.

5. Cena prava, a ne „po dogovoru”.

Oglase bez cene ili sa cenom „1 dinar, zovite” i Google i rsale u katalogu prikazuju niže. I kupci filtriraju po ceni, pa ako je nemate, vas prosto ne vide pri sortiranju.

Zašto su tri jezika množenje, a ne sabiranje

Jednostavan primer. Recimo da prodajete dečija kolica u Novom Sadu. Na srpskoj publici konkurišete sa uslovno 50 drugih oglasa, i šansa za poruku je 1 prema 50. Ali ako se vaš oglas automatski pojavljuje na ruskom i engleskom, ulazite u tri zasebne grupe kupaca:

Srpski roditelji koji traže „dečja kolica Novi Sad”
Ekspati koji guglaju „baby stroller Novi Sad”
Rusofoni relokanti koji traže „коляска Нови-Сад”

To nije jedna publika sa prevodom, to su tri različite. Svaka sa svojim Google-om.

Kako Google uopšte „razume” vaš oglas

Kada objavite proizvod, dešava se otprilike sledeće:

Kartica ulazi u našu bazu.
AI servis prevodi naslov i opis na druga dva jezika.
URL oglasa zajedno sa tri jezičke verzije dodaje se u sitemap.xml, koji čita Google.
Na strani proizvoda ubacujemo JSON-LD oznake (@type: Product) sa cenom, stanjem, dostupnošću, prodavcem.
Google dolazi, vidi strukturiranu stranu, razume: „ovo je proizvod, nije blog, nije članak”, i stavlja u indeks proizvoda.
Nakon nekoliko dana oglas počinje da se pojavljuje u običnoj pretrazi i u Google Shopping-u.

Ovaj ciklus traje od par dana do par nedelja. Zato je nešto skupo i važno bolje prodavati sa rezervom u vremenu, a ne „moram da prodam danas”.

Čeklista savršenog oglasa na rsale

U naslovu tačan model/naziv i ključna karakteristika
Naveden grad (ili kvart Beograda, ako je u Beogradu)
Opis odgovara na 5–7 tipičnih kupčevih pitanja
Minimum 5 fotografija, prva jasna i pri dnevnom svetlu
Izabrana tačna kategorija, a ne „Razno”
Navedena prava cena
Navedeno stanje (novo / polovno / kao novo)
Popunjeni kontakt načini (poruke, dostava)

Svaka stavka košta vas 30 sekundi. Svaka preskočena stavka je minus 10–20% vidljivosti.

Česti mitovi

„Što češće osvežavam, to sam viši u rezultatima”. Delom tačno, ali osvežavanje mora biti smisleno: dodati fotografiju, ažurirati cenu, dopisati stavku u opis. Prosto „diži u vrh” dugmetom Google ne uzima u obzir, to radi samo unutar kataloga rsale.

„Plaćeno promovisanje podiže u Google-u”. Ne. Plaćeno postavljanje vas podiže u katalogu rsale, ali to Google ne vidi. Da biste bili visoko u Google-u, potrebni su naslov, opis, fotografije i vreme.

„Ako napišem više ključnih reči, biće više”. Tako je bilo 2010-ih. Sada Google za to snižava. Opis treba da se čita kao ljudski tekst, sa ključnim rečima prirodno utkanim, a ne nabacanim na gomilu.

Zaključak

SEO za oglase nije magija ni jednokratna radnja. To je zbir pravilno urađenih sitnica: tačan naslov, smislen opis, normalne fotografije, ispravna kategorija, prava cena. Tehnički deo (višejezičnost, sitemap, schema.org, brzina) preuzimamo na sebe. Ostalo ste vi i vaš proizvod.

Ako se sve uradi kako treba, u prve dve nedelje nakon objavljivanja oglas počinje da se pojavljuje u Google-u za konkretne upite, i pozivi/poruke stižu ne samo od onih koji listaju katalog, već i od onih koji su došli iz pretrage. A to je sasvim druga publika: čovek već zna šta hoće i spreman je da kupi.

Postavite oglas na rsale.net i primenite čeklistu. Ako imate pitanja o konkretnim oglasima, pišite u komentarima, razmotrićemo.

From Next.js 15 to SvelteKit: Why We Rewrote Rsale.net's Frontend

Maksim Baranov — Sun, 03 May 2026 10:25:55 +0000

Hey dev.to! Maksim here again, author of the previous article "From Idea to MVP: Building a Classified Platform in Serbia" about Rsale.net, a classified platform for Serbia. In that post I described the stack: Next.js 15 + React 19 + ASP.NET Core microservices + AI translation.

A few months later, the frontend has been fully rewritten on SvelteKit 2 + Svelte 5 (runes). The Next.js codebase is gone. In this article I'll walk through why we did it, what we gained, and where it hurt.

Project status: the backend is still being finished, the site shows test data. But the new frontend is already in production-ready shape.

TL;DR

We migrated from Next.js 15 / React 19 to SvelteKit 2 + Svelte 5 runes. Bundle size dropped, DX improved, the Server/Client Component dualism disappeared, and i18n became a 50-line file instead of a separate library. No regrets.

Why we left Next.js

Next.js 15 is a great framework. But on a real project, a classified board with three languages, ISR, SignalR chat, geolocation, image upload, a sell wizard, three pain points piled up.

1. The Server/Client Component dualism. In the previous article I called it the "Server-First + Client Wrapper" pattern. Sounds elegant on a slide. In practice every new component requires a decision: 'use client' or not? Can I import it from a server component? Why did the bundle suddenly grow by 40 kB? Why does this hook break SSR?

// Next.js 15, a typical "wrapper" because we need one onClick
'use client';
import { ServerThing } from './server-thing';
export function Wrapper({ children }) {
  return <div onClick={...}>{children}</div>;
}

In SvelteKit there is no such dichotomy. A component is just a component. SSR happens by default, hydration too, and reactivity works the same on the client and the server.

2. Bundle size and React runtime. React 19 + the Next.js runtime + next-intl + zustand + framer-motion, even with aggressive code-splitting the baseline JS for an empty page was around 99 kB. For a classified board where users open 20–30 listings in a session, that's a real cost on Serbian 4G.

Svelte is a compiler. There is no "framework runtime" shipped to the browser, only the code your components actually need.

3. RSC, caching and the "magic". fetch overrides, revalidate, unstable_cache, dynamic = 'force-dynamic', ISR with on-demand webhooks, Next.js gives a lot, but every "why isn't this updating" debugging session takes an hour. SvelteKit's model is honest and explicit: the load function, export const prerender, export const ssr, export const csr. That's it.

Why SvelteKit

Compiler instead of runtime. Svelte compiles components to plain JS that mutates the DOM directly. No virtual DOM, no reconciler, no Fiber. For a content-heavy site, that's a free performance win.

Svelte 5 + runes. Runes ($state, $derived, $effect) replaced the magic $: and stores from Svelte 4. The model is closer to Solid/MobX, explicit, debuggable, and works the same in .svelte and .svelte.ts files.

Here's our auth store. It's a regular .svelte.ts file, no writable, no providers, no useContext:

// src/lib/stores/auth.svelte.ts
let currentUser = $state<AuthUser | null>(null);

export const auth = {
  get user() { return currentUser; },
  get isAuthenticated() { return currentUser?.isAuthenticated ?? false; },
  get isAdmin() { return currentUser?.role === 'admin' }
};

export function notifyAuthChanged() {
  getChannel()?.postMessage('auth:changed');
}

Any component just imports auth and reads auth.user, reactivity is automatic. Compare with React: useContext + Provider + useSyncExternalStore for cross-tab sync.

File-based routing without [locale] everywhere. In Next.js the i18n routing scheme is app/[locale]/..., every route lives under a dynamic segment. In SvelteKit we handle locale in hooks.server.ts via cookie + Accept-Language and prefix URLs with a helper lp('/category/cars'). Route folders stay clean: routes/category/[id], not routes/[locale]/category/[id].

i18n in 50 lines instead of a library. We dropped next-intl and wrote our own thing. Three dictionaries, one t() function, runes for reactivity:

// src/lib/i18n/index.svelte.ts
export type Locale = 'sr' | 'ru' | 'en';
const allTranslations: Record<Locale, Translations> = { sr, ru, en };

let currentLocale = $state<Locale>('sr');

export function setLocale(locale: Locale) {
  currentLocale = locale;
  document.cookie = `locale=${locale}; path=/; max-age=31536000; SameSite=Lax`;
}

export function t(key: TranslationKey, params?: Record<string, string | number>): string {
  let text = allTranslations[currentLocale]?.[key] ?? allTranslations['sr'][key] ?? key;
  if (params) {
    for (const [k, v] of Object.entries(params)) {
      text = text.replace(`{${k}}`, String(v));
    }
  }
  return text;
}

That's it. No ICU MessageFormat (we don't need plural rules in this domain), no providers, no next-intl config files. Type-safety comes from TranslationKey = keyof typeof sr, TypeScript yells at any unknown key.

SSR by default, no 'use client'. Every +page.svelte is rendered on the server, gets hydrated on the client, and reactivity just works. No mental tax on whether to put 'use client' at the top.

<!-- routes/category/[id]/+page.svelte -->
<script lang="ts">
  import { t } from '$lib/i18n/index.svelte';
  import { auth } from '$lib/stores/auth.svelte';
  let { data } = $props();
</script>

<h1>{t('category.title')}</h1>
{#each data.products as product}
  <a href="/listing/{product.id}">{product.title}</a>
{/each}
{#if auth.isAuthenticated}
  <button>{t('add_favorite')}</button>
{/if}

This component runs on the server and on the client. No directives, no wrappers.

Stack: before and after

Layer	Was (Next.js 15)	Now (SvelteKit 2)
Framework	Next.js 15.4	SvelteKit 2.50
UI	React 19	Svelte 5.51 (runes)
State	Zustand	`$state` in `.svelte.ts` files
i18n	next-intl	own 50-line module
Animations	framer-motion	CSS + Svelte transitions
Bundler	Webpack/Turbopack	Vite 7
Adapter	Vercel/Node	`@sveltejs/adapter-node`
Real-time	@microsoft/signalr 9	@microsoft/signalr 10
DB layer	(REST to ASP.NET)	+ Drizzle ORM for FE-side reads
Tests	none	Vitest + Playwright

SignalR for chat stayed, it's a client library, framework-agnostic. The ASP.NET Core backend with microservices and the AI Translation Service didn't change at all, the rewrite was purely frontend.

The migration in practice

What was easy:

Routing. app/[locale]/products/[id]/page.tsx became routes/products/[id]/+page.svelte. Conceptually 1:1.
Server-side data loading. Next's async function Page() became SvelteKit's load() in +page.server.ts. Same idea, cleaner separation.
API routes. route.ts with GET/POST became +server.ts with the same exports.

Where we had to think:

ISR analog. Next had revalidate: 600. SvelteKit doesn't have ISR out of the box with adapter-node (it does with adapter-vercel if you host there). For static pages (about, terms, blog index) we use export const prerender = true, for dynamic ones plain SSR-on-demand. With proper Cache-Control headers and a CDN in front, the practical effect is the same.
Image optimization. No next/image. We use sharp at upload time + a small <img> wrapper with srcset. Less magic, more control.
Sell wizard state. Our sell wizard was a tangle of Zustand slices. Moving it to a single sell-wizard.svelte.ts with $state actually shrank the code by about 40%.

What genuinely hurt:

Smaller ecosystem. No shadcn/ui, no react-hook-form. You write more by hand. For us this was a plus, fewer black-box deps, but on a deadline-driven project it would hurt.
Svelte 5 is fresh. Some libraries (Leaflet wrappers, for instance) hadn't been updated to runes yet. We use vanilla Leaflet directly, works fine.
Ecosystem search. "How do I do X in SvelteKit" Google results often return Svelte 4 / SvelteKit 1 answers. Always check the version.

Numbers (dev environment, same machine)

Metric	Next.js 15	SvelteKit 2
Cold dev start	~8 s	~1.5 s
HMR update	300–800 ms	30–80 ms
Production build	~3 min	~25 s
Baseline JS (homepage)	~99 kB	~38 kB
Lighthouse Performance	90+	95+

The build-time numbers are the ones that changed daily life the most. vite build finishes before you alt-tab to the browser.

What stayed from the previous architecture

ASP.NET Core microservices. Untouched. The frontend rewrite didn't ripple into the backend at all, that's the upside of a clean REST contract.
AI Translation Service. Still translates listings between Serbian, Russian and English on submit.
SignalR for chat. Library is frontend-agnostic, just a different import path.
Three-language UX with Cyrillic-first Serbian. That's a market decision, not a tech one.

Would I recommend the move?

If you're starting from scratch in 2026 and your project is content-heavy with SSR/SEO requirements, try SvelteKit first. The DX is genuinely better, the bundle is smaller, the mental model is simpler.

If you have a working Next.js project that ships features, don't migrate for the sake of migrating. We rewrote because we were still in MVP, there are only two of us (me and my backend friend), and 2–3 weeks of rewriting paid for itself in faster iteration after.

If your team is large and React-shaped, the hiring market reality is real. SvelteKit devs exist but there are fewer of them.

What's next

Finishing the backend (transition from test data to real listings).
On-demand cache invalidation: ASP.NET webhook to a SvelteKit endpoint that purges CDN entries.
PWA and offline-first for mobile.
Improving AI translation with category context.

The architecture lesson from both articles is the same: boring backend, sharp frontend choices. The stack you pick on the frontend is the one users actually feel.

If you're considering the same migration, drop questions in the comments. The site lives at rsale.net, still on test data, but the SvelteKit build is what's serving it.

From Idea to MVP: Building a Classified Platform in Serbia

Maksim Baranov — Tue, 30 Dec 2025 14:37:55 +0000

Hey dev.to! My name is Maksim, and I want to share the story of building Rsale.net — a classified platform for Serbia. This is a story about technical decisions, architectural trade-offs, and the specifics of the Balkan market.

Project Status: Backend and frontend are currently under active development. The site currently displays test data to demonstrate functionality.

Why Serbia?
Serbia is an interesting market for classifieds:

7 million population with a growing e-commerce segment
Dominated by outdated platforms with 2010s-era UX
High smartphone penetration rate
Active Russian-speaking community (relocants)
We saw an opportunity to create a modern platform that combines products and services with a focus on multilingualism and geolocation.

Tech Stack: Why These Choices
Architecture: Microservices

We chose a microservices architecture with clear separation of responsibilities:

┌─────────────────────────────────────────────────────────┐
│                      Frontend                           │
│                   Next.js 15 + React 19                 │
└─────────────────────┬───────────────────────────────────┘
                      │ REST API
                      ▼
┌─────────────────────────────────────────────────────────┐
│                    API Gateway                          │
│                    ASP.NET Core                         │
└───┬─────────────┬─────────────┬─────────────┬───────────┘
    │             │             │             │
    ▼             ▼             ▼             ▼
┌────────┐  ┌──────────┐  ┌──────────┐  ┌────────────┐
│Products│  │ Services │  │   Auth   │  │Translation │
│Service │  │ Service  │  │ Service  │  │  Service   │
│        │  │          │  │  (OIDC)  │  │   (AI)     │
└────────┘  └──────────┘  └──────────┘  └────────────┘

Why microservices for an MVP? The common advice is "start with a monolith". But we had reasons:

Independent scaling — the translation service is under heavier load than others
Different teams — frontend and backend are developed in parallel
AI component isolation — Translation Service can be easily replaced or updated

Why ASP.NET Core?
Performance — one of the fastest web frameworks (TechEmpower benchmarks)
Type safety — C# catches errors at compile time
Ecosystem — Entity Framework, Identity, SignalR out of the box
Hosting — works great in Docker/Kubernetes

Frontend: Next.js 15 + React 19

// package.json
{
  "dependencies": {
    "next": "15.4.6",
    "react": "19.1.0",
    "next-intl": "^4.6.1",        // i18n
    "zustand": "^5.0.8",           // State management
    "framer-motion": "^12.23.24",  // Animations
    "@microsoft/signalr": "^9.0.6" // Real-time chat
  }
}

Why Next.js 15?

App Router — native Server Components support
ISR (Incremental Static Regeneration) — critical for classified SEO
next-intl — best integration for multilingualism

Frontend + Backend Integration
Frontend communicates with ASP.NET Core via REST API with retry logic:


// lib/server-api-service.ts

  async function fetchWithRetry<T>(endpoint: string): Promise<T> {
  const url = `${API_CONFIG.EXTERNAL_API_URL}${endpoint}`;

  for (let attempt = 1; attempt <= 3; attempt++) {
    try {
      const controller = new AbortController();
      const timeoutId = setTimeout(() => controller.abort(), 10000);

      const response = await fetch(url, {
        signal: controller.signal,
        headers: { 
          'Content-Type': 'application/json',
          'User-Agent': 'RSALE-Frontend/1.0' 
        }
      });

      clearTimeout(timeoutId);
      return await response.json();

    } catch (error) {
      if (attempt === 3) throw error;
      await new Promise(r => setTimeout(r, 1000));
    }
  }
}

ISR Architecture: The Key to SEO

For classifieds, SEO is everything. Every listing must be indexed by Google. We use different revalidation intervals:

// lib/config.ts
export const ISR_CONFIG = {
  REVALIDATE_MAIN: 300,      // Homepage: 5 min
  REVALIDATE_PRODUCTS: 600,  // Lists: 10 min  
  REVALIDATE_DETAILS: 1200,  // Product pages: 20 min
};

Server Components vs Client Components
We developed the "Server-First + Client Wrapper" pattern:

// app/[locale]/page.tsx — Server Component
export default async function HomePage({ params }) {
  const { locale } = await params;
  setRequestLocale(locale);
  return (
    <>
      {/* SEO-critical content renders on server */}
      <script type="application/ld+json" 
        dangerouslySetInnerHTML={{ 
          __html: JSON.stringify(structuredData.website()) 
        }} 
      />

      <Suspense fallback={<CategoriesSkeleton />}>
        <MainPageContent />  {/* Server Component */}
      </Suspense>
    </>
  );
}

The rule: Everything the search bot sees — server component. Interactivity (modals, forms, auth) — client components.

Three Languages: Serbian, English, Russian
Multilingualism was mandatory from day one:

// app/[locale]/products/page.tsx
export default async function ProductsPage({ params }) {
  const { locale } = await params;
  setRequestLocale(locale);

  const t = await getTranslations('navigation');

  return (
    <h1>{t('products')}</h1>  
    // ru: "Товары", sr: "Производи", en: "Products"
  );
}

Important lesson: Serbian has two alphabets — Cyrillic and Latin. We chose Cyrillic as more traditional for the older generation.

AI Translation of Listings on the Server
One of our key features — automatic listing translation using AI. When a user adds a product or service in one language, the Translation Service automatically translates the content into the other two languages:

User writes in Russian:

"Продаю iPhone 14 Pro, отличное состояние, полный комплект"
↓ AI Translation Service ↓
Serbian: "Продајем iPhone 14 Pro, одлично стање, комплетан сет"
English: "Selling iPhone 14 Pro, excellent condition, full set"

Backend implementation (ASP.NET Core):


// TranslationService.cs
public class AITranslationService : ITranslationService
{
    private readonly IAIClient _aiClient;

    public async Task<TranslatedContent> TranslateAsync(
        string title, 
        string description, 
        string sourceLang)
    {
        var targetLanguages = new[] { "ru", "sr", "en" }
            .Where(l => l != sourceLang);

        var translations = new Dictionary<string, LocalizedContent>();

        foreach (var targetLang in targetLanguages)
        {
            var translated = await _aiClient.TranslateAsync(
                new TranslationRequest
                {
                    Title = title,
                    Description = description,
                    From = sourceLang,
                    To = targetLang
                });

            translations[targetLang] = translated;
        }

        return new TranslatedContent
        {
            Original = new LocalizedContent { Title = title, Description = description },
            SourceLanguage = sourceLang,
            Translations = translations
        };
    }
}

Why this matters:

Lower barrier to entry — sellers don't think about translation
SEO in all languages — listings are indexed in three language versions
3x audience — a Russian-speaking seller reaches Serbian and English-speaking buyers

Current Development Metrics

Metric Value
Build Time (frontend)   ~3 sec
Bundle Size 99.7 kB
Lighthouse Performance  90+
SEO Score   9/10
Static Pages    72

What's Next?

We're actively working on:
Completing the backend — transitioning from test data to production
PWA — offline mode for mobile
Real-time chat — SignalR is already connected on both ends
On-Demand Revalidation — webhook from ASP.NET Core to Next.js when listings change
Improving AI translation — contextual translation based on product category

Conclusion

Building a classified platform in 2024-2025 isn't rocket science, but it requires thoughtful technical decisions:
ASP.NET Core for a reliable and fast backend
Microservices for independent scaling (especially AI translation)
Next.js 15 with ISR for SEO and performance
AI translation to remove language barriers
The project is still in development, but the architecture is already set up right — and that's what matters. If you have questions about our stack or architecture — drop them in the comments!

rsale.net - check out the demo