I Built a Digital Notebook for a Kiosk Owner Who's Tired of Paper Records — Here is What I Learned

The problem I set out to solve

Picture a small kiosk in a town — the kind that sells bread, milk, sugar, eggs, tea leaves. The owner tracks everything in a notebook: what is in stock, what sold today, how much cash should be in the till. It works, until it doesn't, a page gets torn, a calculation gets missed, or nobody notices sugar is almost out until a customer asks for it.

I built Nuru Shop Sales Tracker, a simple command-line tool in Python, to replace that notebook. No app download, no internet connection needed, no technical skill required beyond typing numbers into a menu.

What it actually does

When you run it, it asks for the kiosk's name and the owner's name, then enters a menu:

1. View Current Inventory Stock
2. Add or Restock a Product
3. Sell a Product
4. View Sales Report
5. Search Products
6. Save & Exit

From there, the owner can check what's in stock, add new products or top up existing ones, record a sale (with the system automatically calculating change to hand back in notes and coins), search for a product without needing to remember its exact name, and see a summary of the day's performance.

The part I'm most proud of: it thinks ahead for the owner

The most useful part of this project isn't the menu — it's what happens quietly in the background. Every time the owner exits the program, two things happen automatically:

1. A restocking list is generated for any product running low (fewer than 10 units), so the owner has a ready-made shopping list to hand their supplier, no manual stock-checking required.
2. The full inventory and the day's sales are saved to files, so nothing is lost between sessions. The next time the program runs, it picks up exactly where it left off.

At the end of a shift, instead of doing the math, the owner instantly sees their total revenue and which product sold the most, the kind of insight that used to take flipping back through notebook pages to figure out.

How I approached building it

Rather than writing one giant block of code, I broke the problem into small, single-purpose functions. One to view stock, one to sell a product, one to generate the sales report, and so on and all are called from one main loop. This meant I could test each piece (does selling more than what's in stock actually get blocked? does a typo in the menu crash the program?) independently before trusting them to work together.

I also spent some time on input validation. A shop owner using this tool might mistype a price, leave a field blank, or enter letters where numbers are expected, the program needed to handle all of that politely instead of crashing, since a crashed program is worse than a paper notebook.

What I'd build next

• A configurable low-stock threshold per product. 10 units is a sensible cutoff for something like bread, but not for a slower-moving item like sugar.
• Trend reporting across sessions, not just a single shift. Right now, sales history is saved but only ever summarized one day at a time.
• A CSV export, so an owner could hand their sales data to an accountant without needing to open a text file.

What this project taught me

The technical skills — dictionaries, file handling, input validation — were the easy part to learn. The harder, more useful skill was thinking about the end user the whole way through: someone who isn't a programmer, might make typos, and just wants their day to run smoother than it did with a notebook. Every design decision, from the menu wording to the automatic restock alerts, came back to that person.