The most expensive bug in any project is the one written into the requirements before a single line of code exists. Here's why I spend the first weeks of an engagement not building, and what I'm listening for.
The most expensive bug in any project is the one written into the requirements before a single line of code exists — and no amount of clean architecture will refactor it out.
I've watched capable teams ship exactly what was asked for, on time, well-tested, and still fail. Not because the engineering was weak, but because nobody had sat with the business long enough to agree on what actually needed to be solved. The code was fine. The brief was a guess dressed up as a specification.
That gap — between what a client asks for and what they actually need — is the part I do. And it's the reason I spend the first weeks of an engagement not building.
#The expensive silence
Most briefs arrive already solved. A client hands you a document that says "we need a dashboard," and buried inside that request is a chain of assumptions nobody has said out loud: which decisions the dashboard is supposed to support, who actually looks at it, and what they'll do differently once they can see the numbers. Build against the document and you get a dashboard. Build against the need and you sometimes discover they didn't need a dashboard at all — they needed one alert, sent at the right moment, to the right person.
The silence around those assumptions is expensive because it compounds. Every downstream decision inherits it, and by the time it surfaces — usually during UAT, when someone says "oh, but that's not how we actually work" — it's the most costly possible moment to find out.
"Build against the document and you get a dashboard. Build against the need and you might discover they never needed one."
#Embedding beats receiving
A forward-deployed engineer doesn't take a finished brief and disappear to build it. You embed with the client's own team — sit inside their operations, watch how the work really flows, and find where time and money actually leak. Only then do you define what gets built. The brief becomes an output of discovery, not an input to it.
This feels slower. It isn't. The weeks spent understanding the problem are the cheapest weeks in the entire project, because they're the only weeks where changing your mind costs nothing but a conversation.
#What "reading the signal" looks like
Discovery isn't a vibe; it's a discipline. A few things I'm always listening for in the first sessions:
- The decision behind the request. "We want X" — okay, what decision does X let you make that you can't make today?
- Where the current workaround lives. If the problem were unbearable, they'd already have a spreadsheet, a group chat, or an intern patching it. Find that; it's the real spec.
- Who disagrees in the room. Consensus in a kickoff is usually just politeness. The quiet objection is the requirement nobody wrote down.
- What "done" means to the audit. In regulated environments, a system isn't finished when it works — it's finished when it can be audited. That reframing changes the whole build.
#The part I won't hand to AI
I lean on AI heavily across delivery — discovery notes, documentation, specification drafts, QA scenarios. It's the multiplier that lets a small team move from first hearing to signed-off spec in a fraction of the usual time. But the judgement about which problem is worth solving stays human. AI is extraordinary at answering the question you give it. It has no opinion about whether it's the right question. That opinion — formed by sitting in the room, reading the signal, and being willing to tell a client the thing they asked for isn't the thing they need — is the whole job.
Clean code is table stakes. Clarity about the problem is the differentiator. If you get the brief right, most of the hard engineering decisions make themselves. Get it wrong, and no framework will save you.