Multipurpose Inventory & Business Management System
About this Project
A full-stack, all-in-one platform built to solve one core problem: how do you fit retail, restaurant, and service-based businesses into a single inventory system without breaking the data model?
The Problem
Most inventory software is built around one assumption — that a "product" is a fixed, sellable unit sitting on a shelf. That works fine for a retail shop, but it completely breaks down the moment you try to apply it to other business types:
A retail business sells finished products directly from stock. A restaurant doesn't sell "products" in that sense — it buys raw ingredients, combines them into prepared items through a recipe-like process, and only then sells the final dish. Stock here isn't static, it's transformed. A service business doesn't have physical stock at all. It sells time, skill, or a service package — yet it still needs to be tracked, invoiced, and reported on alongside everything else. These three models have fundamentally different data structures, different stock behavior, and different sales logic. Most existing tools force you to pick one model and hack around the rest. I wanted to build a system where all three could coexist in the same database, the same dashboard, and the same reporting layer — without one business type's logic corrupting another's. The real engineering problem wasn't building CRUD screens. It was designing a schema and workflow that could answer questions like: How do you track "stock" for something that doesn't physically exist (a service)? How do you connect a sale to inventory when the sold item (a prepared dish) is made from other inventory items (raw ingredients) that need to be deducted automatically? How do you keep one unified dashboard, one wastage report, and one sales report that make sense regardless of which business type generated the data? I split the domain into distinct but connected modules instead of forcing everything into one generic "product" table: Product — for standard retail items sold as-is. Raw Product — for restaurant-style ingredients purchased in bulk. Prepared Product — items built from raw products through a defined composition, so selling one automatically deducts the correct quantity from the linked raw materials. Service — a separate sellable entity with no physical stock, but still fully integrated into invoicing, sales, and reporting. All four flow into the same purchase, sale, invoice, and dashboard layer, so a business owner running a hybrid operation — say, a restaurant that also sells packaged retail goods and offers catering as a service — can manage everything from one place instead of three disconnected tools. Inventory and Stock Separate tracking for products, raw materials, and prepared items Automatic raw material deduction when a prepared product is sold Wastage reporting and manual stock adjustments Sales and Purchases Purchase management with supplier records Sales processing with customer due tracking Invoice generation covering products, prepared items, and services in one bill Return and refund handling Dashboard and Reporting Unified business overview regardless of business type KPI cards and sales/purchase trend charts Activity log for accountability across all modules Access Control Role-aware modules with a foundation for staff permissions, still is not included yet. Built as a modular monorepo: inventory/ ├── multipurpose-inventory-backend/ -> Express + Prisma API └── multipurpose-inventory-management/ -> Next.js dashboard app The backend models each business type as its own domain (product, raw product, prepared product, service) but joins them at the transaction level — purchase, sale, and invoice — so the frontend dashboard never has to know or care which business type generated a given record. account, activity log, auth, category, customer, dashboard, invoice, prepared product, product, purchase, raw product, return, sale, service, staff, supplier, trash, unit, wastage The core workflows for all three business models — dashboard, product management, purchases, sales, and supplier/customer tracking — are functional and live in production. The staff role and permission system is not included yet. This project came from a genuine gap I noticed: most inventory tools assume one business type. Building a schema that could honestly represent retail stock, restaurant transformation, and service-based sales in one coherent system was the hardest and most rewarding part of this build.The Core Design Challenge
The Solution
Core Features
Tech Stack
Architecture
Core Modules
Current Status