← All work
Amazon seller analytics platform

MarginLynx

A profitability dashboard that tells you exactly which number it is showing you.

The MarginLynx dashboard: profit and sales rings, ROI and margin tiles, a product breakdown and a daily sales chart
Role
Founder · Azurcrea · Product Design, UX/UI, Front-End
Timeline
2026 · Ongoing
Industry
E-commerce analytics
Tools
React, Fastify, Prisma, Amazon SP-API
01 — Overview

Nine marketplaces, one profit number.

MarginLynx pulls an Amazon seller's data straight from the marketplace API and works out what they actually earned — per order, per SKU, per day — across France, Italy, Germany, Spain, the UK, Ireland, Belgium, the Netherlands and the UAE.

I designed the product surface: the dashboard, the application shell everything else lives inside, the settings architecture, and the identity.

02 — Problem

"Profit" is not one number.

Ask two tools what a seller made last quarter and you can get two very different answers, both arrived at honestly. Cash received is not the same as revenue earned. A figure taken before the VAT return settles is not the figure after. Neither is wrong — but a dashboard that prints a large number without saying which basis it used is quietly making that choice on the user's behalf.

The design problem was less "how do we show profit" and more "how do we make the basis impossible to miss", for someone who is going to act on it.

03 — Approach

Say the basis on the tile, and show the whole derivation.

The headline figures carry their own caveat in place. A line under the profit ring names the basis the number is on — on an earned basis it reads that profit is net of the VAT you collect and remit; switch the control to cash and it says so instead. The filters that change it (lifetime or period, earned or cash, all channels or FBA only, which of the nine marketplaces) sit along the top where they read as part of the number rather than as buried settings.

Behind the profit tile is the part I would point at first: the full derivation, as a plain list. Sales at the top, then every deduction named in the seller's own language — fulfilment, referral commission, subscription, digital services fee, inbound shipping, storage, regulatory and EPR charges, refund fees, reimbursements back, cost of goods, VAT owed — down to the profit figure. No aggregated "fees" bucket. If you disagree with the number you can find the line you disagree with, which is the only version of trust that survives contact with an accountant.

Two structural pieces came out of using it rather than designing it. The application shell was rebuilt so the navigation stays pinned to the viewport instead of scrolling away with the document — on a dense analytics page you are constantly moving between sections, and losing the nav each time was a small tax paid hundreds of times. Settings grew from two tabs to six, mostly by surfacing configuration that already existed in the backend and had simply never been given a front end.

The identity went through a real correction. The mark is a lynx eye: an almond outline with a vertical slit pupil. The first attempt was a ring-and-reticle version that looked fine in the design file and, once rendered at actual favicon sizes, read unmistakably as a map pin — and the iris and slit together resolved into a bold letter O. It was redrawn rather than defended.

04 — Outcome

In production, on a real trading account.

MarginLynx runs in production against a live multi-marketplace account rather than seed data, which is the only way this particular product gets tested honestly — reconciliation bugs do not show up against fixtures, they show up when the platform's own settlement report disagrees with you by a few cents on a Tuesday.

There is no public marketing site yet, so there is nothing to link to here. The screenshots are the real interface, running on demonstration figures rather than a seller's actual trading data.