D2Metrics

Project Overview

D2Metrics is a SaaS analytics platform I built for a business that works with payment and transaction data.

The main idea was simple: instead of the team checking different platforms every day to understand revenue, transactions, chargebacks, and traffic, I built one application where they could manage and monitor everything from a single place.

I worked on the project from the ground up, including the frontend, backend, database, data synchronization, user permissions, background jobs, and deployment setup.

Bringing Everything Into One Dashboard

One of the first things I focused on was making the daily workflow easier for the team.

The dashboard brings important information such as revenue, transaction volume, card-network data, and other performance metrics together in one place.

Instead of opening multiple platforms and comparing information manually, the team can now open D2Metrics and get a much clearer picture of what's happening.

I also kept the dashboard modular, so new analytics sections could be added later without rebuilding the whole interface.

Working With Large Amounts of Data

This wasn't a simple dashboard with a few static numbers. The platform handles around 20,000 to 40,000 records per day coming from external platforms.

Because of that, I needed to think about how the data would be stored, synchronized, and displayed without making the application slow.

I used PostgreSQL for the main database and built background jobs with BullMQ for the synchronization process.

The data is processed in the background instead of making users wait for every sync to finish. The dashboard also shows when the data was last synchronized and includes a manual “Sync Now” option when the team needs an immediate update.

One Table Component Used Across The Platform

There are a lot of data-heavy sections in D2Metrics, so building a separate table for every section would have created unnecessary code and maintenance work.

I built one reusable data table component and used it across different parts of the application.

The table supports things like search, filtering by date, exporting data, and fullscreen viewing.

The same component can be used for chargebacks, products, traffic, payment routing, and other datasets.

This also made it much easier to add new modules because the basic data-handling UI was already there.

Different Users Need Different Access

Since the platform contains payment and chargeback information, giving everyone the same access wasn't an option.

I built a role and permission system where access can be controlled at the module and action level.

For example, one user might only be able to view a module, while another can edit or delete its data.

A Super Admin can also control which parts of the platform are available to different roles. This gives the client much more control than a basic admin/user permission system.

Managing Features Without Changing Code

Another part of the platform is the feature flag system.

I built an admin panel where the client can enable or disable specific features directly.

This is useful when a feature needs to be temporarily disabled or when the client wants to control when a particular module becomes available.

They don't need to contact a developer and wait for another deployment just to switch a feature on or off.

Keeping The Backend Busy, Not The User

A lot of the work in this project happens behind the scenes.

External platforms send large amounts of data into the system, which then needs to be processed and stored correctly. I handled this using background jobs with BullMQ rather than putting that workload directly on normal API requests.

The result is a better separation between the user-facing application and the heavy data-processing work happening in the background.

Backend & Database

The frontend was built with Next.js and Tailwind CSS, while the backend was developed with NestJS and Node.js.

The backend exposes REST APIs and handles the main business logic, authentication, permissions, data processing, and communication with external services.

PostgreSQL is used as the primary database because the application needs to work with structured transactional and analytics data.

I also built reusable backend services so common functionality could be shared between different modules instead of duplicating the same logic.

Deployment & CI/CD

Once the application was ready, I also handled the production setup.

The platform runs on DigitalOcean with Docker and Nginx, with SSL configured through Certbot.

I kept staging and production environments separate so new changes could be tested before being pushed to the live application.

For deployments, I configured GitHub Actions to automate the build and deployment process. This made releases more consistent and reduced the amount of manual work involved in deploying new changes.

What The Platform Includes

D2Metrics is built around the day-to-day needs of the client's operations and analytics team.

The main areas include:

• Performance dashboard
• Revenue and transaction analytics
• Chargeback analytics
• Affiliate and payment-router traffic
• Product management
• User management
• Roles and permissions
• Feature flags
• Data synchronization
• Knowledge base

Because these sections share common components and backend services, the platform can continue growing without every new module needing to be built from zero.

The Outcome

D2Metrics gave the client one central system for working with data that was previously spread across multiple platforms.

The team can now monitor important metrics from one dashboard, manage access based on user roles, control features from the admin panel, and keep large datasets synchronized automatically.

For me, the important part of this project was building more than just the visible dashboard. I handled the systems behind it as well, including the database, APIs, background jobs, permissions, deployment, and CI/CD.

That foundation gives the platform room to add more data sources and features without having to rethink the whole application every time something new is added.

Tech Stack

1. Frontend: Next.js, React, Tailwind CSS
2. Backend: NestJS, Node.js, REST APIs
3. Database: PostgreSQL
4. Background Jobs: BullMQ
5. Infrastructure: DigitalOcean, Docker, Nginx, Certbot
6. CI/CD: GitHub Actions