I build systems that work in the real world.

The problem. Restaurants receive reviews continuously across Google, Yelp, Zomato and other platforms. Responding well means understanding the review, the brand, the location, available offers or loyalty actions, business rules, language, and what should happen next. Doing that manually does not scale.

What I built. I led the architecture and end-to-end development of Alfie, a production AI workflow that turns each incoming review into a response-ready business event. Reviews are pulled from multiple platforms through scheduled jobs, normalized, and placed onto a message queue for asynchronous processing.

Each consumer retrieves the appropriate brand context from cache. This context includes the information needed to make the response relevant to that brand, including offers, loyalty actions, business rules, calculations and other operational context.

When a review arrives in another language, Alfie can invoke a translation tool before passing the enriched review and context into the AI workflow. The foundation model generates the candidate response, but the model is not the final authority.

The generated response goes through a deep validation and guardrail layer before it can continue. This allows the AI to operate inside a controlled software system rather than simply generating free-form text.

Once validated, the response is ready for the customer's chosen workflow: it can be automated, or it can be presented to an operator who can review, edit and send it manually.

As AI makes it dramatically easier to generate application code, verification becomes an increasingly important engineering step. Writing a test is not enough: the system needs to understand the requirement, the codebase, the application and the state required to actually execute the test.

I built an AI-assisted E2E testing workflow around Playwright. A Jira or Notion ticket becomes the starting point. The system understands the requirement and codebase, uses a Playwright MCP server to explore the application, determines what state and test data are required, and identifies missing prerequisites.

If required data does not exist, the workflow guides the developer through creating the prerequisite data. Once the environment is ready, the system generates the Playwright test specification. Tests can then run daily or inside a CI/CD pipeline.

Customers needed to resolve or unresolve around 100,000 rows on average in a single API operation, directly from the product. The operation happens in front of the customer, so making the workflow feel like a hanging system was not acceptable.

The existing implementation had grown into a collection of filters and separate ticket-type implementations. The key architectural decision was to separate selection from execution.

Once filters have been evaluated and the ticket IDs are known, the IDs are materialized in Redis under a deterministic key representing the relevant account, user and filter combination.

The frontend receives that key. When the customer triggers the operation, the backend retrieves the materialized IDs and performs the resolve or unresolve operation without repeating the expensive selection work.

Restaurant feedback lived across multiple platforms including Google, Yelp, Zomato and others. I designed and built the analytics infrastructure from scratch to provide unified insights across brands, locations and individual outlets.

The system handled hundreds of restaurants, thousands of outlets and millions of records per week. I worked across ingestion, processing, storage and the application layer rather than treating analytics as a reporting-only problem.

A major part of the work was database performance. I optimized multiple analytical queries through SQL changes, indexing strategy and query planning. Queries that previously took tens of seconds or around a minute were brought down to sub-100ms execution for key workloads.

The result was an analytics system where users could explore restaurant, brand and outlet-level insights without waiting on long-running queries.

Data scientists at Walmart needed a reliable way to run and schedule production-grade Jupyter notebooks without depending on DevOps teams for every deployment.

I designed and built a deployment platform around Jupyter Notebooks, Papermill and Airflow that turned notebook execution into a self-service production workflow.

The platform was adopted across Walmart's data science team. I also trained the client team directly, helping move the system from software delivery into actual organizational adoption.

Sixth Sense was an internal observability platform spanning infrastructure, applications and databases across global teams. I worked on synthetic monitoring, database monitoring and the telemetry infrastructure behind the platform.

I built and scaled programmable synthetic monitoring in Python, owning high-level and low-level designs for user journeys and checks. Airflow orchestrated monitoring suites while the platform surfaced live pass/fail results.

I also built custom database monitoring agents that collected query-level metrics, latency patterns and failure events, pushing telemetry into Elasticsearch for visualization and investigation.

The work included collaborating with SRE, platform and application teams to define SLIs and SLOs and integrate observability into the engineering lifecycle.