· 1 min read · 13 views
Pricing a catalogue against a rate that changes every morning
Fresh-goods retail has a pricing problem most e-commerce never sees: the wholesale rate moves daily. Here is the data model that made it a one-field edit.
When I started building Chicken Master, the hardest requirement sounded like the simplest: "prices change every morning."
The naive version
Store a price on every product. Every morning, someone edits every product. Nobody does this for long — they stop updating, and the shop quietly sells at yesterday's margin.
Derive, don't store
The fix is to store the relationship instead of the price:
type Product = {
id: string;
name: string;
weightKg: number;
// price = mandiRate * weightKg * factor + adjustment
factor: number;
adjustment: number;
};
function price(product: Product, mandiRate: number) {
return mandiRate * product.weightKg * product.factor + product.adjustment;
}The manager enters one number — today's mandi rate — and the whole catalogue is correct.
What this bought us
- One field to edit per day instead of one per product
- A price history that is just a history of rates
- No stale-price bugs, because there are no stored prices to go stale
The lesson generalises: when a value is a function of something that changes, store the function's inputs.
Working on something like this?
Tell me the constraints, I'll tell you how I'd build it
These posts come out of client work — delivery platforms, inventory systems, and internal tools that a business actually runs on every day. If you're weighing a build and want a straight answer rather than a pitch, describe it in a few lines.
Start a conversation