Self-Service AdTech Platform
Building and evolving a self-service advertising platform for small merchants — from the guided React experience and Node.js APIs to payments, Redis-backed workflow orchestration, enterprise campaign integrations, analytics, and production operations.
Full-Stack Engineer → Team Lead · Core Product Ownership
Merchant UX · React · Node.js · MongoDB · Redis · Payments · Enterprise APIs · Analytics · Production Operations
~20,000 Advertisers at Peak Scale
Shipped to production · Revenue-generating product
From full-stack implementation to production ownership and team leadership.
I worked on this product across a substantial part of its lifecycle — from core product development through production launch, stabilization, analytics, monetization, operational tooling, and later team leadership.
My hands-on scope crossed the merchant-facing React application, Node.js backend services, MongoDB data models, Redis-backed background processing, payment and webhook flows, enterprise campaign integrations, admin tooling, analytics, and production support.
This was not a narrow feature assignment. It was long-running ownership of a production product where product UX, backend orchestration, failure recovery, operations, and business outcomes were connected.
The existing system was built for agencies — not small merchants.
The company already possessed a powerful enterprise advertising engine. But using it required deep domain knowledge: placements, audience demographics, impression targets, creatives, complex billing plans, and fulfilment pipelines.
That complexity worked for professional media agencies. It was completely overwhelming for a small merchant who simply wanted to reach nearby customers.
Hide the complexity of the advertising engine.
The challenge was not to rebuild the enterprise advertising engine. It was to create a translation and orchestration layer that hid its complexity behind a much simpler merchant-facing workflow.
“Allow a small business to launch a real advertising campaign without needing to understand how the underlying advertising platform worked.”
Simplifying the advertiser journey
I worked across the implementation of the guided merchant journey that translated a complex enterprise media configuration process into six understandable product steps:
Authenticate
Instant onboarding and account provisioning with secure session management.
Provide business information
Business details entered manually or retrieved automatically through a live GST API integration.
Choose a target location
The merchant intuitively selects target geographic zones where they want their campaign active.
Understand expected reach
The system dynamically computes and presents forecasted impression volumes based on geometry and budget.
Choose plan & creative template
Pre-approved creative templates and transparent pricing plans eliminate ad spec confusion.
Complete payment & launch or schedule
Direct online checkout. The campaign can launch immediately or wait in pending state for a future scheduled date.
Payment was only the beginning of fulfilment
From the merchant's perspective: Pay → Campaign launches.
Internally, a multi-system orchestration had to succeed across disparate enterprise services:
Payment succeeds, campaign creation fails
The customer has already paid. Asking them to retry checkout would cause double-billing. The backend must record payment and autonomously retry campaign creation.
Campaign created, creative creation fails
A campaign entity exists in the enterprise system, but the ad creative failed. Blindly repeating the entire workflow creates duplicate ghost campaigns.
Downstream enterprise API timeout
A timeout creates uncertainty, not guaranteed failure. The enterprise system may have processed the ad even if our application didn't receive the response.
Application node crashes midway
If an application instance stops mid-orchestration, persisted intermediate state allows processing to resume from the last known workflow stage instead of restarting successful steps.
Distributed job processing with Redis & atomic queue pops
Background campaign processing needed to run safely across multiple application instances without allowing every instance to execute the same scheduled work. I worked on the Redis-backed coordination pattern used to distribute and claim campaign jobs:
┌──────────────────────────┐
│ Designated Cron Node │ (Queries MongoDB for eligible jobs)
└─────────────┬────────────┘
│
Inserts jobs into queue
│
▼
┌──────────────┐
│ Redis Queue │
└──────┬───────┘
│
Publishes work signal
│
┌────────────────┼────────────────┐
▼ ▼ ▼
Node Instance Node Instance Node Instance
│ │ │
└─────── Atomic Queue Pop ────────┘
(First to pop claims work)Redis Pub/Sub (Signalling)
Tells application instances: “Work is available right now.”
Redis List (Work Ownership)
Atomic pop ensures only one instance claims and executes a specific campaign job.
Operational platform & dual-funnel analytics
Production systems require internal tooling to understand and repair state without requiring engineers to touch raw databases:
I built internal operational dashboards for managing plans, ad placements, creative templates, monitoring pending campaigns, and triggering controlled recovery for edge cases.
This gave operations teams direct visibility into campaign state and recovery actions instead of relying on engineers to inspect or modify raw database records.
I worked on analytics across two different questions: the Product Funnel (acquisition, configuration, and payment conversion through GA/GTM) and the Operational Funnel (payment validated → campaign created → ad associated → fulfilled through application data and MongoDB pipelines).
Treating checkout conversion and successful campaign fulfilment as separate funnels made product performance and operational reliability easier to reason about independently.
Key engineering lessons from years of production
Payment does not equal fulfilment
Checkout completion is only one state transition. When money is involved, the system needs explicit downstream fulfilment state, retry behavior, and recovery paths.
Long workflows must expose state
Hiding multi-system asynchronous processes behind a single boolean makes recovery impossible. Explicit intermediate states make retries predictable.
Timeouts mean uncertainty, not failure
A network timeout leaves downstream state ambiguous. Recovery logic must distinguish safe retries from operations that may already have succeeded downstream.
Retries should resume, not restart
If 3 stages succeeded and stage 4 failed, the worker must restart at stage 4 rather than repeating completed enterprise API calls.
Operational tooling is core architecture
Admin dashboards, failure visibility, and reconciliation jobs cannot be afterthought side-features when managing live revenue workflows.
The abstraction is the product
Translating between complex enterprise ad parameters and simple merchant business questions was the true value of the software.
“The difficult part of a distributed workflow isn't making every step succeed. It's designing the system so that when one step doesn't, you still know what happened — and what should happen next.”
The platform grew to serve ~20,000 advertisers and became a revenue-generating production product. Working on it across multiple stages — build, launch, stabilization, analytics, operations, and team leadership — shaped how I think about distributed workflows and production ownership.
Building complex enterprise workflows or distributed systems?
I bring this experience to complex product and platform work involving enterprise integrations, asynchronous workflow orchestration, payment reliability, operational tooling, and production ownership.