This case study highlights how design goes beyond screens into problem validation, decision-making, and scaling under constraints.
What began as a daily frustration at NIT Rourkela, limited food options, dull mess meals, and long delivery walks, led us to build a faster, simpler food ordering solution.
We initially planned to build a dedicated food delivery app, but with no funding and a small tech team, we pivoted to validating the idea through a WhatsApp based service.
Students at NIT Rourkela faced poor mess food, limited dining options, and a 2 km walk to Jagda Gate to collect orders, as existing food delivery platforms are not allowed inside the campus.
We initially planned to build a dedicated food delivery app to solve hostel food accessibility issues at NIT Rourkela.
After defining the MVP features, we mapped core user flows using paper sketches and sticky notes to quickly visualize happy paths and edge cases. Design and development ran in parallel to move faster, with completed flows handed off incrementally to developers.
We followed familiar food delivery patterns inspired by existing apps to reduce learning effort, aligning with Jakob’s Law. Ideas moved from paper wireframes to high-fidelity UI, allowing rapid iteration without early design lock-in.
Since this was my early phase with Figma, I iterated on these screens multiple times to improve layout clarity, visual hierarchy, and overall usability, eventually arriving at a more refined and consistent final design.
When app development stopped due to technical constraints, we realized that building a business was not about waiting for perfect technology.
WhatsApp gave us a fast, no-build way to test whether students truly needed the solution.
The goal was simple: prove usage first, then fund app development through profits.
Before launching the service on WhatsApp, we focused on building a strong operational foundation. The first step was onboarding top-rated restaurants in Rourkela. To gain their trust as first-time founders, we created a formal MOU that clearly defined expectations around food quality, hygiene, delivery discipline, and operational transparency.
The second challenge was securing permission to operate on campus. After navigating multiple approval layers, including FTBI, the on-campus business committee, and security officials, we finally received partial approval from the Registrar with restrictions on delivery access. While doorstep delivery inside hostels was not permitted, this clarity helped us redesign the delivery flow within allowed boundaries.
To solve the delivery problem, we built a student-led delivery network. Orders were delivered up to Jagda Gate by external partners and then carried to hostel rooms by student volunteers coordinated through WhatsApp. This approach allowed us to complete deliveries efficiently while complying with campus rules.
QuickServe received strong early adoption, driven by student curiosity and word-of-mouth across campus.
Pre-launch promotion through WhatsApp groups and on-campus posters generated high awareness.
Continuous feedback collection after each delivery helped us rapidly improve service quality and operations.
We analyzed feedback from 100+ customers and spoke with 50+ students during the first month to identify high-impact issues.
Rather than fixing minor problems, we prioritized three major pain points that directly affected speed and revenue.
We brainstormed solutions to address these pain points and explored the concept of a WhatsApp ordering bot.
The goal was to eliminate manual catalog browsing and structured message typing by automating order collection.
While we designed multiple bot flow approaches, the final implementation could not be completed due to technical constraints.
After the WhatsApp bot failed due to technical constraints, we shifted to a lightweight web app to reduce typing errors and speed up ordering.
Users place orders on the web app, with the final order summary as PDF invoice sent to WhatsApp for confirmation.
I worked closely with developers to audit flows, fix usability issues, and finalize the ordering experience.
42 min YT vid, showing my thought process while audit
Text-based orders can be edited, leading to pricing errors and disputes.
PDF invoices act as a locked source of truth, prevent manipulation, and reduce manual verification during WhatsApp-based order confirmation.
We started with internal alpha testing, then launched the web flow as an alternative to WhatsApp to reduce risk and ease adoption.
Since our primary users are students, they adopted the web-based ordering flow quickly and with minimal resistance.
During moderated testing with 10 users, some first time users were briefly confused by the PDF invoice and WhatsApp redirection.
However, existing trust prevented drop-offs, and users quickly adapted, with task completion improving rapidly after the first attempt.
The web-based flow boosted order speed by 40–50%, increased monthly sales to ₹1L+ from ₹70K, and improved satisfaction for 90% of users, while highlighting order tracking as the next improvement area.
With early validation complete, we are scaling QuickServe beyond MVP by outsourcing app development, funding the build through profits, and expanding across Rourkela with a faster, more localized delivery experience.
That’s a wrap. If my approach aligns with what you’re looking for, feel free to explore the full case study or get in touch.
