Maintaining a multi-brand awards platform

The challenge#

The client runs several awards programs on one multi-tenant platform: entries, payments, judging, public voting, winners and galleries. The codebase is mature and shared by every program, so any change can have side effects in a program you were not looking at. They needed someone who could fix real issues without breaking the busy parts of the year.

What I did#

I started by making the platform safe to work on. I brought up a dedicated cloud development machine that runs the full application against the staging environment, so I can reproduce issues exactly as users see them without touching production.

Then I traced how the platform actually works, from how a property, season and category relate to each other to how an entry moves through judging to a winner, and wrote it up as a guide verified against the code and the database. That guide is now the reference for anyone joining the work.

For each ticket I record the before state in the database, make the change on a dedicated branch, check the fix against database ground truth, and run regression checks on the other awards programs that share the code.

How it works#

Changes move through a branch per environment, from development to staging for client acceptance and then to production. Every push to staging or production, and every production database statement, needs its own explicit go-ahead.

Results#

• Issues are reproduced on a full working copy of the platform, not guessed at.
• The team has a verified map of the data model and workflow.
• Fixes carry evidence: before and after numbers checked against the database.

This work is ongoing.

What I learned#

On a mature live system, the fastest way to move is to slow down first. An hour spent proving what the data looks like before a change saves days of chasing a side effect in another program.