Model money properly.
Prices, costs and postage are held as integer minor units throughout, so a rounding error cannot quietly become a loss on a sale.
Seller operations
Bookmaster
The whole shop, in one view.
A multi-tenant operations platform for booksellers trading on Amazon, built and run in-house.
Multi-tenant architectureMarketplace integrationBackground job pipelinePricing engineLive
01 / THE CONTEXT
The world behind
the work.
A bookseller on a marketplace is really running several systems at once: a catalogue, a pricing position against other sellers, real postage costs, and the stock behind it all. Bookmaster brings those into one product instead of a spreadsheet and a memory.
02 / THE FOCUS
A considered
way forward.
The platform connects to a seller's marketplace account, keeps the catalogue in step, watches competing offers, and proposes prices that still clear a floor the seller sets. Pricing is never applied blindly — the seller stays the one who decides.
Thoughtfully
put together.
The priorities that shape the product and the experience.
Do the slow work in the background.
Catalogue sync, offer checks, price suggestions and postage learning run as scheduled jobs, so the interface stays quick while the data keeps itself current.
Treat credentials as dangerous.
Marketplace credentials are encrypted at rest and never returned by the queries that list accounts, so a mistake in one screen cannot leak them.
Behind the build.
The decisions that shaped how this was actually put together.
Why money is stored as integers
Every price, cost, and postage figure in Bookmaster is held as an integer in minor units rather than a decimal. Floating-point arithmetic introduces small errors that are invisible in a single calculation and material once they compound across a catalogue of thousands of items and repeated repricing. On a platform whose entire purpose is deciding whether a sale clears a margin, a rounding error isn't a cosmetic bug — it's the product being wrong about the only thing it exists to tell you.
Keeping the interface fast while the data stays current
Catalogue synchronisation, competitor offer checks, price suggestions, and learning real billed postage weights all run as scheduled background jobs rather than on request. The seller opens a screen and reads state that's already current; nothing waits on a third-party marketplace API responding. Splitting the work this way is what allows the data to be continuously refreshed without the interface ever feeling like it's loading.
Credentials treated as a liability, not a field
Marketplace credentials are encrypted at rest, and the queries that list seller accounts never return the credential column at all. That second part matters more than the first: encryption protects the database, but a listing endpoint that happily returns secrets means one careless screen leaks them. Designing the data access so the secret simply isn't available unless explicitly requested removes a whole category of mistake.
Something like this
on your mind?
Tell us about the challenge you’re working on. We’ll help find a useful place to start.
GOOD THINGS START WITH A CONVERSATION.
YOUR NEXT CHAPTER STARTS HEREGot a spark?
Let’s make it matter.
An ambitious idea. A fresh challenge.
Something you can’t stop thinking about. We’re listening.