Core Stack

Turborepo

Convrs is organized as a Turborepo monorepo.

As the product has grown, keeping everything in a single repository has made development much easier. The marketing website, analytics dashboard, and shared packages all live together, allowing us to reuse UI components, TypeScript types, utility functions, and configuration without duplicating code.

It also makes adding new packages and services much simpler as the project continues to evolve.

Next.js

The web application is built with Next.js.

Since Convrs includes both a marketing website and a highly interactive dashboard, Next.js gives us the best of both worlds. Public pages benefit from server-side rendering and excellent SEO, while the dashboard delivers a fast, app-like experience with realtime charts, filters, and live analytics.

Keeping everything inside one Next.js application also means we only have one frontend to maintain.

TypeScript

The entire codebase is written in TypeScript.

As Convrs has grown to include APIs, ingestion services, realtime updates, and analytics pipelines, strong typing has become one of the biggest productivity wins. Catching mistakes while writing code is significantly easier than discovering them after deployment.

For a project with many moving parts, end-to-end type safety quickly becomes essential rather than optional.

pnpm

We use pnpm to manage dependencies across the monorepo.

Besides being noticeably faster than npm, pnpm uses disk space much more efficiently by sharing dependencies instead of duplicating them across projects. It also produces deterministic installs, making local development, CI, and deployments much more predictable.

Data Layer

One of the first architectural decisions I made was separating application data from analytics data.

Although both are "data," they have completely different access patterns.

Application data is highly relational. Analytics data is append-only, write-heavy, and optimized for aggregations across millions of events.

Trying to force both workloads into the same database usually leads to compromises, so Convrs keeps them separate.

PostgreSQL

PostgreSQL stores everything related to the application itself.

Users, workspaces, authentication, billing, API keys, onboarding, settings, and permissions all live here.

Relational databases excel at joins, constraints, and maintaining data integrity, making PostgreSQL the right choice for the application layer.

Tinybird

Every analytics event flows into Tinybird.

Unlike application databases, analytics databases need to continuously ingest large volumes of events while answering aggregation queries almost instantly.

Queries such as:

• Visitors over the last 30 days
• Top landing pages
• Referrers
• Devices
• Countries
• Funnels
• Conversion rates

can involve scanning millions of events. That's the kind of workload Tinybird is designed for.

Keeping analytics separate from PostgreSQL also means reporting workloads never interfere with the application itself.

Redis

Redis is primarily used for caching.

Dashboard data is requested frequently, and repeatedly running the same expensive queries would only increase latency and database load.

Caching commonly requested data allows dashboards to respond much faster while reducing unnecessary work for PostgreSQL and Tinybird.

As Convrs grows, Redis also gives us flexibility for additional use cases such as rate limiting, distributed locks, and background processing.

Realtime Infrastructure

WebSockets

One of the features I wanted from the beginning was realtime analytics.

When someone visits your website, you should see that visitor appear immediately—not after refreshing the page every few seconds.

WebSockets make that possible.

They power live visitor counts, active sessions, realtime dashboards, and the live globe, making analytics feel responsive instead of delayed.

Frontend

Tailwind CSS

I've been using Tailwind CSS for years, and it remains my first choice for building modern interfaces.

The utility-first workflow makes it easy to iterate on designs quickly while keeping styling consistent across the entire application.

For a product that changes every week, that development speed is difficult to give up.

Radix UI

Interactive components such as dialogs, dropdowns, popovers, and tooltips are built using Radix UI.

Building accessible UI components is much harder than it initially appears. Focus management, keyboard navigation, nested overlays, and screen reader support all introduce edge cases that are easy to overlook.

Radix handles those details while remaining completely unstyled, allowing us to build our own design system on top.

Visx

Charts are the heart of an analytics platform.

Instead of relying on opinionated charting libraries, Convrs uses Visx to build custom timeseries charts and funnel visualizations.

It takes a little more effort upfront, but the tradeoff is complete control over interactions, animations, tooltips, and the overall user experience.

Mapbox

The realtime visitor globe is powered by Mapbox.

It was one of those features I wanted to build from the start because it makes analytics feel much more tangible. Watching visitors appear from around the world seconds after they arrive never gets old.

Mapbox provides excellent rendering performance and smooth interactions, even as the number of active visitors grows.

External Services

Dodo Payments

Subscriptions and billing are handled through Dodo Payments.

Recurring billing involves subscriptions, invoices, taxes, upgrades, downgrades, payment failures, and customer portals. Rather than building and maintaining that infrastructure ourselves, we rely on a platform dedicated to solving those problems well.

That allows us to spend more time improving Convrs instead of maintaining billing logic.

Resend

All transactional emails are sent through Resend.

Authentication emails, verification links, password resets, and product notifications all go through a single provider with a clean developer experience and reliable delivery.

Sentry

No matter how much testing you do, production always uncovers something unexpected.

Sentry gives us visibility into client-side errors, browser-specific issues, and edge cases that are difficult to reproduce locally, helping us identify and resolve issues much faster.

Infrastructure

Cloudflare

Cloudflare sits in front of much of our infrastructure.

Every website using Convrs downloads our tracking script before sending analytics events, so keeping that script fast is critical. Cloudflare's global network helps deliver it with low latency regardless of where visitors are located.

We also use Cloudflare for DNS and DDoS protection, allowing us to keep the platform reliable without managing that infrastructure ourselves.

Render

Our event ingestion service runs separately on Render.

Separating ingestion from the main application means both services can scale independently. Large spikes in incoming events won't affect dashboard performance, allowing Convrs to remain responsive even as traffic increases.

Final Thoughts

Choosing a tech stack is always a series of tradeoffs.

Every technology in Convrs was selected because it solves a specific problem, whether that's processing large volumes of analytics events, delivering realtime updates, or making development faster and more maintainable.

As Convrs continues to grow, I'm sure parts of this stack will evolve too. But looking at where the product is today, I'd make many of these same decisions again.