We're Live

The front door is open.

Today we launched arivu.app — not just a marketing site, but a statement.

Brutalist by Design

We chose brutalist design because it mirrors how we think about bookmarking: direct, honest, and unapologetically functional.

No soft shadows whispering “trust me.” No rounded corners pretending to be friendly. Just 2px black borders, offset shadows that cast real weight, and Bebas Neue headlines that demand attention.

This aesthetic isn’t contrarian for its own sake. Brutalism strips away the visual noise that plagues most productivity tools. When you’re trying to resurface a bookmark from six months ago, you don’t need glassmorphism — you need clarity.

Sharp corners because decisions should be decisive. Bold typography because your ideas deserve presence. A color palette anchored in signal orange because the important stuff should be impossible to miss.

The Typography System

Every typeface earns its place. Bebas Neue handles the headlines — tall, condensed, uppercase, impossible to scroll past. It’s the font equivalent of someone grabbing you by the shoulders and saying “pay attention.” We use it sparingly, which is precisely what makes it effective.

DM Sans carries the body text. It’s geometric without being cold, readable at every size, and pairs with Bebas like they grew up on the same block. For labels, metadata, timestamps — anything that needs to feel systematic — we reach for IBM Plex Mono. Uppercase, widely tracked, clinical. When you see monospace, you know you’re looking at data, not prose.

This three-font system creates natural hierarchy without requiring you to think about it. Headlines announce. Body text explains. Mono labels orient. The structure is invisible until you look for it, which is exactly the point.

Why Not Just “Modern” Design?

We could have gone with the template. You know the one: Inter font, indigo gradients, rounded-2xl everything, a hero section that looks like every other SaaS landing page shipped in the last three years. It would have been faster. Cheaper. Nobody would have complained.

But Arivu is a tool for people who save and resurface knowledge — researchers, writers, analysts who live in their bookmarks. These users have seen every “modern” design trend come and go. They don’t need their tools to look trendy. They need their tools to work, and to get out of the way while doing it.

Brutalism isn’t a design trend for us. It’s a philosophy: show the structure, respect the user’s intelligence, refuse to hide behind decoration. When every element serves a purpose, the interface disappears and the content takes over.

One Domain, One Identity

We unified everything under a single domain. No more app.arivu.app sitting awkwardly beside a marketing page.

Now it’s just arivu.app — the marketing site at the root, the application seamlessly woven in at /dashboard, /bookmark, and the other routes you’d expect. One domain, one identity, one coherent experience.

The Subdomain Problem

Subdomains create friction. app.arivu.app is a cognitive tax — every time you type it, every time you share a link, every time you explain “no, the app is at app dot arivu dot app,” you’re spending mental energy that should go toward the actual work.

Worse, subdomains fragment identity. The marketing site feels like one product. The app feels like another. Users sense the seam even if they can’t articulate it. That seam whispers: “This was built by two teams who didn’t talk to each other.” We wanted the opposite: a unified surface where marketing and product blur into one coherent experience.

How It Works

When you visit arivu.app, you land on the marketing site. Clean Hugo-generated pages, fast and static. Click “Dashboard” and you’re in the React app — same domain, same visual language, same feeling. The transition is seamless because there is no transition. You’re never leaving arivu.app; you’re just going deeper.

This matters for sharing too. A bookmark link is arivu.app/bookmark/xyz, not app.arivu.app/bookmark/xyz. Cleaner URLs. Easier to remember. Easier to trust when someone pastes it in Slack.

Technical Implications

Single-domain architecture meant rethinking cookies, CORS, and authentication flows. Access tokens set at the root domain work everywhere. No cross-origin headaches. No weird third-party cookie warnings. Just straightforward session management that works the way sessions should have always worked.

Simple Architecture

The architecture underneath is deliberately simple.

Hugo generates the marketing pages — fast, static, cacheable. Nginx sits in front, routing requests to either Hugo’s output or the React app based on the path.

No edge functions. No build-time magic. Just a reverse proxy doing what reverse proxies do well: making complexity invisible to the people who visit.

The app lives behind the site. The story lives on it.

Why Hugo for Marketing

Static site generators are boring technology, and boring technology is reliable technology. Hugo compiles the entire marketing site in under a second. The output is plain HTML, CSS, and a sprinkle of JavaScript — files that can be cached aggressively, served from anywhere, and understood by any browser built in the last twenty years.

We considered using the React app for everything. Single codebase, unified deployment, developer convenience. But marketing pages don’t need React’s interactivity. They need to load fast and rank well. Hugo delivers both without the bundle size tax of a JavaScript framework.

The marketing site builds to static files. The React app builds to static files with client-side routing. Nginx serves both from the same origin, choosing which bundle to return based on the URL path. Marketing routes get Hugo output. App routes get the React SPA. Same server, same domain, different tools for different jobs.

The Nginx Configuration

Nginx does surprisingly little, which is exactly right. It listens on port 80, terminates TLS, and routes requests. Marketing paths (/, /about, /features, /blog, /chronicle) serve static HTML from Hugo’s public directory. App paths (/dashboard, /bookmark, /settings, /auth) serve the React app’s index.html with HTML5 history mode fallback.

The API lives at /api/*, proxied to the FastAPI backend. Cookie headers flow through correctly. CORS isn’t a problem because everything shares the same origin. The configuration file is about 60 lines. We can read it, understand it, and debug it at 2 AM if something breaks.

No Serverless, No Edge

We could have deployed to Vercel, Netlify, or Cloudflare Pages. Edge functions, automatic scaling, globally distributed CDN. It would have been slick. It also would have added abstraction layers that make debugging harder and vendor lock-in inevitable.

Instead, we run on a single VPS. Docker Compose orchestrates the containers: nginx, the React frontend, the FastAPI backend, MongoDB. When something goes wrong, we SSH in and look at logs. When we need to scale, we upgrade the droplet or add a load balancer. The architecture fits in our heads, which means we can fix it under pressure.

Other Changes

• Analytics from day one — Google Analytics for the broad picture, OneDollarStats for privacy-respecting basics. We want to understand how people discover Arivu without building a surveillance apparatus.
• Domain migration — Consolidated from app.arivu.app to arivu.app. Simpler URLs, simpler mental model, fewer SSL certificates to manage.
• Nginx reverse proxy — React app routes and static assets now flow through the same nginx instance as the marketing site. One entry point, seamless routing between Hugo and the SPA.

Welcome to Arivu.