SVJ Outdoor —Operational SoftwareBuilt Around Real Work
An internal point-of-sale system adapted for a growing outdoor fashion retailer operating across two physical stores — designed around actual workflows, not generic retail assumptions.
Live·used daily
Year
2025
Role
Product Engineer
Stores
2 locations
Users
Cashiers + owner
The Situation
Before the system, operations were managed through WhatsApp notes and handwritten records. Transactions, cash reconciliations, and inventory tracking were handled manually across two locations, resulting in fragmented information, limited visibility, and a higher risk of errors.
It worked — until the business grew.
Then the cracks appeared.
Transaction tracking
Depended on human consistency. No centralized audit trail. Operational visibility was fragmented by design.
Inventory visibility
No synchronized stock view across stores. Inconsistencies were only discovered after the fact.
End-of-day reconciliation
Repetitive manual checking, prone to errors. Time spent calculating instead of serving customers.
Workflow fragmentation
Information scattered across WhatsApp threads, handwritten notes, and mental models. Functional, but not sustainable.
The Insight
The first observation was that the business didn't organize inventory the way standard POS systems expected. Instead of SKU-based product catalogs, everything ran on category logic, flexible pricing, and in-transaction negotiation — the reality of how an outdoor fashion store actually operates.
The challenge was not digitizing transactions. It was translating real-world retail behavior into software without disrupting how staff already worked.
That distinction shifted the project from "building a POS" to "adapting software around operational reality." Generic systems introduced mismatches at every touchpoint — rigid product structures, standardized pricing, workflows optimized for a different kind of store.
Design Priorities
P — 01
Fast transaction flow
Reduce friction at every interaction during active cashier operations.
P — 02
Flexible pricing
Support dynamic discounts and real-time adjustments without disrupting flow.
P — 03
Operational visibility
Centralize transaction and inventory data across both store locations.
P — 04
Low cognitive load
Keep interactions understandable for non-technical staff under real store conditions.
P — 05
Reliability first
Stability and usability over feature count. If the system goes down, operations revert to manual.
How The Workflow Changed
Transaction
Before
WhatsApp message to owner or notebook entry
After
Logged in real time with category, price, and discount
Inventory
Before
Manual stock count, no cross-store sync
After
Synchronized across stores via PL/pgSQL stock functions
End of day
Before
Manual calculation, repeated checking, error-prone
After
Centralized report, auto-calculated, immediately reviewable
Visibility
Before
Fragmented across WhatsApp, notebooks, memory
After
Unified dashboard with operational overview per store
Stack
Frontend
- Next.js 16 (App Router)
- React 19 + TypeScript
- Tailwind CSS 4
- Headless UI
- Recharts
backend
- Next.js API Routes
- Supabase Auth
- PostgreSQL
- PL/pgSQL stock functions
infrastructure
- Vercel deployment
- GitHub version control
- Row Level Security
Real-World Constraints
Building for daily store use introduced a different kind of responsibility. This was not a portfolio project with tolerance for bugs or downtime. When the system fails, the store reverts to manual operations.
Non-technical users meant clarity and simplicity were non-negotiable. Speed-sensitive transaction periods meant every extra tap had real cost. Inconsistent connectivity meant graceful recovery wasn't optional.
“The most valuable software is often not the most technically impressive — it's the one that integrates naturally into how people already work.”
Outcomes
Manual reconciliation replaced with centralized daily reporting
Inventory synchronized across both store locations in real time
Cashier transaction speed improved through simplified interaction design
Operational errors reduced through centralized, auditable data
“Setelah pake sistem itu, semuanya terasa mudah. Thank you pisan der.”
Reflection
The hardest part was not engineering the interface. It was understanding operational behavior deeply enough to know what the software should and shouldn't change.
Working close to real-world constraints — non-technical users, live transactions, genuine dependency — reshaped how I think about product engineering. Usability, workflow fit, and reliability matter more than feature novelty when software becomes infrastructure people depend on every day.
Previous
Lume