Trade-promotion platform

The problem

The platform plans promotions for a manufacturer's products in retail chains: who runs what, with which mechanism, in which stores, out of whose budget, and how the resulting cost is allocated in accounting. It was built by an external development team that is no longer on it. There was no handover.

The business owners and a product manager needed answers about a production financial system (what it does, where the rules live, what reaches accounting and how) and nobody in-house could give them.

What I did

I kept it running and shipped changes: front-end features on the React and TypeScript UI. They include a reporting download for a discount mechanism across two customer channels and terminology changes that run through a whole functional area.

The larger piece of work was reverse-engineering the system, with agentic tooling under a citation-checked process, into the reference documentation the product manager and business owners now work from: the module map, the accounting allocation logic and its field matrix, and a database analysis for the controlling department.

A decision and its cost

The findings went to the product owner and business owners as open questions, not as a defect list. Every item carries a question instead of a verdict, because an external team's decision whose reasons I do not know is not a bug found.

Citations make documents slower to write and less pleasant to read. For the document a business treats as its source of truth about a financial system, that trade is not close: a reader who doubts a sentence can check it in ten seconds.

What I would do differently

My production contributions here are on the React and TypeScript side; my Java work has been reading the estate closely enough to document how it behaves. If the platform were mine to change, I would first get the business to settle the open questions, since each answer decides whether a finding is a defect or a design, and only then start changing code.