Selected work,
in detail.

Simulated period used to pressure-test the framework end-to-end, from issue capture to verified closure.

Created for Tesla-relevant interview and portfolio preparation - not an official Tesla assignment. During a production ramp, issues appear faster than teams can fully investigate them. A local equipment stop can quickly become a quality, material, or output risk. The core problem is often not issue detection; it is unclear ownership, slow escalation, inconsistent priority rules, and weak closure evidence.

Nine categories classify recurring factory issues in the modelled 142-issue population, ranked by volume in the issue log:

A closed-loop operating model for detecting, escalating, resolving, and preventing manufacturing bottlenecks across seven lifecycle stages. The system separates immediate containment from permanent correction - an issue is closed only after effectiveness is verified.

Decision layer - the five control surfaces that make the loop operable day-to-day:

The dashboard is designed as an operations control page. It combines current issue load, production impact, escalation tier, responsible function, ageing, resolution performance, and equipment effectiveness in one view.

Power BI-style portfolio mock-up. Values are tied to the simulated Excel issue register.

Decision questions the page is built to answer:

Tier level is determined by severity, cross-functional impact, and the authority needed to remove the blocker - not only by how long an issue has been open.

Severity score - Priority Score = Production Impact (30%) + Safety (25%) + Quality (20%) + Duration (15%) + Recurrence (10%)

Example issue walkthrough

The model uses one record per issue. This creates traceability from the original event to the final corrective action and allows consistent filtering by department, category, severity, tier, status, owner, and date.

Actual spreadsheet render of the simulated issue register used as the dashboard data source.

Key data fields: Issue ID, date raised, department, category, sub-category, tier, severity, status, owner, description, root cause, downtime, units affected, target resolution, resolved date, and actual resolution time.

The root-cause page shifts the discussion from how many issues occurred to why they occurred, how often they repeated, how long they took to resolve, and whether corrective actions were effective. A Pareto view highlights the small number of categories responsible for most disruption: Equipment (46 issues, 32.4%), Material (31, 21.8%), Quality (24, 16.9%), Process (21, 14.8%), Supplier (12, 8.5%), Engineering (6, 4.2%), and other causes (2, 1.4%).

Root-cause and corrective-action dashboard mock-up using the same simulated issue population.

Closure standard - an issue is only marked resolved once every condition below is met:

The dashboard works only when decisions happen on time. Each review level has a defined owner, agenda, decision output, and escalation trigger - moving issues from local containment to site-level decisions without losing ownership.

Line teams own immediate containment. Functional teams own technical resolution. Site leadership resolves cross-functional trade-offs. Senior management becomes involved only when the issue requires capacity, investment, supplier, or programme decisions.

Baseline figures from the simulated dataset used to pressure-test the control design before-and-after comparison.

Operational reporting becomes difficult when process steps, system data and management KPIs are documented separately - a number can appear on a report without a clear definition, owner, source field, calculation rule or action threshold. The project builds traceability from the business process to the KPI, and from the KPI to the management decision.

Project question: How can manufacturing data be converted into a control system that distinguishes normal variation from real risk, assigns ownership, and closes the loop through verified corrective action?

The project was designed around a closed loop, not a one-way dashboard. Traditional reporting tells management what happened; a control model must also define the expected condition, detect meaningful deviation, trigger the right response, and verify that the response worked.

Feedback: verified corrective action changes the process rule, ownership, or operating method - closing the loop back to Process Event.

Five design rules:

Averages alone can hide an unstable process. The chart below plots engineering approval cycle time against statistical control limits rather than the target alone.

Simulated control chart. Three points breach the upper control limit - special-cause variation that would be hidden by the average alone.

Interpretation: the average approval cycle sits close to the business target, but three observations breach the statistical upper control limit. These are not normal fluctuations - they require root-cause investigation before the process is judged by its average.

A process can meet the target on average and still fail too often because variation is too wide - so the model monitors standard deviation and capability, not only the mean.

Simulated capability analysis. CPU = (USL − process mean) / (3 × standard deviation); values below 1.0 indicate insufficient one-sided capability.

Control action tested: standard approval path, mandatory data fields before submission, workload visibility, and automatic escalation of ageing records.

The purpose of a leading indicator is to explain and influence a lagging result - so the catalogue is built as a causal system, not a flat KPI list.

Design rule: a lagging KPI should have at least one controllable leading indicator and one named owner.

Ten KPIs span leading, process and outcome layers, each with a business definition, calculation logic, data source, target/warning/critical bands, frequency, owner and escalation rule.

Simulated KPI catalogue and ownership matrix - the control constitution referenced by every dashboard and management review.

The control system only works when each field, formula, owner, and review cadence is explicit. The source register captures planned and actual dates, cycle time, data quality, compliance, open action, action owner, due date, and escalation tier.

Simulated ERP-style operational data register - the record-level source behind every KPI in the catalogue.

Not every miss deserves the same meeting, owner, or response time. A composite Exception Priority Score (0–100) prioritises attention: 30% deviation magnitude + 25% business impact + 20% recurrence + 15% data confidence + 10% strategic exposure.

Simulated exception matrix. Bubble size = recurrence; label = composite exception priority score (0–100).

The final deliverable is a control constitution: definitions, thresholds, owners, cadence, and escalation rules.

What this project demonstrates: connecting ERP data, process modelling, statistical control, KPI governance, and management action into one operating model. The project is not presented as a measured company transformation - the figures above are a transparent simulation showing how the control design could influence performance.

A battery programme can appear ready at component level while remaining unstable as a complete production system. Ramp-up requires simultaneous maturity across equipment, material, supplier capacity, process capability, quality controls, workforce readiness and issue governance - so the project treats launch readiness as an integrated system rather than a single milestone.

Six dimensions are scored Green / Amber / Red: capacity (rate vs. requirement), quality (defect trend, process capability), delivery (on-time, lead time, recovery plan), industrialisation (tooling, fixtures, training), change control (open design/process changes) and risk response (containment speed, escalation quality).

An Excel model compares planned demand against demonstrated capacity (not nominal capacity), highlighting coverage gaps, ramp-rate assumptions, downtime sensitivity and supplier dependencies. Scenario analysis tests base, constrained and recovery cases using clearly labelled synthetic scenario data - never confidential production figures.

A high-volume education-sales environment requires disciplined lead handling. Revenue performance depends on how quickly leads are contacted, how consistently follow-ups are completed, how accurately opportunity stages are maintained, and how clearly managers can see funnel leakage. I worked in a high-volume sales environment where thousands of leads moved through the CRM every month - the real challenge was not simply generating activity, it was deciding which leads deserved attention, how quickly the team should act, where revenue was being lost, and how performance could be made more predictable.

Also received top-performer recognition, including an NS200 motorcycle award.

I progressed through three roles - Senior Business Development Associate, Team Lead, and Senior Business Development Specialist - covering direct sales, customer counselling, CRM discipline, team coordination, weekly reporting, performance coaching, and revenue delivery.

A hand-drawn strategy board connects the funnel, lead scoring, customer response, team coaching, forecasting, and the 90-day operating roadmap into one commercial system.

Reconstructed and anonymised for portfolio use - no confidential customer or company data is shown.

Where did potential revenue reduce as leads moved from assignment to contact, qualification, counselling, and payment? The reconstructed funnel is built around the documented INR 1.2 crore-plus result.

Illustrative funnel based on the documented revenue outcome.

Main insight: response speed, qualification quality, demo attendance, and payment follow-through are the biggest controllable revenue levers.

Not every lead deserves the same urgency, and not every representative should receive the same type of lead - the model makes prioritisation transparent and easier to manage.

Core allocation rules:

How does conversion change when first contact is delayed, and how much can additional follow-up recover?

Finding: fast first contact with 3–4 structured follow-ups produced the strongest conversion.

Recommended control: same-day first-contact SLA, a standard four-step follow-up sequence, and a weekly aged-lead review.

Activity and effectiveness were reviewed separately - this made coaching more specific and helped identify who needed more leads, who needed skill support, and who needed a recovery plan.

Bubble size represents revenue generated. The matrix separates effort from effectiveness.

Observed result: approximately 30% improvement in team output, supported by focused tracking and coaching. The coaching conversation becomes practical: what behaviour must change, what support is required, and how will progress be measured?

Management rhythm:

Success metrics tracked: conversion rate, follow-up completion, revenue vs target, forecast accuracy, lead response time, team productivity.

Passenger volume alone does not show whether a route is healthy. A busy route may have weak margins, while a profitable route may suffer from poor punctuality or an inefficient timetable. The study combines commercial and operational measures in one decision model - the strength of the project is not a single formula, it is the complete workflow from raw data to decision-ready output.

Research questions:

The analysis moved from raw data to a route decision across demand, economics, service quality and strategic fit.

Core calculations

Decision rule - commercial attractiveness: demand strength, contribution margin, revenue potential and strategic corridor value. A high score indicates a stronger commercial case.

Operational feasibility:

Line width represents passenger volume; line style represents the recommended network action across 10 European corridors.

Simulated and anonymised portfolio data.

The revised timetable removes weak late-night departures and shifts capacity toward stronger morning, afternoon and weekend demand windows - testing whether better timing can improve utilisation before the network adds more total trips.

Proposed schedule removes weak late-night trips and shifts capacity toward stronger demand windows.

The corridor combines high demand, strong weekly contribution, and resilient utilisation. The proposal adds two peak departures during Friday and Sunday demand windows.

Simulated and anonymised portfolio data. Commercial gate: incremental load factor ≥75% and weekly contribution ≥€250k.

Recommendation: run a four-week pilot with two additional peak departures. Make the change permanent only when incremental load factor stays at or above 75% and weekly contribution reaches at least €250k.

Bubble size represents weekly revenue; the axes separate commercial value from execution feasibility across the corridor portfolio.

Bubble size represents simulated weekly revenue. The axes separate commercial value from execution feasibility.

EV market data is often spread across registration tables, infrastructure records and market reports. The project creates one decision-support layer that lets a reviewer move from national market growth to brand, model, regional and infrastructure patterns without reading multiple disconnected sources.

Vehicle service is often reactive. Drivers may not understand warning signals, service prices, workshop timing or whether a recommended intervention is urgent. The concept reduces uncertainty by connecting vehicle status, service history, maintenance prediction, workshop availability and customer communication in one digital journey.

Solving real-world EV charging friction in Germany

Germany is one of Europe's fastest-growing EV markets, yet charging infrastructure remains fragmented, unreliable, and frustrating for everyday users. This self-directed project simulated a full product discovery and roadmapping process for an EV Charging App - from user pain-point identification through to a phased product roadmap, PRD, and KPI framework.

The goal was to apply structured product thinking - the kind used by product managers at mobility and tech companies - to a real, unsolved problem aligned with my MBA specialisation in Automotive & Mobility.

Key pain points identified

10 core features - prioritized with MoSCoW

Using the MoSCoW framework, 10 key features were defined and categorised by business value, user impact, and delivery complexity:

3-Phase delivery plan

KPI framework to track outcomes

EV ownership introduces after-sales concerns distinct from conventional vehicles - battery confidence, software support, charging-related assistance and long-term maintenance uncertainty. The study explores whether a structured extension pack can reduce this uncertainty and create value for both customers and mobility providers.

Controlling appliances with your mind - hands-free, signal-driven automation

This final year project developed a Brain-Computer Interface (BCI) system that enables users to control smart home appliances entirely through brainwave signals - specifically EEG (electroencephalography) data captured via the NeuroSky MindWave headset and processed in real-time using MATLAB.

The motivation was accessibility: designing a control system that requires no physical interaction, enabling hands-free operation for people with limited motor function. The system responds to deliberate eye blink patterns detected in the raw EEG stream, translating them into appliance on/off commands via Bluetooth and Arduino-controlled relay modules.

End-to-end signal pipeline

How the system works

The NeuroSky headset transmits raw EEG data over Bluetooth to a laptop running a custom MATLAB signal processing pipeline. The pipeline applies bandpass filtering to isolate relevant frequency bands (delta, theta, alpha) and uses amplitude thresholding to distinguish deliberate eye blinks from background neural noise.

Detected blink patterns (single, double, sustained) are mapped to specific appliance commands - lights, fans, and power sockets - and transmitted via the HC-05 Bluetooth module to an Arduino Uno, which drives 5V relay modules connected to real AC appliances in a mock home setup.

SQL was used to log command history, session timestamps, and device state - enabling basic usage analytics and session review for usability testing during the project evaluation phase.

Key engineering problems solved

A case-study portfolio, built page by page from scratch

This is the site you're reading right now. It's a multi-page personal portfolio built to present detailed case studies - manufacturing operations, product strategy, analytics and engineering work - in a consistent, readable, recruiter-friendly format, without relying on a website builder or a JavaScript framework.

The brief was self-set: every project needed its own full case-study page and a place in a filterable index, the whole thing had to feel like one coherent product rather than a stitched-together set of documents, and it had to load fast and work cleanly on a phone in a train station as well as a laptop at a desk.

One shared shell, many independent case studies

Plain HTML, CSS and JavaScript - no build step

The design system runs on CSS custom properties (color, spacing and type tokens shared across light and dark section variants), a single Inter type family from Google Fonts, and reusable component classes (section-block, index-row, feat-list, outcome-row, tech-badge) so every case study looks native to the site instead of pasted in.

Interaction is handled by one shared vanilla JavaScript file: a custom cursor that follows the pointer with an eased requestAnimationFrame loop, scroll-triggered reveal animations via IntersectionObserver, a scroll-aware navigation bar with active-link tracking, and a mobile hamburger menu - all DOM lookups guarded so the same file runs unmodified on pages that only use a subset of these elements.

The project index uses a lightweight category filter (data attributes + class toggling, no framework), and the CV/contact capture flow is wired to Web3Forms as a serverless form endpoint, so there's no backend to host or maintain.

Keeping every page consistent without a framework

Confirmed on real widths, not just assumptions

Every page was served from a local static server and driven with headless Chrome rather than checked by reading code alone - full-page screenshots at desktop width against the rest of the site, then a responsive sweep across the site's own breakpoints (≤1024px, ≤960px, ≤540px, ≤480px) from small-phone widths up to a 1440px desktop, with an automated check comparing the document's scroll width to the viewport width to catch horizontal overflow.