top of page

◀ Home

This case study illustrates how I identified the path to fixing a business-critical bug.

Company Type: Startup
Product: Multi-lingual regional content
Business model: Freemium with content subscriptions and purchases
Company size: < 10
Duration of engagement: 1 month

This case study demonstrates the following skills:

  1. I first understand the goals clearly. I also understand non-goals, which draws a boundary around the goals. We're often in a rush so we start executing without clarity on goals, but that's like getting in your car and driving without knowing where you're going. In this case, there was one narrowly defined goal: to fix a bug where users were upgrading to premium were not getting premium content.

  2. When I run into problems, I know when to take a step back from the given goal and evaluate the code holistically. Reframing the problem was necessary in this case to identifying the root cause, without which any efforts won't solve the problem. If you go to doctor and say, "Hey, doc, I want a bypass surgery", the doctor doesn't say, "Great, lie down on this table over here, and I'll grab my scalpel and come back!" Instead, he'll investigate the problems and form his own independent assessment. That's what I did in this case when I stepped back from the given goal of the payments bug and holistically evaluated the tech.

  3. I'm able to tie my assessment back to the given goal: given the poor state of the code, fixing the payment bug in a way that stays fixed requires rewriting the whole code.

  4. Once I decide to rewrite the code, it's usually better to improve it in place: imagine you have a car where every component is broken: the engine, the transmission, the brakes, the seats, the windshield, and so on. It's usually better to replace the engine, at which point we have a better car than before. Then we replace the brakes. And so on, eventually ending up with a brand new car. Doing it this way is quicker, less risky and delivers value sooner than buying a whole new car. However, I also know when a general guideline is not applicable, such as in this case. I reached this decision by evaluating technical reasons (React being hard to upgrade) and non-technical (the founder's lack of confidence in the agency).

  5. I'm able to guide the founder on how to make the best use of a limited budget, such as by suggesting he prioritise UX over more features.

  6. When I find deficiencies in the client's thinking, I guide him on improving as an engineering leader, such as having granular milestones, or recognising that a greater scope of work will result in greater time and cost. That way, the client is more effective in the future, and that the problem we started out with doesn't repeat. I try to leave clients better off at the end of the engagement than before, rather than making them dependent on me.

  7. When we started the engagement, we did not know that we'd end up evaluating agencies. I do what's best for the client. Having run a startup before, I'm not rattled by uncertainty. Instead, I bring order out of chaos.

  8. I was able to achieve all this in just 14 hours, resulting in a high ROI.

This flowchart tells you how I executed this project at a high level, followed by a detailed flowchart:


“When we had a business-critical problem (premium content was not getting unlocked after payment), Kartick evaluated the code and identified the root cause as bad code quality. He advised us to rebuild the code from scratch as the best way to solve the problem, and advised us on which stack to use. He also connected us with a Design Leader who delivered an excellent design for us on time and on budget.

I highly recommend Kartick.”




◀ Home

bottom of page