Context
TCWGlobal's core client-facing platform ran on an aging PHP stack. Nothing meaningfully new had shipped to clients in a long time, and there was real internal pressure to visibly modernize — starting with a rebrand and UI facelift the CEO and CTO wanted to move on quickly.
Problem
I pushed back on rebrand-only as the plan. A visual facelift on top of the same legacy PHP stack was, in my read, lipstick on a pig — it would look different without fixing anything structural, and it would still cost real engineering time. Underneath the visual ask was a real, unmet need: a genuinely new international order/quote procedure that compliance, staffing, and the MSP team all needed and didn't have.
My Role
The direction itself was above my pay grade — the CEO and CTO wanted the rebrand — so I didn't try to block it. Instead, I used the project to build the thing underneath it: I owned the international quote flow end-to-end, the most cross-functionally complex initiative I led at TCWGlobal. That meant coordinating requirements across compliance (international labor law), staffing (how the team would actually use it with clients), the MSP team (VMS usage for dedicated clients), and training (how clients would be onboarded to it) — while also running the visible rebrand work: mockups with designers, flow cleanup with UX based on client feedback, and staying within brand guidelines with engineering.
Team & Stakeholder Dynamics
I ran a purpose-built task force with one embedded developer specifically to think through architecture, and validated the flow with them weekly. Engineering as a broader group was used to ticket-to-ticket work rather than holistic ownership of a flow this size, which meant translating the same context repeatedly instead of it being absorbed once — a real drag on velocity that compounded over the project's length.
Process & Decisions
The day-to-day rhythm was a repeating cycle: build the flow end-to-end in Miro, work with designers on mockups, validate weekly with the task force, surface roadblocks, iterate, validate again. Nine months in, the CEO killed the project — the rebrand-only visible layer hadn't shipped either, and from his seat, nothing had shipped to clients in too long. The engineering team's ticket-to-ticket gap had genuinely compounded the delay, and I hadn't surfaced that resourcing risk early enough, in language that would have landed with the CEO before sunk cost set in.
Outcome
The rebrand and the quote flow, as originally scoped, never shipped. But the process and cross-functional buy-in I'd built — the relationships with compliance, staffing, MSP, and training, and the fully mapped-out flow — didn't disappear with the project. When the CEO pivoted to rebuilding faster with AI shortly after, I worked directly with him to vibe-code and QA the replacement, using everything already validated from the killed project to move faster. That became the actual platform migration — off the legacy PHP stack and onto Next.js, serving 100,000+ users with page load times cut 50% — built and shipped in a fraction of the original timeline, with a brand-new international client onboarded on it.
Reflection
Three things I'd do differently, in hindsight: surface the timeline risk earlier and in the CEO's language — a plain "this approach costs X months, this one costs Y, here's what breaks" framing, before nine months had passed and sunk cost made the conversation harder. Flag the engineering team's ticket-to-ticket gap as a resourcing risk in week one or two, not let it surface later as the reason for the slip. And build in smaller checkpoints and demos throughout instead of one long stretch with no visibility — that buys patience and gives everyone a chance to redirect before frustration builds. The project itself got killed, but the underlying work didn't go to waste, and that's the part I'd actually protect if I did it again: build in a way where even a killed project still pays off.