Before I had platforms of my own, this is where I found out what production means when other people's operations depend on it.
The work was enterprise Django and Angular: REST integrations, database design, backend performance, AWS infrastructure, and backup processes that were tested rather than assumed. Some of it was passenger-facing for Northern Rail, which is a materially different kind of pressure to an internal tool — if it is wrong, it is wrong in public, for people trying to get somewhere.
The deploy that taught me
Something I shipped broke in production, and the cause was environment drift.
The code was correct. It had worked everywhere I had run it. Production simply wasn't the same shape as the place I had tested it — a difference in configuration that existed because staging had been allowed to drift away from the thing it was supposed to be rehearsing.
That is the unglamorous version of the story, and it's the true one. It isn't a dramatic outage anecdote. It's the ordinary way most incidents actually happen: not from a reckless change, but from a quiet assumption that two environments matched when nobody had checked recently.
What changed afterwards was the rehearsal. Staging had to actually resemble production — same configuration path, same assumptions, differences deliberate and known rather than accumulated. Once that was true, an entire category of surprise stopped happening.
I have carried it into everything since. AIRaware has staging and production environments defined in version control specifically so they cannot quietly drift apart, and that is a direct descendant of this.
Several at once
The other thing this taught me was less about code. Multiple client deliveries ran concurrently, each with its own deadline, stakeholder and definition of urgent. Holding several unrelated systems in your head, and being honest about which one genuinely has to move first, is a skill you do not develop on side projects — where the only stakeholder is you, and the deadline is always negotiable.