Built end to end · Warehouse operations
SPS warehouse app: Warehouse software shaped by daily use.
I built the app StoragePal staff use to receive items, record their locations, and prepare returns. I own its design, implementation, and production support.
- 120 / 120
- weekdays with a completed scan session
- 1,348
- completed scanning sessions
- 3,602
- recorded moves from one storage spot to another
Production use, 13 April - 25 September 2026. Counts reviewed 26 September.
The short version
- 01Workflow4 stepsReceive, check, locate, and return items, all from a phone.
- 02ScopeOnline onlyI removed offline mode before daily use. Much less code to maintain.
- 03RetriesSaved resultA repeated completion returns the first result instead of running again.
- 04LabelsLabel nowStaff label items before approval. SPS checks its guess afterward.
- 05Daily use120 / 120Weekdays with a completed scan session, 13 April - 25 September 2026.
- 06Reliability1,175 / 1,187Push jobs that worked on the first try, 28 June - 26 September. The rest worked on a retry.
Connect the booking to the warehouse floor
Before SPS, staff sorted out booking differences over email, and item locations were not always recorded. SPS puts the whole flow on a phone.
I built SPS end to end, from first commit to production. I also maintain the StoragePal platform it connects to, so both sides of the integration are mine to keep working.
Remove complexity the warehouse does not need
An earlier version worked offline. But every warehouse already had internet, and offline support was a lot of extra code to maintain.
Before: offline mode
Extra offline state to maintain, next to the main StoragePal platform.
After: online only
- Online
- Scanning needs a connection
- Saved
- Sessions live on the server and survive a reload
- Smaller
- Much less code to maintain
Removed before daily production use began.
The app does not queue offline writes. The result is a clear limit, and a much smaller system to maintain.
Make a retry understandable
Keep work moving across system boundaries
Each system owns its own data. Staff sometimes need to print a label before StoragePal approves a change, and SPS does not make them wait.
StoragePal owns
OrdersArticle IDs
SPS owns
Scan sessionsPhotosBay history
- PredictSPS predicts the article ID.
- LabelStaff label and place the item right away.
- ConfirmAfter approval, SPS checks its guess against StoragePal.
- FixA wrong guess flags the item for a new label.
Staff keep moving, and the rare wrong guess becomes a small correction later.
Check the behaviors that matter
Tests cover the cases that would hurt most on the warehouse floor.
- Repeated completion
- Duplicate approval
- Rejected returns restore locations
- Cancelled bay sessions roll back
Daily use shaped the small details.
One-tap verification
Checking an item takes a single tap.
A quieter Cancel
The Cancel button is less prominent.
Flexible name search
First name or last name first: both work.
Staff used SPS on all 120 weekdays from 13 April to 25 September 2026.
120 / 120weekdays with a completed scan session
- 1,348
- completed scanning sessions
- 7,470
- item verifications
- 8,847
- bay changes, 3,602 of them moves between bays
These counts are workflow events from the same period. They show steady daily use.
- 1,175 / 1,187
- push jobs worked on the first try, 28 June - 26 September. The other 12 worked on a retry, 3 seconds to 10 minutes later.
- 2,047 / 2,200
- hourly pulls finished without a recorded failed step. They are counted separately.
The testing numbers
The 15 September code had 659 test methods, run manually, plus 65 scripted agent scenarios: 57 browser and 8 API, with 28 documented runs in April and May.
Product walkthrough