← Back

Taking Ownership of a Legacy Project with Just One Page of Documentation

Note: This case study is based on my personal experience, written by me and refined with AI tools for clarity and polish.

Imagine inheriting a critical food delivery system that serves thousands of customers daily—yet, the only documentation you receive is a single page with a few lines about its features. That was the challenge I faced when I took over HungryNaki, an online platform where users order food from over 750 restaurants across Dhaka, Chittagong, and Sylhet.

The platform operates with 1,500+ riders and 25 hubs, ensuring most orders are delivered within an hour. Customers rely on its website and mobile apps to search for restaurants, place orders, and get their food delivered seamlessly. However, the system struggled to handle peak-hour traffic, leading to frequent failures, frustrated customers, and business disruptions.

The Challenge

I was assigned as the lead for this project, a live system with ongoing client dissatisfaction. The system struggled to handle peak-hour traffic, particularly in the evenings when most customers placed orders or when the marketing team launched new discount promotions.

This was not a small system—it included:

I was leading a team of four junior developers, most of whom were new to the project. The available documentation consisted of just one page, containing only a 4–5 line overview of its features.

My Approach

My first goal was to understand the full lifecycle of a single request—from the client app or web platform to the server and all the components it passed through.

Once I gained an understanding of how the system functioned and the roles of different components, I focused on identifying system bottlenecks using metrics. However, I quickly discovered that we had minimal monitoring in place, forcing me to rely on system usage patterns instead.

I also found that the system was a monolith, running on a single server with a high load on MongoDB. To improve scalability, I planned to transition it into a modular monolith, ensuring that we wouldn’t be limited to a single instance.

Execution

Short-Term Fixes (Immediate Stability & Performance Improvement)

Long-Term Fixes (Scalability & Architectural Improvements)

Results

The immediate system failures during peak hours were mitigated, allowing the business to continue operations.

However, performance was still slow at peak times, requiring further optimization efforts.

Learnings

Conclusion

Starting work on a new system—especially one with minimal documentation—can be overwhelming. The best approach is to begin with the smallest unit, gradually expand understanding, and prioritize the most critical issues first.

Key Technologies & Tools