Insights
Platform27 June 2026

I refuse AI projects without 30 days of platform discovery. Three CTOs taught me why.

Every AI project I have rescued had the same root cause. The platform was not ready. The team did not know. The vendor did not care. I will not take that work without 30 days of discovery first.

PatternPlatform substrate never measured

Two ways to start an AI project

One ships in 6 weeks and fails in week 8. The other ships in 10 weeks and runs.

A
Rush to AITime: weeks

W1-2

Architecture deck

W3-6

Build AI features

W6

Demo: success

W7

Go live

W8

馃挜 Incident

Root causes nobody saw coming:

Hidden cache layer 路 4-year-old retry queue 路 Engineer on leave 路 Capacity ceiling never measured

B
Discovery firstTime: weeks

W1-4

30-day platform discovery

W5-8

Fix platform, then build

W9

Go live

W10+

Running

What 30 days of discovery revealed:

Cache layers mapped 路 Capacity ceiling known 路 Failure modes documented 路 On-call ready

AI does not fail because the model is wrong. It fails because the platform was not measured.

In 2024 I took on an AI project with a 6-week delivery window and no discovery phase. The CTO was confident. The platform team was confident. The board had signed off. I shipped what they asked for. Eight weeks after go-live, the system started returning stale results during peak traffic. The root cause was a cache layer that nobody had told me about. It had been there for four years. Two engineers knew how it worked. One had left the company. The other was on parental leave.

That project taught me my first rule.

AI does not fail because the model is wrong. AI fails because the platform underneath was carrying load nobody had measured, depending on code nobody had read, and degrading in ways nobody was watching.

Six months later I took on a second AI project. Same pattern. Different cause. The data pipeline was running at 80% of its capacity on a normal Tuesday. Adding the AI inference workload pushed it over. The pipeline started silently dropping events. The team noticed three weeks later when the analytics reports stopped matching the source systems.

The third project was the one that changed my approach. The CTO had hired a major consultancy to do the AI integration. They had a beautiful slide deck. They had timelines. They had architecture diagrams. None of them had looked at the platform that the AI was being bolted onto. By the time they did, they had already burned six weeks of the engagement. The remediation cost more than the original project.

Since then, I do not start any AI engagement without 30 days of platform discovery. I am explicit with clients up front. If they will not pay for the discovery, I do not take the work.

Discovery is not an audit. It is a structured 30-day investigation into the systems that the AI will depend on. I trace every read path, every write path, every cache, every queue, every retry. I map the failure modes that the team is not watching. I check the deployment patterns, the rollback procedures, and the on-call rotation. I review the cost model and the capacity ceiling.

  • What is the current platform doing that nobody is measuring?
  • Where are the cache layers, queues, and retries that AI will amplify?
  • What breaks if traffic doubles? Quadruples? Goes to zero and recovers?
  • Who owns each component, and what happens when they are on holiday?
  • What is the platform actually costing, and where will AI inflate that bill?

At the end of 30 days, the client knows whether they are ready for the AI work or whether they need to fix the platform first. Half the time, the answer is fix the platform first. The other half, we proceed with full knowledge of what we are building on.

Every project I have completed using this method has shipped on time. None of them have had a major incident in their first 90 days. The first three taught me what was at stake. The discovery process is what I built to make sure nobody else paid that lesson again.

If a consultant wants to start your AI project without measuring your platform first, do not hire them. They are not going to find the cache layer. They are not going to map the queue. They are not going to ask the questions that matter. They are going to ship something that works in the demo and breaks in production.

ShareLinkedIn

Get the next one in your inbox

One short, opinionated field note per fortnight on platform engineering, cloud, and making AI work in production. No spam. Unsubscribe anytime.

Senna Semakula

Senna Semakula

Founder, Atruvo

Bring your architecture diagram, cloud bill, or last incident summary.

I will tell you what is actually breaking.

30 minutes. No pitch. Ranked risks and a clear next step.