Monday, 9:47 a.m. I’m in the standup, coffee still hot enough to be a weapon, when Yusuf raises his hand before I even get through the sprint goals.
“I’ve been thinking,” he says. “We need to talk about the backend stack.”
I know this voice. This is the voice of someone who found a blog post at 1 a.m. and now believes he’s discovered fire. I’m already tired, and we’re seven minutes in.
Team Slack — #eng-general, 1:47 AM
Yusuf: ok hear me out. Nexus Framework. I’ll have benchmarks by standup.
Seen by nobody. Reacted to by nobody. Read in full seven hours later by a very tired Paul.
(This is not Yusuf’s first framework. In the two years I’ve managed him, he has pitched Nexus, plus at least four others whose names I no longer remember except that they all sounded like energy drinks. We do not use any of them. He remains undeterred, the way a golden retriever remains undeterred by a closed door.)
“The backend stack is shipping features,” I say. “What’s the actual problem?”
“It’s slow. It’s bloated. The latency on the search endpoint is unacceptable. I read this comparison yesterday—” he pulls up a benchmark on his monitor, “—and if we migrated to Nexus Framework, we’d cut response times by forty percent. Maybe more.”
Nexus Framework. Never heard of it. That’s not a sign it’s bad—it’s a sign Yusuf found it in a Reddit thread about emerging backends. And here’s the problem: he’s not entirely wrong. Our search endpoint does drag. It’s been dragging for six months. Every sprint, someone mutters about it. It sits there like a stone in a shoe—annoying enough to notice, not annoying enough that we’ve prioritized the work to fix it properly.
Dex perks up. This is his mode: when there’s a chance to do something right instead of patching the thing that works badly, he’s interested. “A full rewrite would let us rethink the data model,” he says. “We could fix the N+1 query problem we’ve had since the acquisition.”
Now Marcus shifts in his chair. He doesn’t say anything, but I can see it: the appeal of starting fresh when the current code feels like a haunted house. No ghosts in new code. Not yet.
I feel it too. I won’t pretend I don’t. There’s this moment where a rewrite sounds like freedom. Like we could burn down the whole rotting structure and build something clean. Something where all the mistakes we made in 2021 don’t exist anymore. Something nobody has to apologize for in a code review.
Then I remember: I have a customer deliverable due in six weeks. Not a big one, but real money on it. And the second I greenlight “let’s explore Nexus,” someone’s math is going to look like this: exploration becomes planning becomes architecture becomes a sprint of groundwork before we can even move the first service. That’s two weeks gone. Then we hit some edge case nobody anticipated in the benchmark. That’s four weeks. Then Yusuf realizes the migration strategy is more complex than the blog post suggested. That’s eight weeks.
I’ve seen this movie. I’ve lived this movie. Three years ago, I approved a “quick rewrite” of the payment processor in a newer version of our stack. Quick. That’s what the senior dev said. “Quick, cleaner, better.” Four months later, we’re patching the old system because the new one isn’t ready, and now we’re maintaining both.
“Okay,” I say. “The search latency is real. Nexus Framework might be real too. But I need to understand the actual cost.”
“The cost is technical debt,” Yusuf says. “We’re paying it every day.”
“No,” I say. “I mean the cost of doing the rewrite. Not the abstract debt we’re carrying. The actual sprint time. The risk. The fact that none of us have shipped anything in Nexus before.”
Priya, who’s been quiet, speaks up from the corner where she always sits. “And what ships Friday if we do this.”
“And what ships Friday if we do this.”
That’s the sentence that breaks the spell. Friday. The actual Friday. The one that matters.
I can see Yusuf absorbing this. He’s smart. He knows the answer: nothing ships Friday if we start a rewrite today. Some feature goes back to the customer marked “delayed.” Some commitment we made gets smaller.
“Here’s what I’m thinking,” I say, and I’m not making this up as I go, exactly, but I’m close. “The search endpoint is a real problem. Not an emergency, but real. What if we do this: you and Dex spend the next three days—just three days—actually testing Nexus on a sandbox version of our search index. Not planning to rewrite. Actually seeing if the benchmark holds up with our real data. With our schema. With the way we actually use it.”
Yusuf nods.
“If the numbers are still there,” I continue, “we add it to the quarterly planning meeting. We get a VP in the room. We talk about what ships and what doesn’t if we allocate a team for six weeks. But we don’t decide that now. We decide that when we know what we’re deciding about.”
“That’s fair,” Yusuf says. And he means it. I can tell because he doesn’t argue.
The meeting moves on. Marcus relaxes. Dex looks like someone just told him he might, someday, get to do something properly. I go back to the sprint goals, which nobody heard the first time.
Later that day, Yusuf sends me the first test results from his sandbox. They’re… actually pretty good. Not blog-post-forty-percent good, but real improvements. I message him back: “Good work. Keep going with the sandbox thing. We’ll know what we’re working with by Friday.”
He responds with a thumbs-up emoji. Not the emoji of someone who got told no. The emoji of someone who got told “yes, and let’s be smart about it.”
What I Learned
(And What You Can Steal From It)
My mistake wasn’t saying no to the rewrite. It wasn’t saying yes either. It was almost saying yes in the moment when the current system was most annoying, which is exactly when my judgment is worst. When something is dragging, when it’s tedious, when you’re tired of maintaining it—that’s precisely when a shiny new tool looks like a rescue instead of a risk. I almost got swept up in it because Yusuf’s problem was real. The solution just wasn’t “burn it down and start over.” It was “let’s understand this before we commit.”
If you freelance, you’ve had my exact conversation, just with a client instead of a VP. You’re deep in a project built on technology that was great three years ago and now feels clunky. Or you’re managing your own business and thinking about switching platforms entirely because the current one is slow or annoying or filled with features you don’t use. The pull is strongest exactly then, and that’s the trap. You decide in the moment of frustration instead of deciding with criteria you set when you weren’t frustrated.
Here’s what I’d tell you to do this week: Write down the actual criteria for what would make a major change worth it. Not “if this gets annoying enough.” Real criteria. “If the cost of staying is provably higher than the cost of switching, measured against actual timelines and deliverables we’ve committed to.” Then, the next time you’re standing in your own equivalent of that standup—tired, frustrated, staring at something that drags—you have an answer that isn’t made in the heat of the moment. You just check the list.
