01 · The challenge
Bugs users could see, and errors they couldn’t.
Planners and product managers used a low-code portal to manage new-product forecasts. They ran into layout and usability bugs, forecasts were sometimes wrong after item re-runs, and production had drifted from development, which made safe changes difficult.
02 · What I did
What I owned and built.
- Fixed front-end issues: sticky-column gaps, a date picker trapped behind sticky columns, and calendar date overlap.
- Added a product cover image popup that appears when users hover over a UPC.
- Root-caused a scaling error: re-running a reference item cleared the original 10-week forecast, and users didn’t know to re-enter it. I documented the cause and proposed an in-screen reminder, with an automated fix plus row locking as the alternative.
- Investigated an intermittent forecast overstatement that corrected itself the next day.
- Diagnosed prod-to-dev drift in the managed solution, evaluated tooling options, and recommended a governed dev-to-prod deployment process.
- Kept product managers informed during connection and refresh delays.
03 · Key decisions
The judgment behind the build.
Why document the root cause before automating?
A clear business rule fixes the problem today. Automation and locking can follow once everyone agrees on the behavior.
Why a governed deployment process?
Drift between environments makes every change a gamble. A defined dev-to-prod path makes changes safe again.
04 · Impact
What changed because of the work.
- Made the tool easier to use, with faster title recognition through cover images.
- Explained a forecasting error and set a clear business rule to prevent it.
- Laid the groundwork, and the requirements, for the Planning Data Hub 2.0 rebuild.
05 · What’s next
Where it goes from here.
Continue support and monitoring while users move to Planning Data Hub 2.0.
This case study is a sanitized reconstruction. Organization names, proprietary code, data, and internal schemas are intentionally left out.