PRO BONO CLIENT PROJECT
A point-of-sale, inventory and event operations system created for a small product business selling through warehouse stock and temporary market locations.
I led the product and engineering work for the functional Version 1, translating business requirements into a private full-stack application.
01 / CONTEXT
Godscent Drive needed to coordinate sales, stock and temporary market events. The design follows the owners’ day-to-day workflow across sales, stock movements and market operations.
Stock can begin in a warehouse, move to an event, be sold using different payment methods and return after the event. The owners needed one workspace that preserved a reliable record of those movements while supporting everyday sales and reporting.
Connectivity at markets can be inconsistent. Offline storage and later synchronisation are therefore planned for a future implementation phase rather than presented as a completed Version 1 capability.
Sales, stock and event information needed to operate as one connected workflow rather than separate manual records.
Warehouse and event stock required clear movement history, balances and controlled returns.
A later phase needs browser-side storage, a retry queue and a defined synchronisation process for periods of weak or unavailable internet access.
Refunds, voids, configuration and user administration required controlled access and traceability.
02 / SOLUTION
Version 1 connects the primary workflows inside one branded internal application while retaining a modular structure for continued development.
Process purchases, record payments, produce receipts and review sales history.
Track products across warehouse and event locations through explicit stock movements.
Create events, allocate stock, process event sales and review event-level performance.
Protect selected high-impact actions and provide role-aware access for staff.
03 / RESPONSIVE EXPERIENCE
The interface adapts across tablet and mobile layouts so core navigation, operational information and frequent actions remain accessible without relying on a desktop-sized screen.
04 / ARCHITECTURE
The diagram shows the high-level system boundary. Client-specific rules, schema details and operational calculations remain confidential.
05 / MY CONTRIBUTION
I worked directly with the owners, modelled their workflows and developed the application across the frontend, API and persistence layers.
Turned conversations about selling, stock handling, markets and corrections into defined system workflows and boundaries.
Modelled users, roles, products, locations, movements, events, sales, payments, refunds, voids and reporting relationships.
Built the React interface, Spring Boot services, PostgreSQL persistence, JWT authentication, role-aware navigation and selected role-restricted backend endpoints.
Exercised representative API and interface workflows for sales, receipts, inventory movements, events, refunds, voids and reports while refining the user experience.
06 / ENGINEERING DECISIONS
The most important choices were about stock accuracy, understandable transaction state and protection of high-impact actions.
Inventory changes are represented as movements so the origin of a current balance can be investigated.
Sales and stock movements include synchronisation-status fields. An offline queue and reconnect process still need to be implemented before those fields support end-to-end offline operation.
Backend restrictions cover user management, settings, audit logs, suppliers, refunds, voids, promotions, reports and inventory actions. Several core operational routes still require complete authorisation coverage.
07 / STAFF AUTHENTICATION
Staff sign in through the Spring Security authentication endpoint. The React application stores the returned token, sends it with API requests and limits client-side routes according to the user’s recorded role.
08 / DELIVERY
The project followed an iterative cycle of discovery, modelling, implementation, manual workflow checks and interface refinement.
Understood how the owners sell, move stock, operate markets and review results.
Converted business workflows into system entities, permissions and transaction boundaries.
Implemented the interface, services, persistence and authentication controls.
Manually checked representative API and interface workflows and corrected issues found during development.
Improved navigation, dashboard visibility, branding and system feedback.
09 / OUTCOME
Version 1 brings requirements discovery, business modelling and full-stack delivery into connected workflows across sales, inventory, events and administration.
Core sales, stock and event operations are represented in one internal application.
Sales link to payments, receipts, stock effects, corrections and reports.
The dashboard surfaces sales totals, warehouse and event stock, planned events and recent stock movements.
The modular frontend, API and database structure support continued development.
10 / CURRENT SCOPE
Version 1 supports the core connected workflows. The next phase focuses on offline capability, broader automated testing, complete backend authorisation and structured client feedback.
The source remains private because the application contains client-specific workflows and business logic. I can discuss its architecture, development process and selected engineering decisions during an interview while respecting the owners’ confidentiality.
CASE STUDY 01