← Back to projects

Work Experience | Full-stack Software Engineer | Oct 2021 - Present

Popsixle

Attribution and Event Processing Platform

$2.0M+

Revenue Generated

SaaS usage and subscription billing since launch.

2M+

Events Processed / Day

Server-side event ingestion and attribution workloads.

200+

Customers Supported

Production usage across customer organizations.

Overview

At Popsixle, I built and launched a production platform across frontend, backend, data processing, and AWS infrastructure.

The product launched in February 2024 and has generated more than $2.0 million in revenue through SaaS usage and subscription billing.

I designed low-latency event ingestion and conversion processing systems supporting Meta, TikTok, and Google integrations.

I also use AI-agent workflows daily in Popsixle development for implementation, debugging, and faster iteration with strong human review.

Highlights

  • - Launched a production SaaS platform used by 200+ businesses.
  • - Processes more than 2 million events per day through resilient server-side pipelines.
  • - Built and operated Popsixle on AWS services including EC2, RDS, S3, Lightsail, and Route 53.
  • - Used AI agents daily to accelerate implementation and debugging while maintaining code quality standards.
  • - Built high-throughput ingestion and delivery workflows for multi-destination integrations.
  • - Partnered with product and client teams to ship revenue-impacting features quickly.

Technologies

  • TypeScript
  • React
  • Next.js
  • Node.js
  • PHP
  • MySQL
  • AWS RDS
  • AWS EC2
  • AWS S3
  • AWS Lightsail
  • AWS Route 53
  • Shopify APIs

Links

Live Project

Case Studies

Distributed Event Reliability Pipeline

Built a queue-backed event processing pipeline that improved reliability and data integrity across multi-channel conversion delivery.

Problem

  • - Event ingestion had to stay fast while preserving payload integrity.
  • - Destination fanout had to support different channel requirements.
  • - Duplicate purchase events needed suppression before downstream delivery.
  • - Teams needed clear operational state for queued, sent, and skipped events.

Architecture

  • - Persist-before-dispatch queue model for replay safety and auditing.
  • - Dual browser/server delivery status tracking per destination.
  • - Low-latency webhook acknowledgment with deferred heavy processing.
  • - Dedupe checks keyed by account, event type, and order identifiers.

Outcomes

  • - Improved delivery reliability under partial-failure conditions.
  • - Reduced duplicate conversion risk through explicit existence checks.
  • - Increased operational confidence via status and response metadata.

Progressive Delivery and Safe Routing

Designed a server-side canary/stable routing framework for safer major runtime rollouts without breaking public endpoint contracts.

Problem

  • - Public endpoints had to remain stable during major runtime evolution.
  • - Requests arrived with inconsistent identifiers and varying context quality.
  • - Routing failures needed safe fallback behavior to prevent customer impact.

Architecture

  • - Deterministic context detection across query, payload, and header signals.
  • - Multi-source channel decision order: metadata override, DB channel, stable default.
  • - Server-side routing shim preserving existing URLs while selecting app roots.
  • - Stable-by-default exception handling for ambiguous or incomplete requests.

Outcomes

  • - Enabled controlled canary rollout with reduced blast radius.
  • - Preserved backward compatibility for existing integrations.
  • - Improved release safety with deterministic fallback behavior.