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.
Two developers. One marketplace. Rsale.net, a Serbian classifieds platform with AI listings, semantic search, chat, and five languages. No bloated engineering team. No technical committee. Just two people who understood that every fancy architectural decision is a bill one of them pays forever.
The source is from a developer on the project who runs everything outside the backend: design, product, and the entire frontend on SvelteKit. His cofounder owns the .NET backend. That's the team. That's the constraint.
Most businesses don't hire McKinsey to tell them to overcomplicate their tech stack. They do it naturally. A developer reads about microservices, containerization, event-driven architecture, or the latest frontend framework. It sounds good. It gets implemented. Then someone (usually the same person, always) has to maintain it forever while the business grows and priorities shift.
The rsale.net team rejected this entirely. They made boring decisions. Probably unglamorous ones. But boring decisions kept them shipping instead of refactoring. Boring decisions meant one backend engineer could own the API without architectural debt. Boring decisions meant the frontend engineer could iterate on design and product instead of fighting their framework.
If you're running a small team, a manufacturing operation with limited IT staff, or a commercial enterprise where tech is a cost center not a product, ask this one question before adopting any new technology: Can one person own this forever? Not 'is this trendy.' Not 'did a senior engineer at a startup use this.' Can my actual person maintain this when priorities change, when the person who originally built it leaves, when you're in crisis mode?
The rsale.net team answered yes to that question for every choice they made. Stack, database, frontend framework, deployment pipeline. And it worked. They shipped a marketplace that competes on features, not engineering flex.
You don't read case studies about the team that chose PostgreSQL instead of a shiny NoSQL database. You don't hear applause for picking the framework that's been stable for five years instead of the one with stars on GitHub. But that's exactly where small and medium teams win. That's exactly where rsale.net, two developers deep, built something that works.
Architecture theater is a luxury of large teams with rotation cycles and engineering blogs. If you have two people, you're buying your own infinity gauntlet. Treat it like it.
How WebKing runs this
We help small and industrial businesses audit their tech decisions the same way: not 'is this cutting-edge,' but 'can our two engineers actually maintain this forever?' We spot unnecessary complexity that bloats your team's workload and replace it with simple, scalable alternatives.
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
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.
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.
