Ask most agencies how they landed on your timeline and your price, and the honest answer is a loosely-informed guess wearing a proposal template.
That guess gets built on a sales call, a demo, a vague sense that “it’s a bit messy.” Rarely has anybody opened the codebase, so nobody knows if the login flow runs on three lines of duct-taped middleware or work someone took real care with. And somehow there’s already a number on a page and a team ready to start Monday.
We don’t work that way, because guessing is bad operations.
Picture sending a mechanic to fix a car they’ve never seen, working only from what the owner said on the phone, “it’s making a noise.” No sense of what kind, how often, or whether anyone’s already tried to fix it. Whoever shows up Monday needs that before they open the hood, or you end up with the wrong person, the wrong tools, in the wrong bay, taking three times as long as anyone promised, and a bill full of “extras.”
That’s what happens when you staff a software engagement before anyone’s reviewed the code. You commit a team of a certain size, with certain skill sets and seniority, to a job you haven’t seen yet. Maybe you needed a senior architect and sent a generalist. Or, the estimate assumed clean code and ran straight into legacy spaghetti. Three weeks in, someone hits the real problem, and now you’re re-staffing mid-engagement, resetting a timeline the client already signed off on, eating the gap out of your margin or your reputation. Usually both.
A codebase review does more than justify a sales pitch. It tells us who needs to be in the room, whether this is a two-person job for six weeks or a five-person job for four months, and whether the timeline going in the proposal is real or optimistic fiction. Get that wrong, and it’s not just our problem. It’s the developer stuck in an impossible spot on day one while the client watches a timeline slip for reasons nobody explained, and assumptions that you and your team made.
We are all adults here. Nobody wants to hear “we didn’t know what we were walking into” three weeks after signing. So we find out first, and we build the proposal around what’s there, not what we’re hoping is there.
A review before staffing means we’re not guessing, you get a timeline that holds, and whoever we put on your project isn’t discovering the real scope of the job on day four.
Normalize not knowing yet, and normalize saying so before you promise anything. Be the partner, not the ‘yes-man’.