Development
Mess Is a Signal, Not a Disqualifier
Brant DeBow
Written on May 20, 2026
An engineer on our team once pulled me aside about a client we’d been working with for a few weeks. He wasn’t angry. He was bewildered. He’d never seen a codebase in this kind of state — and being a thoughtful engineer, he was trying to make sense of it. He asked, quietly, “how does it get this bad?”
Before I could answer, Joe — my co-founder — had already heard him. He cut in, gently, with clarity: we don’t make our clients apologize for being a good fit. Restaurants don’t complain that people can’t cook for themselves at home. Our clients call us because their software is in trouble. That’s the engagement.
We don’t make our clients apologize for being a good fit
A lot of companies hesitate to reach out about their software because they’re embarrassed. The code is a mess. The build process is held together with duct tape. The original team is gone. The requirements are messy or nonexistent. They feel like they need to clean it up before they can ask for help.
That’s backwards. And it’s costly.
You don’t wait until you’re already getting better to call a doctor. You call a doctor because you’re sick. The whole point of the engagement is that you’re not in a position to figure it out alone. If you were, you wouldn’t be calling.
When a prospect describes their situation as “we know it’s bad, we don’t even know where to start” — that’s not a red flag. That’s the qualifying signal. Real systems, under real stress, that need help they can’t generate internally. That’s the work.
What “this bad” actually looks like
Early in BiTE’s history, we picked up a client who had acquired another company. The acquisition came with a mobile app. The app had a story.
A few months before the deal closed, the original team had been offered a slot in the iPad launch — Apple was looking for high-profile apps to feature, and they had two weeks to turn their iPhone app into an iPad app. So they did what people in two-week windows do: they made it work by any means available.
When we got the codebase, every iPad class was a copy-paste of its iPhone counterpart, jammed in by hand. Over 500 compiler warnings. The build took forever. Some iPad classes had the same names as their iPhone counterparts, differentiated only by tricky uses of letter casing. The team that built it — almost entirely contractors — had been let go before the acquisition closed. The acquiring company had a staff of strong engineers who didn’t happen to know Objective-C.
No one was asking us to come in and work lightly. They knew it was a mess. The acquired team had known it was a mess from the moment the iPad submission cleared review. The acquiring team had inherited that knowledge and was honest about it from day one.
So we did the work. We stabilized the build. We got compiler warnings and errors to zero. We carefully renamed and re-routed the iPad app into a sensible structure that shared code with the iPhone codebase without collapsing the two. And we spent time in their offices teaching the fundamentals of Objective-C and iOS development, so their capable engineers could come up to speed and take real ownership of the code going forward.
That engagement worked because everyone was aligned on the same goal with the same reality. No one was pretending the code was better than it was. No one was apologizing for it being in the state it was in. The shape of the mess was what defined the work.
The job is to make it great
It doesn’t matter how the codebase got into its current state. Whether it was a two-week feature submission, a series of departed contractors, a rushed acquisition, three CTOs ago’s architecture decisions, or just twenty years of accumulated trade-offs — none of that determines what’s possible next.
What matters is whether everyone is willing to look at it honestly and agree on what comes first. Stabilize the build. Make the behavior visible. Get the regressions under control. Then start making it better, incrementally, with discipline.
If your situation is “something isn’t working and we need help” — that’s all the qualification we need. The mess isn’t the problem. The mess is the engagement.
