Case study · Desktop business application
Bike Store Inventory & Sales App
A desktop application built for a small electric-bike retailer to manage inventory, sales, service records, FIFO stock, users, and operational reporting.
- Role
- Designer & developer
- Users
- Small retail staff
- Platform
- Windows desktop
- Status
- Ongoing
Overview
The project replaces inconsistent manual tracking with one system for recording stock, transactions, service activity, users, and reports. The interface is organised around the work staff actually perform rather than around database tables.
Problem
Handwritten and disconnected records made it difficult to check stock quickly, review sales history, and understand the true cost of inventory received at different times.
Solution
A local-first desktop application with structured workflows, reliable SQLite storage, and FIFO stock-lot accounting designed for daily retail operations.
Key features
Inventory & FIFO stock
Products, colours, received stock lots, unit costs, remaining quantities, and FIFO consumption are kept together.
Sales & invoices
Staff can record multi-item sales, payment methods, frame numbers, customer details, and print compact invoices.
Service records
Service work is tracked alongside sales with printable records and a searchable operational history.
Users & reporting
Role-aware access, activity tracking, date-range reports, and stock movement summaries support safer daily use.
Implementation
C# and .NET 8 provide the desktop application layer, while SQLite keeps deployment lightweight and the store operational without an internet connection. Database changes are handled through migrations and important stock behaviour is covered by tests.
- Workflow-oriented WinForms screens for non-technical users
- FIFO consumption ordered by received date and stock-lot ID
- Local SQLite persistence with migration support
- Printable sales, service, and reporting documents
- Iterative improvements based on real store feedback
Challenges & learnings
The most important lesson was that operational software has to reflect real exceptions, not only the ideal path. Stock corrections, split quantities, printable paperwork, permissions, and recovery behaviour became as important as the first version of each feature.
Reliable business software is built by repeatedly comparing the interface with the work people actually do.