Find the one broken thing

Most technology conversations start in the wrong place. Someone wants a platform. Someone wants AI. Someone wants to rip out the system that "everyone hates" and replace it with something modern.

I have sat in those rooms at Gopuff, at PE-backed operators, and at funded startups that were about to write a very large check. The pattern is the same. The thing they want to build is rarely the thing that is costing them money.

If you cannot name the choke point in one sentence, you are not ready to rebuild anything.

The spreadsheet is usually the truth

I have watched $50M companies run critical revenue processes in Excel because the "system of record" could not be trusted. That is not a technology preference. That is a diagnosis.

The ops lead is not being stubborn. They are protecting the number that actually matters: invoices that go out, jobs that get assigned, inventory that is real. If your new architecture does not move that number in weeks, it is a hobby.

At Gopuff we did not get to 200 engineers by starting with a clean-slate platform. We found the constraints that were blocking growth and we removed them in the order the business could feel. Some of that work was ugly. It also funded the next stage.

One metric, or you are guessing

A useful audit does not produce a 40-page deck. It produces one number you can defend in front of a sponsor who has been burned before.

• Hours lost per dispatcher per day, not "we need a better UX."
• Accrual leakage in dollars, not "the ERP is old."
• Time from quote to cash, not "we should be on the cloud."

If the metric is mushy, the project will swell. Consultants love mushy metrics. Sponsors should not.

Systems last, not first

I will look at the stack. I will also walk the floor, sit with the person who actually closes the books, and ask what they do when the software lies. That last conversation is usually worth more than the architecture diagram.

Once you know the broken thing, the build becomes obvious. Sometimes the answer is a thin proof on real data. Sometimes the answer is do not build. I have given that answer. It is cheaper than a rebuild that does not move the number.

Find the one broken thing. Prove it matters. Then, and only then, spend real money.