The brief
What needed solving
Amazon sellers running influencer and affiliate programmes were coordinating them in spreadsheets: who was promoting what, which discount code belonged to which creator, and whether any of it actually sold. The platform's job was to turn that scattered bookkeeping into one operational view where a campaign, the creators in it, and its performance are the same object.
Approach
How it was built
01Model the domain, then draw the screens
Campaigns, affiliates, discount codes and orders were modelled as related entities up front. The interface follows that model — every screen is a view onto shared state rather than an isolated page with its own private copy of the data, which is what keeps numbers consistent across the app.
02Analytics designed to be read, not admired
Performance views prioritise comparison and decision-making: consistent axes, comparable date ranges, and clear empty and low-data states, so a seller can tell the difference between 'this campaign is not working' and 'this campaign has no data yet'.
03Consistency at multi-page scale
With many operational screens, a Tailwind-based component layer keeps tables, filters, forms and modals identical everywhere — a seller learns the interaction pattern once and it holds across the whole product.
Scope
What shipped
- Campaign creation and lifecycle management
- Influencer and affiliate roster management
- Discount code generation and attribution to creators
- Performance analytics across campaigns and creators
- Amazon API integration for seller and product data
- Consistent multi-page operational UI
Engineering notes
The hard parts
Challenge
Third-party marketplace data arrives on its own schedule, with rate limits and partial availability — the UI can't pretend it's instant and local.
Solution
Fetching was centralised with caching and clearly designed loading and stale states, so slow or partial upstream data is communicated honestly rather than surfacing as an empty table that reads like zero sales.
Challenge
Attribution state is shared across many screens, and duplicated copies would show sellers contradictory numbers.
Solution
A normalized Redux store with derived selectors per view: one fetch, one truth, and every screen recomputes from it instead of storing its own snapshot.
Outcome
Where it landed
- 01Live seller-facing platform at swaysive.io
- 02Spreadsheet coordination replaced by one operational view of campaigns, creators and results
- 03A component layer that keeps a large multi-page product visually and behaviourally consistent