Most link management tools on the internet are just dumb, static URL shorteners. But in modern web development and marketing, static links are no longer enough. We need links that behave like intelligent, programmable data pipelines.
As a solopreneur, I set out to build Reulink—a production-grade SaaS platform designed to transform cold links into smart routing infrastructure.
Here is a look behind the curtain at the architecture and the 14 core engine features I engineered to solve complex traffic distribution:
The Tech Stack
Frontend: Next.js (for lightning-fast page loads and optimized rendering).
Backend & Database: Supabase (for real-time data synchronization, secure user tables, and instant query execution).
Core Engineering Features Built Into the Dashboard
I built a unified dashboard capable of orchestrating 14 specialized traffic services seamlessly:
Smart Links: Permanent URLs that can be dynamically updated at any time without changing the original link.
Dynamic QR Codes: Printable codes that allow backend destination updates on the fly, paired with granular scan tracking.
Advanced Analytics: Real-time analytics engine tracking traffic sources, devices, and operating systems.
Routing Engine: A centralized system to control the full user journey and automate behavioral redirection.
Quota Routing: Split-testing and traffic distribution by assigning exact click counts or volumetric caps to specific destinations.
Sequential Journey: Multi-destination paths where a user is dynamically routed to a brand-new page every single time they click the exact same link.
Self-Destructing Links: Temporal URLs that automatically expire and break after reaching a set expiration date or maximum click threshold.
Device Routing: Smart sniffing that automatically routes users to dedicated links depending on their OS (iOS, Android, Windows, Mac, or Desktop).
Geo Targeting: Location-based routing that detects the country or region of the visitor to display hyper-localized content.
Time-Based Routing: Automated scheduling that updates destinations based on operational hours, timezones, or seasonal windows.
Referrer Routing: Context-aware routing that segments users coming from specific platforms like Instagram, TikTok, Google, or YouTube.
Hospitality Suite: Specialized smart redirection tools tailored for managing hotel, cafe, and restaurant review flows.
Conversion Optimization: Integrated toolset built for A/B testing destinations and recording precise conversion analytics.
Team Collaboration: Multi-tenant infrastructure allowing team link-sharing, custom roles, and shared report access.
Let's Connect
Building a high-performance routing engine from scratch came with its fair share of caching and performance challenges. I would love to get your brutal engineering feedback on the architecture!
How do you optimize URL redirection latency at scale? Drop your thoughts below!
Top comments (2)
The multi-tenant piece with shared report access is what caught my eye — that is exactly where I got burned on a Supabase build of my own. I had team sharing working, roles working, everything passed my own testing, and it was only later, logged in as a second team, that I realized I could pull the first team's rows back. The policy read fine at a glance; the qual just was not scoped to the team the way I had assumed.
With 14 services all reading from the same tables, how are you drawing the tenant boundary — one set of policies at the table level, or scoping it per service? Curious how you kept that consistent across that many features.
Great question, Pon. It's a common challenge when scaling multi-tenant apps.
Rather than relying solely on individual RLS policies per service, I've implemented a layered boundary approach. I centralize the core tenant scoping logic within a dedicated service/middleware layer that acts as a gatekeeper, which then propagates the tenant context to the database queries. This keeps the policy logic DRY and ensures that the tenant ID is enforced consistently, regardless of which service is initiating the request.
It’s a bit more overhead during development, but it prevents the 'leaky' policy issues you mentioned by maintaining a strict, top-down context enforcement.