What we actually audit in a technical discovery call

A rebuild is easy to want and expensive to justify, so a discovery call is mostly about finding out whether the thing in front of us is broken or just unloved. Six questions usually settle it.

What runs it. Not the framework’s name, its version, and the date anything was last updated. A stack two majors behind is a schedule, not an opinion.

Who can change it. Every system has a number: how many people can safely put a change live, and how long it takes them. When the number is one and the duration is “it depends,” that is the finding, and rewriting the front end will not move it.

Where the data lives, and who else reads it. The database is the part that cannot be thrown away. Much of the real cost sits here, in the export nobody documented and the report a finance team quietly depends on.

How it reaches production. Manual steps, a build that only works on one machine, a staging environment that does not match the real one. This is where “we will just ship it” goes to die.

What hurts, in the words of the people it hurts. Support messages and the workaround someone has taped over a gap are better evidence than any architecture diagram.

And the one a deck usually skips: what happens if nothing changes for another year. Sometimes the answer is that the site is fine and the problem is the content behind it, or the form that takes nine fields to ask a simple question.

A rewrite is a reasonable outcome. It just has to survive those six first, and we would rather say so on the call than three months in.