LEPUS OS

Context

LEPUS is an Amazon business selling in the US and UK. I’m a co-founder, and I handle the engineering and the accounts. Before LEPUS OS, I tracked costs with spreadsheets alongside Amazon Seller Central reports.

The problem

The hard part was connecting information that appeared at different stages: what we paid the supplier, shipping and import costs, the cost of each unit in stock, Amazon’s fees, refunds, and the payout that eventually arrived. A spreadsheet margin could look healthy while quietly missing costs that belonged to that product. An illustrative example:

	Spreadsheet view	Full cost view
Selling price	20.00	20.00
Product cost	5.00	5.00
Freight, allocated to the unit	missing	0.80
Import duty, allocated to the unit	missing	0.40
Amazon fees	missing	6.00
Margin	15.00 (75%)	7.80 (39%)

Illustrative numbers, not LEPUS figures.

LEPUS OS brings all of those events into one traceable record, so every unit can be followed from purchase to payout.

What I did

The application is written in TypeScript on Node.js.

• Interface: Next.js and React, built around the questions I actually ask each day.
• Services: Node services hold the business rules, run Amazon synchronisation and handle background jobs.
• Database: PostgreSQL holds the records.
• Runs on: my own machine under WSL2. Background jobs handle repeatable synchronisation, and I can review or start operational actions from the interface.

The data model covers products, suppliers, purchase orders, receipts, inventory batches, FIFO cost movements, sales, expenses and cash accounts, and on the Amazon side, orders and order items, fees, refunds, financial events, settlements and payouts.

Amazon integration. The connection uses Amazon’s Selling Partner API. Orders are pulled by a background worker with checkpoints and retries, so an interrupted sync resumes where it stopped instead of starting over or duplicating records. Inventory and financial data feed the stock and settlement workflows. Imports are incremental: each sync processes only new or changed records rather than rebuilding everything.

Landed cost, batch by batch. Freight and import duty are allocated to the specific stock batch they paid for, and inventory is held as an asset until it sells. When a unit sells, FIFO takes its cost from the oldest batch, so each SKU’s margin includes its real product, freight and duty cost.

Settlement reconciliation. Each Amazon payout is broken into sales, refunds, fees, adjustments and reserves, and compared with what the recorded events say it should be, so differences surface instead of disappearing into a single net number.

Currency. Amounts in other currencies are converted using only the exchange rate actually applied, never an estimate.

Key decisions and tradeoffs

The hardest problem: a refund is not a return

A refund and a stock return sound like the same event, but often they are not. Amazon may refund a customer before the item comes back, and an item that does come back may not be sellable. If a refunded unit went straight back into stock, both inventory and profit would be wrong, and FIFO costs for every later sale from that batch would be wrong with them.

So LEPUS OS records the refund as a financial event, and records a physical return separately, only when there is evidence for it.

The same principle applies to settlements. The day a sale happens and the day Amazon pays for it are different days, so profit and cash movement are tracked separately rather than treated as one number.

Results

• One traceable record from supplier cost to Amazon payout, replacing manual matching between orders, inventory costs, Amazon charges and payouts.
• A data model designed for thousands of SKUs and a long transaction history, with incremental imports so syncs stay fast as history grows.
• 82 automated tests passing.

What’s next

• Broader automated coverage of Amazon data.
• Clearer exception handling when reports disagree or arrive late.
• A simpler interface for daily use.
• Document processing that turns supplier invoices and shipping evidence into reviewable cost data, with a human confirming extracted figures before they touch the records.

What I would do differently

• Start from real examples. I’d begin with a small set of real order-to-payout examples and define every event around them before building out the interface.
• Separate inventory, profit and cash from day one. Most rework came from untangling those three late.
• Design screens around questions. What sold, what it cost, what Amazon deducted, and what needs attention, with the detail available underneath instead of crowding every page.