The catalogue that builds itself, and the invoices behind it
A seller between producers and buyers was spending most of the week rebuilding catalogues, writing the same outreach by hand and typing invoices out of orders. We built the portal that does all four from the same data, so the week goes on selling instead.
- Client
- Under NDA
- Sector
- Wholesale distribution
- Year
- 2026
- Built with
- Next.js, TypeScript, Postgres, myDATA, Resend
The problem
A seller sitting between producers and buyers spends most of the week on work that produces nothing: rebuilding a catalogue in a document every time a price or a stock level moves, writing the same outreach email by hand, chasing producers in a separate thread, and typing invoices from the orders that came out of all of it. None of it is hard. All of it is the reason nobody has time to look at which products are actually selling.
What we did
- 1
The catalogue is generated rather than maintained. It is a view over the product data, so a price change is one edit in one place and every catalogue that goes out afterwards is already correct.
- 2
Outreach and producer email live in the portal rather than in an inbox, which matters less for the sending and more for the record: who was contacted, about what, and what came back is attached to the product instead of buried in a thread.
- 3
Invoices are issued from the order rather than retyped from it. This is the least interesting part of the build and the one that removed the most work, which is usually how it goes.
- 4
Analytics last, on purpose. Reporting on a process nobody trusts yet just produces arguments about the numbers; once the catalogue and the orders were the same data, the analytics had something solid to count.
Where it got to
The week stopped being spent on retyping. What changed beyond the hours is that the seller can now answer which products move and which producers deliver, because the catalogue, the outreach and the invoices are finally the same data instead of three documents that disagree.