Two Devs Built a Multilingual Marketplace: Why They Skipped the Fancy Stuff
rsale.net's founders chose boring architecture over trendy complexity. Here's what actually matters when your team is tiny and your tech stack is real.
rsale.net's founders chose boring architecture over trendy complexity. Here's what actually matters when your team is tiny and your tech stack is real.
Two developers. One marketplace. No architectural complexity theater.
rsale.net is a classifieds platform for Serbia with AI-assisted listings, semantic search, in-platform chat, and support for five languages. One founder owns the backend (.NET). The other handles design, product management, and the entire frontend (SvelteKit). That's it. That's the team.
This is not a story about scrappy startups outrunning big companies with agility. It's a story about what happens when you cannot afford to make a mistake you have to live with.
When your team is two people, architecture is not a thought exercise. It's a maintenance contract. Every choice to use a newer framework, a more sophisticated pattern, or a trendier tool is a debt that one human will pay, indefinitely.
The rsale.net founders understood this early: fancy decisions are a tax. Not because fancy tools are bad. They are bad because they require ongoing cognitive load. When you have two people, cognitive load is your scarcest resource.
The tech stack: SvelteKit on the frontend, .NET on the backend. Both are mature, well-documented, and lean. Neither demands constant DevOps attention or architectural debates. Both let one person own an entire layer without needing a PhD in distributed systems.
If you're building a web product with a small team or running a marketplace for your industry, apply this ruthlessly: every technology decision must justify itself by reducing future maintenance burden. If it doesn't, it's a tax.
Ask yourself: does this choice get more complicated or clearer six months from now? Will one person need to understand it? Can we explain it in a meeting without a whiteboard? If the answers are no, it's too fancy.
We help small and commercial teams audit their architecture for hidden taxes. We ask: which of your technical choices actually reduce work, and which ones just feel impressive? Then we help you rebuild lean systems that scale with product, not with complexity.
If your team feels trapped by technical debt, or you're about to make a big architecture choice and want to know the real cost, that's where we start.
How WebKing runs this
WebKing helps small and commercial teams audit their tech debt and architecture choices. We show owners which 'improvements' actually slow you down, then help you build lean systems that scale without multiplying your headcount.
Sources
The Lab is original analysis by WebKing. We summarize and interpret developments from the sources above for industrial, commercial, and small business owners. Figures are reported as published by their sources.
More from the desk
A Serbian classifieds platform scaled with SvelteKit and .NET by rejecting complexity. Here's how constraint-driven design saved a skeleton team from technical debt.
A regulatory shift could give publishers control over content use and traffic routing, reshaping how search and AI work together.
One developer wired architectural checks into Claude Code and caught a "clean" patch that would have silently cascaded failures across transitive dependencies. We're explaining the guard rail that saved the codebase.