AI Adoption Intelligence
A platform for logging what teams actually do, finding the tasks worth transforming with AI, and tracking the productivity that comes back. Built for the leads running adoption inside their own department.
- Status
- Paused
- Stack
- Next.js, Supabase, Claude
- Type
- SaaS
The itch
The gap isn't access to the tooling. What was missing was an operating system for the people expected to run AI transformation inside their own department: somewhere a local lead could work out where their team needed to be, what should be automated, what else would have to change, and what happened to the time that came back, in a way that rolled up into the organisation's strategy rather than sitting beside it.
The other half of the itch was that this had to sit on top of operational, day-to-day data. A separate idea-capture tool would be another thing nobody updates. If transformation was going to be more than a pilot and an announcement, the evidence had to come from how the work was actually being done.
How I built it
I started it in Claude Code with the usual stack, Next.js, Supabase and Tailwind, and pointed the design hard at Microsoft's own admin surfaces, because that's where the product gap was. It needed to feel like Copilot's missing module.
The feature set followed the levels. An individual maps their role, evaluates each task for repetitiveness and judgement, classifies the likely solution on a six-step staircase from prompt template up to multi-agent orchestration, and builds a wish list for the time they'd get back. A team lead sees who has completed their evaluation, runs a workshop mode that puts opportunities side by side and merges the overlaps, and plans how freed capacity is reallocated. A department sets its future state, assesses maturity across its teams and keeps a register of strategic priorities. The organisation gets every opportunity ranked in one portfolio, duplication alerts, and a board paper that writes itself from what sits beneath it. Six guided builders, one per step of the staircase, turn a scored opportunity into a specification someone could build from.
Considerations
The hard part was the Russian doll. Each level had to be worth using on its own, so an individual got full value without anyone above them having started, and a department lead could define a future state without a single evaluation beneath it. At the same time, individual data had to roll up into team and department views so that leaders could decide what to transform, and the organisation could see global activity, hotspots and progress without anyone compiling it by hand.
How it landed
It didn't. I pressed pause, because at the time I didn't have the faith that teams would provide the data about their day-to-day work that the whole thing rested on. That day will come, but at the time of building, it didn't feel right.
Pausing gave me the question that led somewhere. How much of the intelligence about where work would benefit from AI could be built from data that already exists, without asking anyone to describe their job first? That question became the Corporate Role Analyser.
Personal takeaways
A product has to be right for the moment it would be released, not the moment it would be useful in principle. And starting simple would have been the better way to build it. The staircase, the six builders and the four nested views were all designed before anyone had entered a single task, and a smaller thing people could react to would have told me far sooner what the bigger thing needed, and saved the time spent on the parts it didn't.
Lessons for enterprise adoption
It isn't hard to imagine utopia. It's even easier to keep building towards one before the right tests have been run to validate the need. In this case, the test was whether other people understood the need to a level that would make adopting a solution possible at all. I skipped it, and kept building on that foundation as if it were reliable and proven.