The Client Asked for a Website. The Business Needed Something Else.

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. Top comments (0)