What is a Diagnose sprint?
Diagnose sprint definition
A Diagnose sprint is Traide’s first engagement with a client: two weeks, fixed in scope, that end in a decision rather than in code. The engineer maps the workflows that cost the most hours and the systems each one touches, measures them on the client’s real data rather than on estimates, and delivers two things: a prioritized opportunity map, ranking where software or AI would pay back and where it would not, and one costed build proposal for the first item on that map.
No code ships in those two weeks. That is deliberate. The most expensive mistake in an AI project is building the wrong thing well, and the sprint exists to find the right thing before anyone commits to a build. What it does produce is evidence: the hours a workflow takes, the handoffs where work waits, the data that exists and the data that does not, and the first cases of an evaluation harness, written from real examples.
What the client receives
The opportunity map, with each candidate scored on the hours it would return, the systems it touches and the risk of getting it wrong. The build proposal, with scope, milestones, the integrations it needs and the cost. The measurements the two rest on, so they can be checked. And a recommendation, which may be not to build: some problems in the map are process problems, and the sprint says so.
What it commits you to
Nothing beyond the two weeks. The proposal is priced per contract and stands on its own: a client can take it to another firm, build it in-house or shelve it. The engagement the sprint is designed to begin continues into a Prototype on your own data, then a Build, then an AI ops retainer. The sprint is one of the ways to engage described on the Services page.