My father owns an FMCG (Fast Moving Consumer Goods) distribution unit. From childhood, I have seen the hardships he faces in managing his business. Since 8th grade, I have been actively travelling along with the business, which gave me real field knowledge about how a distribution unit actually operates, the chaos, the paperwork, the lack of visibility.

So when my college course "Design Thinking and Innovation" challenged us to come up with innovative solutions to real-life problems, I didn't have to think twice. I built a platform to solve my father's problems.

FMCG Distribution Unit Management System is a full-stack web and mobile application built for small to medium level business owners to manage their business end-to-end. It helps owners manage their product data, employee records, and customer information all in one place. Think of it as a lightweight CRM built specifically for distribution businesses.

From Problem to Solution: The Design Thinking Journey

Most developers jump straight into code. Design Thinking forced me to slow down and actually understand the problem before touching a single line of code. Here's how that process shaped this project.

Empathize
I didn't have to go far for this step, the problem was right at home. I spent time observing my father's daily routine, watching how he tracked orders on paper, managed employee schedules manually, and had no real visibility into how the business was performing. I asked questions I had never thought to ask despite travelling with the business since 8th grade.

Define
After gathering observations, the core problem became clear, there was no single place to see everything. Products, customers, employees and orders all lived in different places, mostly paper and memory.

Ideate
I explored multiple solutions, a simple spreadsheet system, a WhatsApp-based tracker, before settling on a proper web and mobile platform. The deciding factor was scalability and ease of use for non-technical users like my father.

Prototype
Before writing any code, I built wireframes in Figma. This saved hours of development time by catching design issues early.

Test and Loop
The app went through multiple iterations based on real feedback from the business context it was built for.

Tech Stack: Why I Chose What I Chose

Every project starts with a set of decisions that shape everything that follows. Here's why I picked this particular stack.

TypeScript was suggested to me for the web layer, and honestly it turned out to be a great choice. The strict typing caught a lot of bugs early during development that would have been painful to debug later. Coming from a Java background, the structure felt natural.

Flutter was my choice for the mobile app. Building a native-feeling mobile app from scratch would have taken significantly longer with other approaches. Flutter let me move fast and still deliver a polished UI, which mattered since the end user was going to be my father, not a developer.

Prisma ORM was the standout decision. Given the volume of data a distribution unit handles, including products, orders, customers and employees, I needed something that could handle relationships cleanly without writing raw SQL for every query. Prisma made database operations faster to write and easier to maintain.

All three connected through a shared backend, keeping the architecture clean and consistent across web and mobile.

Architecture

The application follows a classic layered architecture with three distinct layers working together seamlessly.

Presentation Layer
This is what the user sees and interacts with. The platform has two frontends, a TypeScript web app for desktop access and a Flutter mobile app for on-the-go management. Both connect to the same backend, ensuring data consistency across devices.

Business Logic Layer
This is the brain of the application. Every operation, creating an order, assigning an employee, updating product stock, passes through this layer. It handles all validations, role-based access control, and business rules before anything touches the database.

Database Layer
MySQL serves as the database, accessed entirely through Prisma ORM. Rather than writing raw SQL for every operation, Prisma allowed me to define clean data models and handle complex relationships between products, orders, customers and employees in a maintainable way.

How They Talk To Each Other
The Flutter and TypeScript frontends communicate with the business logic layer through REST APIs. The business logic layer then talks to the database through Prisma. Clean, simple, and easy to scale.

Challenges I Faced

No project goes smoothly. Here are the three biggest walls I hit and how I broke through them.

Real-Time Order Tracking
Real-time visibility was one of the core features of the platform. I implemented this through constant API calls to the database, ensuring the data stays updated without the user needing to refresh manually. The hardest part wasn't the concept, it was configuring the API calls correctly so they were frequent enough to feel real-time but not so aggressive that they hammered the database unnecessarily. Getting that balance right took several iterations.

Vercel Deployment
After pushing commits, the app simply wasn't moving to production. New changes weren't being reflected in the live environment despite successful pushes to the repository. After spending time trying to debug the deployment pipeline, I made the decision to start fresh and that solved it. Sometimes the cleanest fix is just starting over rather than chasing a ghost.

The Dynamic Collection Entry Bug
This was the most complex bug I faced. The platform has a smart collection system. If a customer has two bills, say ₹1,000 and ₹2,000, and an employee enters a payment of ₹3,000, the system automatically clears the lowest bill first and subtracts the remaining amount from the next one. The bug was that bills cleared automatically by the system weren't being removed from the list, they just stayed there, confusing the data. Took significant debugging and outside help to trace the root cause and fix it properly.

What I Learned

Building this project was more than just writing code. It fundamentally changed how I think about software development.

Design Thinking is not just a framework, it is a mindset. Going through the empathize, define, ideate, prototype and test cycle taught me that understanding the problem deeply is more valuable than jumping to solutions quickly. I carry this thinking into every project now.

Building for a real user is completely different from building for a grade. My father was going to actually use this. That pressure made me think about usability, clarity and reliability in ways a typical college project never would have.

Software construction has structure. This project introduced me to real software engineering metrics and techniques that go beyond what textbooks teach. Layered architecture, API design, ORM patterns, these became real concepts rather than theoretical ones.

User feedback is not optional. Every iteration of the product came from observing real usage and making improvements based on that. That loop of build, observe and improve is something I now consider a core part of development.

This project started as a college assignment. It ended as something my father actually uses to run his business. That is the best outcome I could have asked for.