Jayga
A warehouse system that cut order processing from 3 days to 2–3 hours
Jayga rents storage to small businesses that cannot afford a whole warehouse. The space is divided into grids: a grid is what a customer rents, what their stock is assigned to, and what their bill is calculated from. I led product on the internal system that tracks all three.
3 days → 2 to 3 hrs
Order processing time
3x (modeled)
Projected revenue per m²
3 apps
Client, admin, and warehouse floor on one record
- Role
- Product lead
- Team
- 8 people, no dedicated researcher
- Timeline
- 4 months, 2023. Two months design
- Platforms
- Web (client, admin), mobile (warehouse floor)
- Tools
- Figma, Notion
Three decisions that shaped the product
- 01
One unit carried pricing, storage, and billing at once, so the business could see which space earned money.
- 02
Client, admin, and floor staff each do a different job on the same data, so every fact is entered once.
- 03
Contextual inquiry found stock laid flat on the ground. Rack level pricing was the fix. The pricing was accepted but never built, so the gain stays a projection.
Problem
Disconnected work
Initially, inventory and warehouse work ran on spreadsheets, handwritten logs, and separate steps. Orders took days to process and warehouse space went to waste. Storage, billing, and delivery each stayed hidden from the others.
I designed one system to connect storage, payments, and delivery. The first development phase ran on the founder's knowledge of the business. Research to optimize inventory storage came later, once real orders were being processed.
Process mapping
Two phases
Phase one · 4 months, 2023
Core system
Phase two · After the tool was live
Optimization research
Approach
How the build ran
I started with the flow. I gathered the requirements through stakeholder interviews with the team. I also ran a small market survey on the problems Bangladeshi businesses have with inventory storage. Those requirements went into process maps, and once the team agreed on the flow I moved to rough wireframes. Built in 2023, with no AI help.
Process, pace, and the delivery mapLean-Agile loop, the team, and the style guideShowHide
- —I used a Lean-Agile method throughout, to keep a close loop with the founder and the engineers.
- —The founder was the subject matter expert, and the engineers were the ones who would build it.
- —A project charter, a Kanban board in Notion, and short sprints kept the work moving.
- —Flow, agree, design, build, repeated in phases across a four month build. Two of those months were design time.
I set a simple style guide early: consistent color, type, and input style. That kept the design system light and flexible, and it grew as requirements settled.
The delivery map: how feedback from the founder, design, and building stayed in step
Phase One
Process mapping and core system
Four months in 2023, on the founder's knowledge of the business. This phase shipped the client dashboard, the admin console, and the grid model the business prices against.
Three apps, one shared record
Three connected apps on one shared record. An action in one shows up in the other two, so each fact is entered once.
The order flow: client to admin to warehouse, and the status travels back on its own
The delivery blueprint runs the other way, and the daily bill follows the emptied grids
Client dashboard
Web · Client
Takes the order
Admin console
Web · Admin
The desk work: requests, billing, and oversight
Warehouse Manager
Mobile · Floor
The floor work: assignment and stock checks
One screen from each web app shows the split.
Admin console: active grid requests by warehouse, user, item, quantity, length of stay, and status
Client dashboard: space used, open requests, and the running daily bill
The grid: what it is and what it costs
A grid is the unit the business sells.
Problem
Space was rented in blocks of square feet, so a half empty rack earned the same as a full one. Nobody could see which space was making money.
Decision
I split the floor into grids: fixed size, assignable one at a time, each with an ID. A grid is what a client rents, what stock is assigned to, and what a bill is worked out from.
Why
That one unit is what makes the rest of the system work. Every item belongs to a named grid, so the physical work turns into data: grid IDs, item counts, and check status. Empty space becomes visible, and good space gets priced for what it is worth.
The price is set per grid by:
- —How close it is to the warehouse
- —The condition of the rack
- —How secure it is
An admin starts an order with the client's details and a warehouse. A client can also start one from the web portal.
Client details and warehouse, the only place a client record is created
The challan is attached in the same flow, so the paperwork stays with the order
Splitting one item across grids
Problem
One item often needs more than one grid.
Decision
A quantity can split across several grids, or stay unassigned until later. I kept the split on a single item card.
Why
Warehouse staff told me why that matters. Logging each split as a new entry made stock hard to trace back to its delivery.
One grid at a time
Problem
Managers said batch assignment failed whenever the space was uneven or half full.
Decision
Grids are assigned one at a time. The system makes you confirm one grid before the next opens.
Why
It removes the work of undoing a bad batch.
Tradeoff
Slower per click, faster overall.
Assign grids: quantity splits in place, one grid confirmed at a time
The Assigned tag exists because the backend updated grid space on a delay at this point in the build. The tag was the only signal a manager had for how many units were already placed. It is a workaround, and with more backend time it would be a live occupancy count.
Once the grids are set, the system rolls the splits into one summary before payment: item, grid, quantity. The admin checks the whole order before the client is charged.
Payment: the splits rolled into one summary, with duration, space, and the advance due
Phase Two
Inventory optimization research
Once real orders were moving there were people to learn from. Research drove a third app for the warehouse floor, the delivery flow, and the billing rework.
Field research
Contextual inquiry on site was about billing. I watched how space was used day to day, and how charges were worked out. Goods were left unstacked and racks were used inconsistently, which reduced income per square metre. During one of the early visits I found inventory laid flat on the ground. The racks were not being used. I proposed rack level pricing. The modeling put that at roughly 3x the space and 3x the revenue per square metre.
The 3x figure is a projection, and I want to be clear about that. The pricing was accepted but not implemented, so the actual revenue increase is unknown. The projection is based on the space that was being used, against how much more could have been used with the racks priced and filled.
Contextual inquiry: watching a warehouse aisle during a working day, which is where the pricing problem showed itself
Market research
Market research answered a different question: who to sell this to. A survey of 23 businesses told me what they weigh when they pick a storage provider. It also told me how many of them need racking.
Survey findings: price, distance, security, and how easily goods could be retrieved mattered most
From there I mapped six possible customer groups: ecommerce sellers, event organizers, NGOs, distributors, farm businesses, and raw material suppliers. I then ran opportunity sizing on each one. I scored them in a cost and demand matrix on item value, upkeep, quantity, how easy the storage was to reach, and room to grow.
The customer segments scored
Opportunity sizing: cost against demand, used to pick which customers to chase
NGOs and raw material makers scored better than general ecommerce storage. The survey findings backed that up.
Delivery
Stock gets checked on the warehouse floor. It is one of the two flows the mobile app was built for, along with handling new order assignments. A delivery request still starts on the admin side: pick the user, then pick the items from what they have in storage.
Warehouse staff interviews shaped the grid assignment rules and showed why a mobile app was needed. Managers described the errors batch assignment caused, and how often a physical count and the record disagreed.
Delivery request: items picked from what the client has in storage, by grid and quantity
The request goes to the Warehouse Manager app. Warehouse staff work the floor, so they can act on it from the aisle.
The app lists the grids the items come out of before anyone touches stock. That list comes from the original assignment, so it is ready before they start.
The request as it reaches the floor
Which grids to pull from, generated from the original assignment
Counts confirmed against the record, or reported as a mismatch
Physical counts and the record go out of step in a real warehouse. Someone has to confirm what is on the shelf before the record changes. So the app reports a mismatch here, and the delivery waits until a person checks it.
Billing
Bills are built from the order record. Invoices use the duration and space already recorded at intake and grid assignment. The system calculates the bill. The admin reviews it and sends it.
Invoice: dates, space, and duration come straight from the order
Client side: upcoming and due, with the invoice as a file
On the client side, billing splits into upcoming and due, and the invoice downloads as a file. Clients run their own operations on a schedule. They need to see what is coming and keep a copy for their records.
The bill also falls on its own when a delivery empties a grid. Once the stock has left and the Warehouse Manager has confirmed it, the client stops paying for that space.
Outcomes
Faster work, priced space
Measured
3 days → 2 to 3 hrs
Order processing, before and after the system was in use
3 apps on one record
Client, admin, and floor staff working from the same data, each fact entered once
Modelled
3x income per square metre
A projection from grid pricing and from selling space that previously earned nothing
Hindsight
- —The Assigned tag works around a backend that tracked grid space on a delay. It should have been a live occupancy count.
- —The mobile app should have been in the first version. I built the admin console with no way for floor staff to write back. Admins worked from old numbers for months.
- —Keeping the design system light was right for the first phase and wrong by the second. I left it too late, and by then the three apps had visible inconsistencies.
Jayga shows a different side of my work than Zevian: more operations, service design, field research, and workflow structure. What the two share is the same: product direction, system design, and build quality grew together.