Exponetix
Exponetix is an "inventory investment engine" for Amazon sellers — it reframes restocking as a capital-allocation decision, with budget planning and cash-flow forecasting to maximize return on invested capital.
Web + Product design + Frontend
Visit live projectThis case study is being filled in — process, artefacts and outcomes are added as I write them up.
- Year
- 2025
- Industry
- E-commerce SaaS
- Contribution
- Web + Product design + Frontend
- Status
- Live · in pilots
The product problem
The founder had the model — a way of treating Amazon restocking as a capital-allocation decision rather than a guess. What it did not have was a product: the working version looked like an old calculator, and the maths that made it valuable was the part nobody could reach.
Ownership & contribution
Around seven months on the product, in from the start with the founder and one developer — a team of three. I designed the product and built its frontend, and designed and coded the marketing site. The mathematical model is the founder's; the path through it is mine.
- Web design
- Product design
- Frontend
How the experience took shape.
Learning the domain
Sellers first, screens later
I studied how restocking and capital allocation actually work, and took input from sellers on Amazon and eBay — what they track, what they fear, and where the money decisions get made. The vocabulary of the product comes from them.
Setup
A path, not a form
Configuration used to be a wall of inputs. It became seven numbered steps that say what to set, what it unlocks and what happens next — so a seller can stop halfway and still know where they are.
Output
Answers you can act on
The model returns numbers; the product returns decisions — budget split as a treemap, a portfolio matrix separating products earning above the cost of capital from those below it, and a ranked purchase list that leaves as a CSV.
Setup, as a path
The founder's model needs a lot of context before it can answer anything. The setup turns that into a sequence a seller can walk, stop halfway, and come back to.
- 7
- steps, each with its own state
- 3
- screens carry the answer: allocation, matrix, list
- 01. Configure policies: Cost of capital and marketplace rules — the seller's own economics.
- 02. Amazon data: Inventory ledger and sales history uploaded.
- 03. Product settings: Each product configured — the per-SKU facts the model needs before it can rank anything.
- 04. Demand forecast: Forecast data uploaded, so the allocation is made against expected demand rather than last month's sales.
- 05. Supplier data: Supplier information uploaded — the constraints that decide what can actually be bought.
- 06. Run analysis: The model runs over everything configured.
- 07. Budget allocation: The seller sets a budget and gets a ranked purchase list.
Decisions → interface
The product
Four screens carry the whole idea: what the money is doing, what to configure, which products deserve capital, and what to buy next.
Budget allocation
Where the money goes, at a glance
Every product sized by the budget it earns, with the portfolio summary beside it — utilisation, expected net proceeds, units — and a line telling the seller how much further the budget could stretch before the next constraint.
Setup
Seven steps instead of a wall
Policies, Amazon data, product settings, demand forecast, supplier data, analysis, allocation — each step shows its state and what it blocks, so nothing is configured in the dark.
Client data is blurred in these screens.
Portfolio matrix
Above or below the cost of capital
Margin against cash conversion cycle, green above the seller's own cost of capital and red below it — the products quietly consuming money become visible.
Recommendations
The list you actually buy from
Ranked by expected financial performance, with quantity, unit cost and shipment value per line, exportable as a CSV so it can go straight to the supplier.
Planned tests · not results
What was checked
One thing was checked properly while designing, and the beta is checking the rest.
Input from sellers
Does the product use the words and numbers sellers already work with?
- Method
- Input gathered from sellers on Amazon and eBay while designing.
- Success signal
- Their vocabulary and the numbers they actually track became the product's language — the interface names things the way a seller would.
Work that moved the product forward.
In from the start, with the founder and one developer. What existed looked like an old calculator — the maths was there, the product was not.
Learned the domain before designing it — studied how restocking and capital allocation actually work, and took input from sellers on Amazon and eBay about what they track and where the money decisions are made, so the product would speak their language.
The engine is the founder's own mathematical model — my work was the path through it: a seven-step setup that tells the seller what to configure and what happens next, instead of a screen full of inputs.
Turned the model's output into things a seller can act on — budget split as a treemap, a portfolio matrix separating products earning above the cost of capital from those below it, and a ranked purchase list that exports to CSV.
Designed and developed the internal SaaS product, including its frontend.
Designed the marketing site and wrote its frontend.
- Year
- 2025
- Contribution
- Web + Product design + Frontend
- Industry
- E-commerce SaaS
Live · in pilots