Skip to content
TechFabric

Fixed fee · Two weeks · A plan either way

Find out what is actually stopping the AI work

A two-week fixed-fee assessment of whether your data, permissions, platform and team can support the AI systems you want to build. You get a written readiness scorecard, the specific blockers ranked by what they cost you, and a thirty, sixty and ninety day order to clear them.

Most AI programmes are not blocked by the model. They are blocked by data nobody trusts, permissions nobody can explain, and a platform where getting an agent to production means six approvals and a service account somebody created in 2023. Two weeks tells you which of those you have.

Length
Two weeks
Who it is for
Leaders with AI on the roadmap and no clear view of what is in the way
Bench
115+ engineers, 80 Databricks-certified
4 common questions, answered below ↓

What we look at

  • Which data an agent would need, where it lives, and who can currently read it
  • Permission model, and whether an agent could inherit it or would have to route around it
  • The path from a working prototype to something running under its own identity
  • Existing pilots, and why the ones that stalled stalled
  • Cost exposure: what a production workload would actually spend on inference
  • Who on your team would own it in month six

What you get

  • A written readiness scorecard, with findings ranked by what they block
  • The two or three things that have to be true before anything else is worth starting
  • A thirty, sixty and ninety day order, written so your own team can run it
  • A fixed-scope proposal for the first build, if you want us to do it

FAQ

AI Readiness Assessment: common questions

What is an AI readiness assessment?

A fixed-fee two-week review of whether your data, permissions, platform and team can carry the AI systems you want. It ends in a written scorecard with blockers ranked by what they cost, and a thirty, sixty and ninety day order to clear them. The page is /ai/readiness.

What access do you need?

Read access to the systems in scope and time with the people who run them. We do not need production data and we do not need write access. If your security process wants a named scope before anything is granted, we will write one.

What if the answer is that we are not ready?

Then you have that in writing, with the reasons and the order to fix them, which is a better position than finding out nine months into a programme. The fee is fixed either way and we would rather say so than start a build we know will stall.

How is this different from a strategy engagement?

A strategy deck tells you what to want. This tells you what is in the way of the thing you already want, in your systems, named specifically enough that an engineer could start on Monday. We are a software company, so the deliverable is written for people who will build.