When I started building Eurorix, the question wasn't "how do we get more clicks?" It was "how do we build something people actually trust?"
That question shaped every technical and design decision that followed.
Starting with the Stack
The foundation needed to be solid. News platforms handle a lot of content, complex relationships between articles, authors, and categories, and demand fast page loads. After evaluating options, I landed on a TypeScript-first stack:
React with TanStack Router handles the frontend. TanStack Router's file-based routing with full type safety means navigation bugs are caught at compile time. The mental overhead of managing routes drops significantly when TypeScript tells you exactly what parameters each route expects.
Hono runs the backend. It's lightweight, fast, and designed for modern JavaScript runtimes. Coming from Express, Hono feels like a natural evolution - similar patterns, better performance, cleaner middleware.
tRPC bridges frontend and backend. This was the decision that paid dividends daily. When you change an API response shape, TypeScript immediately shows every frontend component that needs updating. No more hoping your fetch calls match your server responses.
Prisma with PostgreSQL handles data. Prisma's typed queries and migrations make database work feel like writing regular TypeScript. The schema becomes documentation, and refactoring database models is no longer terrifying.
Monorepo Architecture
The project uses a Turborepo monorepo structure:
eurorix/
apps/
web/ # Frontend
server/ # Backend API
packages/
api/ # Business logic
db/ # Database schema
config/ # Shared configuration
This structure keeps concerns separated while making code sharing trivial. The api package contains business logic that both server routes and background jobs can use. The db package exports typed Prisma client and utilities. Configuration lives in one place.
Turborepo handles build orchestration. It understands the dependency graph between packages and only rebuilds what changed. Development stays fast even as the codebase grows.
The Clickbait Killer
One feature I'm particularly proud of is the Clickbait Killer. It started as an experiment: could we help readers identify manipulative headlines before they click?
The implementation analyzes headlines for common clickbait patterns:
- Curiosity gaps ("You won't believe...")
- Emotional manipulation (fear, outrage triggers)
- Exaggeration (superlatives, absolutes)
- Vague references ("This celebrity" instead of names)
- Sensationalism beyond the facts
Each pattern contributes to a score from 0-100. The breakdown helps readers understand not just whether a headline might be clickbait, but exactly which manipulation tactics it employs.
Building this required thinking carefully about the line between legitimate engagement and manipulation. A compelling headline isn't inherently bad. The goal is transparency, not restriction.
Design as Philosophy
The visual design follows what I've started calling "Calm Tech" principles:
Readability first. Typography choices prioritize comfortable reading over visual flair. Line lengths, spacing, and contrast are tuned for extended reading sessions.
No dark patterns. No infinite scroll designed to trap users. No notification pressure. No engagement tricks disguised as features.
Performance is respect. Slow pages waste reader time. The performance budget is aggressive: sub-2-second loads, 95+ Lighthouse scores. Every asset, every animation, every data fetch is questioned.
Whitespace is content. Dense layouts feel overwhelming. Generous spacing lets the content breathe and reduces cognitive load.
These principles sound obvious when stated, but implementing them requires constantly questioning patterns the industry has normalized.
Lessons Learned
A few things I'd tell myself at the start:
Type safety compounds. The initial investment in TypeScript and tRPC pays increasing dividends as the codebase grows. Refactoring confidence alone is worth it.
Start with performance budgets. It's easier to maintain fast pages than to speed up slow ones. Establish performance expectations early and treat regressions as bugs.
Question engagement patterns. Many standard features - infinite scroll, notification badges, autoplay - exist to capture attention rather than serve users. Each one deserves scrutiny.
Monorepos simplify, eventually. The initial setup has overhead, but sharing code cleanly between packages reduces duplication and drift over time.
What's Next
Eurorix continues to evolve. The roadmap includes expanded verification tools, better personalization that respects privacy, and multi-language support.
The north star remains the same: build something people trust enough to make part of their daily routine. Not through manipulation, but through genuine utility and respect for their time.
That's the bet. We'll see how it plays out.