Easy-to-miss details
Quantity, set, condition, and variant compete with the rest of the invoice while an employee is moving between storage boxes.
Featured build · Product case study
In DevelopmentLoot Singles Fulfillment
A safer picking workflow for a trading-card shop preparing to scale beyond paper invoices.
- Role
- Sole developer & product designer
- Status
- In development · order-detail foundation built
- Outcome
- Order detail with set, condition and variant up front
- Stack
- React, TypeScript, ASP.NET Core, Azure SQL
Operating context
From a paper process to coordinated picking
The shop currently handles roughly 20–200 orders on a normal day and is preparing for a workflow that can support 4–5 simultaneous pickers as volume grows toward approximately 1,000 orders per day.
Implemented coordination
Available work is visible at a glance
The dashboard gives an authenticated picker a clear starting point, shows the current queue, and keeps actions for browsing, importing, and employee management together. This capture uses controlled sample orders; unavailable workflow states remain labeled as such.
The problem
Paper carries the order, not the task
Paper records the purchase, but it cannot protect the physical work of locating and verifying cards.
Invisible ownership
A printed invoice cannot enforce who is currently responsible for an order.
Dead-end exceptions
There is no structured way to report a missing or questionable card while preserving completed work.
The response
Guide the picker and protect the order
Loot Singles Fulfillment replaces the invoice during picking with safeguards matched to those risks.
Pick-focused hierarchy
The interface emphasizes the details most likely to prevent an incorrect pick.
Exclusive claiming
The server prevents two employees from acquiring the same order.
Needs Attention workflow
Employees can document an issue and hand off the order without pretending the pick succeeded.
Planned V1 workflow
The exception path is part of the path
Guided picking is the next phase of work. The branch below is intentional: an employee can report a problem without falsely marking a card as found.
Step 1
Available work
Choose an order or request the next one.
Step 2
Claim order
The server grants one employee exclusive ownership.
Step 3
Guided picking
Move through set-aware, one-card-at-a-time tasks.
Step 4
Pick complete
Validate progress before completing the pick.
Branch from guided picking
Needs Attention
Record the missing card or other issue without pretending the task succeeded.
Resume the path
Take over and continue
Preserve the issue and completed progress for an experienced employee.
Return to Guided Picking, then continue to Pick Complete.
Product decisions
Designing around real picking risk
Make high-risk information impossible to miss
Quantity greater than one is a common source of mistakes. The guided UI will use a prominent instruction such as PULL 4 COPIES and require explicit acknowledgement. Variant, set, and card identity follow in the visual hierarchy.
Design for the exception, not only the happy path
A picker should never have to falsely mark a card as found just to continue. Structured issues move blocked orders to Needs Attention, where another employee can take over without losing the original issue or completed progress.
No image is better than the wrong image
TCGplayer order data remains authoritative. An image appears only when catalog enrichment confidently identifies the exact card and printing; an ambiguous match produces no image rather than a misleading guess.
Product evidence
The implemented order view, annotated
This development view uses sample-order data and card-catalog images. The annotations identify information architecture already present in the application.
1
Visible ownershipThe active picker remains attached to the order.
2
Set contextEvery product keeps its storage-relevant set visible.
3
Risk detailsQuantity, printing, and condition stay together.
Engineering proof
Safety is enforced below the interface
Two pickers cannot both win
Claiming is a server-enforced rule. A conditional atomic database update succeeds only while an order is unclaimed, so two employees racing for the same work cannot both acquire it.
Pick Next Order retries after a lost race, while a filtered unique index stops one employee from holding multiple active claims.
Treat the PDF as an imperfect boundary
The importer handles multi-order and multi-page packing slips, rejects orders it cannot reconstruct confidently, and saves each valid order atomically behind a replaceable boundary.
It retains the original product description for traceability, excludes unnecessary customer data, and keeps condition and variant separate.
Ownership
One product, end to end
I am the sole developer and product designer, working with Loot Card Shop's owners as subject-matter experts. I translate their operational knowledge into requirements, interaction design, architecture, and implementation.
Work moves through clarification, technical planning, Red/Green/Refactor TDD, review, and specification verification. Tests include unit, integration, frontend, Playwright end-to-end, and real SQL Server concurrency coverage.
Current state
What is built and what comes next
The application currently runs locally and has not yet been used for live fulfillment.
Implemented
- PDF import
- Employee authentication and roles
- Responsive order views
- Card-image enrichment
- Exclusive claiming
- Release and manager force-release
- Employee administration
Planned V1
- One-card-at-a-time picking and set transitions
- Multi-quantity acknowledgement and progress tracking
- Issue reporting and Needs Attention
- Takeover, resumption, and completion validation
- An in-store pilot and feedback-driven refinement
Deliberate V1 boundary
V1 stops at Pick Complete
A future V2 would create a verified handoff into packing. A barcode or QR identifier would connect the physical order to the correct digital record before independent verification.
The V1 model supports that extension without pulling packing complexity into the first release. That keeps the current work focused on making picking safer and proving it in-store.
Next in the set
Featured build
V1 Complete
RoleSync
A Shopify app that ties member discounts to verified Discord roles.
- TypeScript
- React Router
- Shopify API
Case study 3 of 5. Up next: RoleSync.
Featured build
Live
pricewatch
A Go CLI that prices an 8,800-card collection on 1,000 API requests a day.
- Go
- SQLite
- GitHub Actions