48 hours before launch, the backend dev quit

What was the job?

A sports media startup needed a front end built from scratch for two properties. DNVR was the established one. PHNX was the first build outside the home market, in Phoenix, carrying a large blog and ecommerce memberships.

I designed and built the full WordPress front end for both. Not a theme with the colors changed. Built.

The infrastructure belonged to a separate AWS developer. I coordinated with him across EC2, Elastic Beanstalk, RDS, S3 and Route 53, but it was his.

And then he quit

48 hours before launch.

Not "went quiet." Not "got busy." He got on a call with the CEO, told him where to go, turned to me, said "good luck," and hung up.

The site was disconnected from AWS. Mixed content errors, an incomplete setup, and the one person who understood any of it had removed himself from the project in about ninety seconds.

I want to be precise about where I stood, because it is the part that makes this worth telling. I was the front-end guy. I had coordinated with the AWS side. I had not built it, and I was not on call for it. None of that mattered by roughly hour three, because the launch date was not moving and there was nobody else.

What I actually did

First I stopped trying to fix it.

That sounds like giving up. It is the opposite. I had two days, no AWS ownership, and a stack I had only ever worked alongside. If I spent those two days teaching myself enough to repair someone else's half-finished infrastructure, I would have been the least qualified person in the building doing the most important job, and I would probably have missed.

So I changed the goal. Instead of fixing it, I made it fixable by somebody who could.

I learned enough AWS, fast, to understand what was in front of me. Not to repair it. To be able to describe exactly what was broken and why, in language another engineer could act on without rediscovering it themselves.

Then I went to the CEO directly. Here is what is wrong. Here is what I think it takes. Here are your options, and here is how long you have to choose.

We brought in a replacement developer. I handed him a real description of the failure instead of a shrug, got him oriented on the system, and stayed on the front end while he worked the infrastructure.

It launched. Hours to spare.

One thing I want to keep straight, because it gets flattened every time this story is retold: I was not the emergency hire. I was the person who found one, briefed him, and kept the thing moving while he came up to speed.

Decisions

Diagnose first, recruit second. Bringing in a developer with 48 hours on the clock only works if he can start on the actual problem instead of spending his first day discovering the system. Learning enough AWS to hand over a real description of the failure is the entire reason that handoff took hours instead of days.

That is not heroics. It is doing the boring part first, under pressure, when every instinct is telling you to start typing.

Go straight to the CEO. With the infrastructure owner gone and a fixed date, the only decision that mattered was move the launch or replace the developer. That was not my call. My job was getting it in front of the person whose call it was, early enough that he still had room to make it, and clearly enough that he could decide without a second meeting.

Twelve years in restaurants taught me that one. When something has gone wrong, the person who needs to know finds out from you, immediately, with a recommendation attached. Not later, and not from someone else.

What happened after

The relationship kept going. I improved AWS security that had been left weak, fixed front-end bugs across both properties, and worked on UX.

An honest note on the stack

I coordinated on the AWS side and worked in it directly during the incident and afterward. I am listing those services because I genuinely worked in them under pressure, not because I architected them. I did not.

The WordPress front end for both properties is mine, start to finish.