Rolling out AI builder tools is mostly choreography with finance, IT, and security. 5 moves from a week of getting a pilot onto the plan.
Last Thursday I walked into our weekly AI adoption leads meeting with a vision I was proud of: every PM and designer in the product org gets to choose between two builder stacks, one anchored on Claude Code and one on Cursor, the same way engineering already picks one of two. We have 2 pilots running. The people who set them up did the hard part (credit to our IT and engineering partners, who have been untangling procurement loops on our behalf for months). I wanted to talk about rollout.
Our finance partner stopped me in the kindest possible way. That decision hasn’t been made, they said, and the financial impact hasn’t been modeled. If it’s something we’re leaning toward, the earlier you talk to me, the more numbers I can give you.
The earlier you talk to finance, the more numbers they can give you.
They were right, and the sentence has been rattling around in my head since, because it’s the opposite of how most of us in design treat finance. We show up with the pitch and ask for the money. The better sequence is to show up with the scenario and ask for the model. A pilot stays a pilot until there’s an annual-plan line item behind it, and ours was due Monday.
So here’s the toolbox for anyone rolling out AI builder tools inside a company with a real finance function and a real security team. It’s less about the tools than the choreography around them.
Model before you pitch. Before the vision deck, bring finance the variables: headcount in scope, 2 or 3 usage tiers, the per-seat and per-token shape of each stack, and a precedent if you have one (engineering’s choose-one-of-two with a defined split gave us ours). Let them build the scenarios. You’ll walk into the leadership conversation with numbers that came from the person who’s going to defend them.
Put the real price on the sheet. We had a 3-month proof of concept whose cost came back at roughly 3x the original estimate, more of a vendor conversation that moved than a scandal. The lesson is to update the tools request sheet the same day the number changes, because the sign-off is only as good as the figure next to it.
Treat overages as a process. Anyone on the team can file an overage request, one person authorizes it, and finance and IT sign off with a 24-hour turnaround target. Finance tunes the limits monthly per person, higher for the power users and lower for everyone else, and the stated goal is zero day-to-day overages with exceptions for known project spikes. The practical habit that follows: if you know next week is heavy, say so before you hit the wall.
Know where the MCP line is. Vendor-published connectors, the official ones a company maintains for its own product, can be switched on org-wide with scope settings, and the turnaround once they’re cleared is 1 to 2 weeks. Third-party connectors hosted by someone on GitHub are a no, and the reasoning from our security partner is worth repeating: it’s not the vendor maintaining that code, it’s random person X. If you’re requesting a connector, ask for it in every tool you’ll use it in at once, so it gets one review instead of three.
Name an owner for every request. One connector we wanted stalled for months because the system owner pointed me to IT, IT had submitted and then recalled it, and nobody held the ball. Every request needs a name next to it, and the system owner weighs in before approval. It’s boring, and it was the single biggest unblock of the week.
It’s the unglamorous part of AI adoption, and it’s the part that decides whether the pilot becomes the way your team works or stays a story 2 people tell about one good Friday.
The teachable part
Bring finance the scenario before the pitch, keep the real price on the sheet, run overages as a process, know the MCP line (vendor-published yes, GitHub-hosted no), and put a name on every request.