CASE STUDY | SHORT READ
IDX Self‑Serve: Turning a specialist‑gated platform into a developer‑ready workflow
Document comprehension at Intuit used to require the IDX team for every new document type. This case study shows how we made the platform self‑serve, from schema through evaluation and deployment.
My Role
Team
Timeline
Scope
IMPACT
THE SITUATION
One team of specialists stood between Intuit and every new document workflow.
Document comprehension underpins some of Intuit's most critical work — identity documents, tax forms, purchase contracts, timesheets. But getting structured data out of any new document type meant one thing: filing a ticket with the IDX team, then waiting weeks for prioritization, coordination, and eventually a bespoke integration. Business Units had the use case; only IDX had the platform knowledge to ship it.
By the time we started this work, the average onboarding took 30 days and required back‑and‑forth across Slack, an internal portal, Google Forms, and GitHub. Teams that couldn't wait built workarounds. Teams that could wait, waited. Every one of them was on a different path.
THE INSIGHT THAT SHAPED THE BRIEF
The problem wasn't missing tools. It was missing standardization.
Talking to developers across BUs, the same pattern kept surfacing — not "we don't have tools." Something quieter, and further upstream.
WHAT THAT PRODUCED
A guided flow that branches inside itself — not across the org.
THE CALLS BEHIND IT
Four decisions carried the design.
Each decision's full option space — plus the AI‑assisted schema model, side‑by‑side comparison view, and manual/automated visual system — is in the full case study.
WHERE THE PLATFORM LANDED
Seven teams. Multiple use cases. One platform.
IN THE BUILDER'S OWN WORDS
The clearest signal, from the teams shipping on it.
More testimonials — from QB Time, OpX & Automation, and Business Platform — in the full case study.
WHAT THE PROJECT TAUGHT ME
Designing a platform is picking a boundary and holding it.
The judgment call I'd defend: choosing a guided flow over a dashboard, even against senior engineers who lived in the dashboard mental model. Designing for the audience you're trying to create — not the one already on the critical path — was the single load‑bearing decision. Every "just let power users do X" request was a request to reintroduce the fragmentation the platform was meant to remove.
The thing I'd do differently: get real BU teams shipping on rough tooling earlier. The 10× efficiency win from Business Platform came from a use case we hadn't specifically designed for — a signal that would have arrived weeks sooner if we'd opened the door to early builders instead of waiting for polish. Adoption teaches you what testing can't.
What this changed in my practice: I now treat "who is currently on the critical path?" as the first question on any platform project. The answer names the constraint every design decision needs to solve for — and it's rarely the persona anyone would list first.
