Look at our portfolio and you'll spot four apps that are obviously siblings: Rutiera: Legi & Amenzi (traffic law), Mediu: Legi & Amenzi (environmental law), Alegeri: Legi & Amenzi (electoral law), and Ordine Publica: Legi & Amenzi (public order law). Same name pattern, same visual identity, same core interaction model — search a law, read the article, see the fine attached to it. The only thing that changes between them is which body of Romanian law each one covers.
That's not four separate product ideas. It's one idea, templated across four niches — and it's one of the more deliberate strategic decisions in how we've built out this studio.
The idea that started it
The first app in the series solved a narrow, concrete problem: Romanian traffic law and its associated fines are spread across dense legal text that's hard to search and easy to misquote. Wrapping that in a fast, searchable, offline-friendly app with the actual fine amounts attached to each article turned out to be exactly what a specific, motivated audience was looking for — people who'd gotten a fine and wanted to know, in the moment, if it was correct.
Once that app proved the format worked, the obvious question was: what other bodies of law follow the same shape? Environmental regulations, electoral law, public order — all dense, all poorly served by search, all with fines attached to specific articles. Same underlying problem, different subject matter.
What actually gets reused
The template isn't just visual. What carries over from app to app is the expensive part of the engineering — search indexing over legal text, offline storage so the content works without a connection, a content update mechanism for when laws change, bookmarking and history, and an interface that's already been through several rounds of real-user feedback on how people actually want to read legal text on a phone. Building app number two isn't starting from zero; it's swapping in a new legal corpus and adjusting the parts specific to that domain.
That's the actual economics of the strategy: the marginal cost of covering a new legal domain drops sharply after the first app, because the hard problems — search, offline access, content maintenance — are already solved.
Why one big app doesn't win here
The tempting alternative is obvious: why not build one "Romanian Law Reference" app that covers all four domains, or more? A few reasons we didn't:
- Search intent is narrow. Someone who just got a traffic fine searches "rutiera legi amenzi," not "romanian law reference app." A focused app with a matching name and listing converts that specific search far better than a broad one competing for a vaguer, more contested query.
- Each domain has a different update cadence. Traffic law and electoral law don't change on the same schedule or from the same sources. Bundling them into one app means every content update touches a monolith instead of a scoped, independently shippable app.
- Risk gets distributed. If one domain's content maintenance falls behind, or interest in one topic fades, it doesn't drag down a single app's rating or relevance. Each one lives or dies on its own.
Where this approach has limits
Templating only works while the underlying problem shape stays the same. If a new domain needed a genuinely different interaction model — say, something that needed step-by-step guidance instead of reference lookup — forcing it into the same shell would produce a worse app than building it properly from scratch. The template is a starting point for domains that fit the pattern, not a mandate to fit every idea into it.
The lesson generalizes past legal reference apps: once you've solved a genuine problem well once, look honestly at whether the same shape of problem shows up in adjacent niches before assuming the next idea needs to start from a blank canvas.