Replacing a production system is rarely about starting fresh. Most of the time, it’s about preserving what already works, especially when that system has been shaped by nearly a decade of real-world use.

That was the situation here: a pricing and promotions engine deeply embedded in a retail environment, handling real-time logic across transactions and displays. It was reliable, but its behavior wasn’t fully documented because it had evolved through years of edge cases, fixes and production realities.

The timeline was four weeks, but we were able to reach feature completion in just seventeen days. Not because we moved faster, but because we approached uncertainty differently.

It Starts With Behavior, Not Code

We didn’t treat the legacy system as something to replace. We treated it as something to understand.

“A lot of the important stuff just isn’t written down anywhere,” shared the Rocket project lead. “You don’t find it in a spec or a doc. You find it when something breaks slightly, or doesn’t, and you realize the system is doing something very specific for a reason.” That reality changes how you start. Instead of designing forward, you work backward—from outcomes, from edge cases, from the moments where the system reveals itself. As he put it, the real questions weren’t theoretical. “What does it do when promotions overlap? What happens when pricing rules conflict? What if transactions show up out of order? That’s the real system.”

At that point, the work stops looking like feature development. It becomes something closer to reconstruction.

Short Cycles, Immediate Feedback

Once we had those scenarios, the process tightened.

“The biggest thing was just… don’t let anything sit,” he said. “If we thought something was true, we tested it immediately. If it wasn’t, we fixed it right there.” That loop—define, build, compare, adjust—ran continuously. There wasn’t a separate phase where everything came together at the end. It was always coming together. “You’re not building for two weeks and hoping it works. You’re finding out every couple hours whether it works.”

In most projects, unknowns pile up quietly and surface late. Here, they showed up early and often, and got resolved just as quickly.

AI Accelerates, Judgment Decides

AI was part of the workflow, but it didn’t replace anything fundamental.

“It’s great for getting you moving,” said the TPN. “You can jump between codebases, spin something up quickly, see where the gaps are. But you still have to decide what’s right.” That line didn’t blur. Every change still went through checks, review, validation against real behavior. “You can’t outsource judgment. What AI really gives you is speed to visibility—you see the consequences of a decision faster.”

By the third week, the new system was processing live transaction data and behaving the same way as the one it replaced. That was intentional.

“If you miss something small in a system like this,” he said, “it won’t stay small. It shows up later, and usually at the worst possible time. So the goal wasn’t improvement. Yet. It was alignment. Confidence that what had been built could stand up to the same conditions.”

The Through-Line

From the outside, it looks like a speed story. Seventeen days. A small team. A lot of output. But that’s not how it felt.

“It didn’t feel rushed at all,” he said. “If anything, it felt more controlled than most projects I’ve been on. We just weren’t waiting around to find problems—we were running straight at them.”

Most systems don’t fail because of technology. They fail because uncertainty is allowed to build unchecked. Stretch the feedback loop, and risk compounds. Tighten it, and progress does. In this case, that’s what made seventeen days possible.