The problem

The company’s customer-facing ecommerce ordering tool needed a data platform built from the ground up—one that could answer product managers’ most pressing analytical questions across large, heterogeneous datasets while fitting into the wider enterprise architecture.

The work

I led the platform from design through delivery: laying out the architecture, choosing the right tools for the job, meeting with vendors, working with engineering architecture teams to map data interactions, running proofs of concept, and leading the team that built it.

• Designed the cloud-native big-data platform on AWS (Redshift, EMR, Athena, S3, Lambda, EC2, Firehose, Secrets Manager, and more), plus open-source Airflow and Redash.
• Integrated enterprise tooling for clickstream and customer data (Tealium CDP), experimentation (Optimizely), monitoring (Datadog), and BI (Tableau).
• Ran a proof of concept and pre-sales engagement with the SingleStore team to evaluate near-real-time reporting on streaming data.
• Led a production migration involving multi-petabyte heterogeneous data sources.
• Completed the migration without disrupting reporting.
• Later worked across engineering, product, and DevOps to plan migration of critical customer-experience resources from AWS to GCP.

The problem

Our client, a healthcare analytics SaaS company, was onboarding more customers, and its data processes were getting harder to scale. Handling sensitive healthcare data meant extensive cleaning, transformation, and validation for every new customer, plus recurring updates. The company needed a scalable way to improve efficiency without lowering its data-quality standards.

The work

The goal was a practical single source of truth and a more reproducible operating model—not governance as a documentation exercise.

Data governance. We implemented a data governance framework to standardize data and keep it consistent.

• Catalog and lineage: created a data dictionary, ERDs, and documentation templates for standardized documentation, and linked data sources to their source-code repositories for easy reference.
• Metadata and ownership: established a consistent process for creating metadata, and defined clear data ownership to improve collaboration and accountability.

Data processing. To support efficient, scalable operations, we improved the ETL processes and automated data-quality testing.

• Reusable ETL scripts and templates: modular, maintainable scripts that reduced processing times and sped up new pipeline development.
• Automated data-quality testing: testing templates and automated testing pipelines that replaced manual post-project checks, plus granular alerts for quicker issue detection.

How we ran the project

We ran the project in agile sprints, with planning and tracking in Jira. The work was scoped up front, broken into a prioritized backlog, and delivered sprint by sprint so progress stayed visible. Validation and unit testing were part of each sprint rather than a separate phase at the end.

The problem

The client wanted to identify visitors who were likely to purchase but had not yet converted. Their existing method assigned subjective weights to behaviors such as product views, list creation, and bid placement.

The work

We used historical behavior and sales outcomes to identify which signals were actually predictive.

• Prepared a year of behavioral and sales data.
• Handled missing data, outliers, correlated behaviors, and class imbalance.
• Used regression-based predictive modeling to identify meaningful behaviors.
• Compared candidate models using AIC, AUC-ROC, and confusion matrices.
• Validated the selected model against more recent data.