What: A digital platform where credit card customers could visualize their spending patterns, raise transaction disputes, and receive dynamic credit-limit suggestions based on their salary. Simultaneously, it gave banks a dashboard to analyze customer spending behavior, identify cross-sell opportunities, and suggest credit-limit adjustments.

Problem: Customers had no clear visibility into where their money was going across multiple cards, and raising disputes was a slow, opaque process. Banks, on the other hand, had raw transaction data but no easy way to turn it into actionable insights for customer retention or targeted product offerings.

What I built: A full-stack system with customer-facing spending visualizations, a dispute-raising workflow, and a bank-side analytics dashboard for segmentation, spending-pattern analysis, and automated credit-limit recommendations tied to income data.

Why it didn't ship: I built a customer-retention tool for an organization that was structurally designed to acquire merchants. Credit card marketing was merged with POS marketing, so the team’s KPIs and budget were tied to merchant sign-ups and transaction volume — not customer lifecycle, cross-sell, or credit-limit optimization. Worse, the bank’s actual operating policy was force-selling: pushing credit products onto the same merchants who already held POS terminals or loans, using the fake promise of a "better relationship" rather than acquiring quality customers backed by data and sustained behavior change. The bank had no dedicated team with the authority, budget, or bonus structure to own customer analytics. The data my platform generated was valuable, but there was no organizational receptor to absorb it — because the institution wasn’t trying to understand customer behavior; it was trying to squeeze existing relationships. Without a champion whose performance review depended on the output, the product became a cost with no clear owner.

Lesson: I now draw the buyer’s organization chart before I draw the architecture diagram. If no one on that chart is measured by the metric my product improves, I am not selling software — I am selling organizational restructuring. And that is a much harder, slower sale than any feature set can overcome. Today, I need to name the person whose bonus gets bigger if my product succeeds. If I can’t, I don’t build.

Merchant Management & Settlement Intelligence Platform Abandoned

What: A merchant management platform that automated daily operational settlements, visualized merchant performance through interactive honeycomb charts, predicted POS terminal inactivity using year-over-year seasonal behavior, tracked total MSF earnings, and gave merchants a self-service portal for multi-channel reporting and issue resolution.

Problem: Banks managed thousands of merchants but relied on fragmented systems for settlements, had no visual way to spot portfolio-level transaction trends, and reacted to POS failures only after they happened. Merchants lacked a unified view of their earnings across channels and no direct path to escalate operational issues.

What I built: An end-to-end platform with automated daily settlement processing, an interactive honeycomb visualization for transaction count and volume drill-downs, predictive POS inactivity alerts powered by seasonal pattern analysis against previous-year data, a real-time MSF earnings tracker, and a dedicated merchant portal for multi-channel report access and issue ticketing.

Why it didn't ship: After multiple quarters of demos, revised proposals, and enthusiastic stakeholder meetings across three different bank divisions, the deal never materialized. The bank didn't reject the features — they rejected what the system would change. If your target is quantity rather than quality, showing someone that their terminal downtime is predictable, their merchant portfolio is underperforming, or their support responses are slow isn't just giving them better data. It's telling them how they should be doing their job. And that is much harder to sell. The system wasn't just another dashboard; it challenged existing priorities, exposed inefficiencies, and created a standard people would be measured against. They called it a data expenditure. What I eventually understood was that the real product wasn't the dashboard. It was a change in behaviour, and changing how people do their jobs is far harder than giving them another tool.

Lesson: I now look for the workaround before I look for product-market fit. If a client isn't already solving the problem in some crude, expensive, manual way — a spreadsheet, a late-night email chain, a headcount they can't afford — then they don't feel the pain deeply enough to change. Enthusiasm in a meeting room is free. A budget line item born from scar tissue is not. I no longer build products that create new habits. I only build products that replace existing, painful ones. And if I can't find the ugly workaround within the first two conversations, I don't schedule a third.