SPARE
A shared operations workspace for one warehouse and multiple spare-parts shops.
- React
- TypeScript
- FastAPI
- Dexie / IndexedDB
- PostgreSQL
- Redis
- Workbox
The problem & my contribution
Spare-parts teams need to know what moved, who approved it and which records still await sync. SPARE brings stock receipts, sales recording, transfers, purchasing, approvals and accounting into a role-aware desktop/mobile workspace. It is an operations platform, not a payment-processing POS. This portfolio presents the SPOP implementation under the name SPARE.
- Keep permitted receipt, sale and transfer-request work recoverable during connection failures.
- Separate warehouse dispatch from shop receipt, with server-side role and version checks.
- Retain stock and accounting movements as auditable records rather than silently overwriting balances.
From input to useful output
A transfer moves through requested, in_transit and received states. Only its request can enter the local outbox; dispatch and receipt require the live API. Dexie stores local records and queued requests. Reconnect replay reuses client request IDs to avoid duplicate server postings. Stale version checks return HTTP 409 for operator review rather than guessing a merge. Purchasing and expenses use a shared approval path; reports derive from recorded stock and journal entries.
How the pieces fit
React/TypeScript provides the responsive console; Workbox caches the application shell and Dexie maintains the local cache/outbox. FastAPI enforces six fixed roles, JWT/device identity, idempotent creation and selected optimistic-concurrency checks. PostgreSQL is the intended production store; Redis and migration state participate in the /ready gate.
- Operations
- Receipts, sales recording, staged transfers, purchasing and approval dispatch.
- Records & insight
- Append-only stock/journal ledgers, branch reports and explainable replenishment suggestions.
Engineering trade-offs
Offline, with boundaries
Queue supported actions; keep stock hand-offs online.
Stable request IDs and expected versions address duplicate replay and stale writes.
Trade-off: Local records are provisional. Conflicts need review; exhausted retries can require intervention.
Explain before predicting
Use trailing 30-day sales velocity for replenishment.
A transparent heuristic is inspectable before real operating data exists for model validation.
Trade-off: This is not trained demand forecasting; no ML accuracy or commercial savings are claimed.
Results, with boundaries
Rechecked on 5 October 2026: 75 backend tests and 7 frontend tests passed. Implementation and verification records cover role-aware operations, local offline replay and conflict handling; these local tests are not evidence of a production deployment.
- Frontend coverage includes permission-filtered navigation, keyboard/focus handling, offline queue/replay and stale-version recovery.
- Backend coverage spans roles, stock, purchasing, approvals, accounting, idempotency, readiness and migrations.
Source: SPOP implementation, pilot verification/UAT records and local test reruns, reviewed 5 October 2026. Client records, credentials, logs and full internal documentation are not published.