A case study on turning a grocery store's business workflow into a simple sales and inventory management system.
A grocery store client approached me with what initially sounded like a straightforward request:
"I need a website for my store."
My first assumption was e-commerce. It would have been easy to jump straight into building product pages, a shopping cart, checkout, customer accounts, and payment integration.
But I didn't start there, I started by asking one simple question:
How does the business actually operate?
That question changed the entire direction of the project.
Understanding the Actual Problem
The store is a physical grocery store, Customers walk in, pick their products, pay at the store, and leave.
There are:
- No online orders
- No delivery workflow
- No customer accounts
- No online checkout
So building a traditional e-commerce platform would have been solving a problem the business didn't actually have.
The real problem was happening behind the scenes, Sales were being tracked manually, making it difficult to:
- Keep accurate records of daily sales
- Know how much stock was remaining
- Calculate profit accurately
- Track sales over time
- Understand how the business was performing
That was the problem I needed to solve.
Rethinking the Architecture
Once I understood the workflow, the architecture became much easier to define.
Instead of building an e-commerce application, I designed a retail sales and inventory management system around the store's actual operations.
The core workflow became:
Product
↓
Sale Recorded
↓
Revenue & Profit Calculated
↓
Inventory Updated
↓
Transaction Saved
For example, let's say the store has:
Product: Coca-Cola
Cost Price: ₦500
Selling Price: ₦700
Stock: 100
A customer buys 3, The system calculates:
Revenue = ₦700 × 3 = ₦2,100
Cost = ₦500 × 3 = ₦1,500
Profit = ₦2,100 - ₦1,500 = ₦600
Remaining Stock = 100 - 3 = 97
The important part is that the staff shouldn't have to calculate any of this manually.
They record the sale, and the system handles the rest.
- Keeping Business Logic on the Backend
One of the decisions I paid particular attention to was where the calculations should happen.
It would be easy to calculate the total and profit in React and send those values to the backend, I didn't want to do that.
The frontend is responsible for collecting input and presenting information. It shouldn't be trusted with critical business calculations.
Instead, the frontend sends something like:
{
"items": [{"productId": "64abc...", "quantity": 3}]
}
The backend then:
- Checks that the product exists.
- Checks the available stock.
- Retrieves the current prices from the database.
- Calculates the sale total.
- Calculates the cost.
- Calculates the profit.
- Updates the inventory.
- Saves the transaction.
This makes the backend the source of truth for the business logic.
It also means a client can't simply modify a frontend value and manipulate the recorded profit or sale amount.
The Historical Data Problem
Another issue I had to think about was changing product prices.
Consider this:
Today:
Coca-Cola
Cost Price: ₦500
Selling Price: ₦700
A month later:
Coca-Cola
Cost Price: ₦600
Selling Price: ₦800
If a sale only stores the product ID, I have a problem.
When I look at an old transaction later, should the system use today's price or the price that existed when the sale happened?
Obviously, it should use the price at the time of the transaction.
So instead of storing only the product reference, each sale item keeps a snapshot of the relevant information:
Product name
Quantity
Cost price
Selling price
Subtotal
Profit
This means an old transaction remains accurate even if the product is edited later.
This is a small design decision, but it matters when you're building systems that deal with financial records.
Preventing Negative Inventory
Inventory introduces another important business rule.
Suppose the store has:
Stock = 5
and someone tries to record a sale of:
Quantity = 7
The system shouldn't simply calculate:
5 - 7 = -2
and save it.
The backend needs to reject the transaction:
Insufficient stock.
Available quantity: 5
This validation needs to happen on the server, not just in the frontend.
The frontend can show a warning, but the backend must enforce the rule.
What This Project Has Reinforced for Me
One thing I've learned from working on client projects is that requirements gathering isn't just a formality before development starts.
It directly affects your architecture.
If I had started coding immediately from the words:
"I need a website for my grocery store.", I could easily have spent weeks building an e-commerce platform that didn't solve the client's actual problem.
Instead, asking questions about the workflow changed the entire system.
And that's probably one of the biggest lessons I'm taking from this project: Don't design the software around the words the client uses. Design it around the problem they're actually trying to solve.
Listen first. Understand the workflow. Then design the system.
The code comes after that.
