Software engineering · Built in-house
The application we had to live with
GranelCo runs a real retail operation selling goods by weight: collections, inventory and cost updates. Three people use it every day. It was built for our own store, so every shortcut would have been our problem — which is a useful way to build software.
At a glance
- Client
- In-house
- Practice
- Software engineering
- Users
- 3, daily
- Status
- In production
- Form factor
- Packaged desktop app
React · Vite · FastAPI · SQLAlchemy · SQLite · JWT · Tauri
The situation
Selling by weight breaks most off-the-shelf systems
Retail software generally assumes a unit: one item, one price, one barcode. Goods sold by weight do not behave that way, and the gap shows up exactly where it hurts — in collections, in inventory counts and in keeping costs current when the purchase price moves.
Those three processes were where the time went. The application was scoped around them rather than around a feature list, and it was packaged as a desktop app because the store needed it to work whether or not the internet did.
What we did
Four steps, in this order.
Scoped to three processes
Collections, inventory and cost updates — the three places where weight-based selling actually costs time. Everything else was left out of the first version on purpose.
Built full-stack, packaged for the desk
React and Vite on the front end, FastAPI and SQLAlchemy behind it, SQLite for storage, JWT for authentication, and Tauri to package it as an installable desktop application.
Shipped to real users immediately
Three people started using it in a live store, which surfaces design mistakes in days rather than in a UAT session that everyone is trying to finish.
Kept it in production
It is still the system the store runs on. That is the only durability test that means anything.
Results
The numbers, as measured.
The takeaway
What this case actually shows
This one is transparent about what it is: an in-house build for our own operation, not a client engagement, and the time saved was never formally measured. What it does demonstrate is a full-stack application scoped around three real processes, shipped to daily users and still running — with the people who wrote it living with every decision. Software built by someone who has to use it on Monday ages differently.
Start here
Have a version of this problem?
Describe the problem in a few lines. You get a written reply with a first read on it, whether or not there is an engagement in it. The message is sent from this page — no email client, no third-party form service, no trackers.