What AI Compresses, and What It Doesn't

A while back a founder sent me a product requirements document and asked me to run engineering against it.

The document asked for parity with two well known digital asset custody platforms, and then to exceed them. Custody operations from day one. Seven payment corridors. Twenty five fiat currencies. Kubernetes, Kafka, TimescaleDB, Vault and Datadog underneath all of it.

Eleven weeks. Two remote engineers. Everything else "post-Series A."

The easy thing to do here is laugh at the founder. I want to argue the opposite, because I think the plan was a reasonable conclusion drawn from a real observation, and the mistake inside it is one I now see almost everywhere.

The observation was correct

This founder had been using AI tooling and watching things that used to take a sprint take an afternoon. That experience is real. I have it too. When I write code with AI assistance now, I move meaningfully faster than I did three years ago. Call it 20 to 40 percent on the kind of work where it helps, which is most of the code I write.

So the reasoning went: if the building got several times faster, the plan can get several times shorter.

That reasoning has one hidden assumption. It assumes the thing standing between you and launch is the building.

For a regulated financial platform, it mostly isn't.

The two kinds of work

Almost everything on a plan falls into one of two categories, and they behave completely differently.

Effort-bound work finishes when someone finishes it. Write the service, build the dashboard, migrate the schema, wire the integration. Add people or add leverage and it compresses. This is exactly where AI lands, and it lands hard.

Time-bound work finishes when enough time has passed. You cannot add engineers to it. You cannot prompt your way through it. It takes what it takes, and the clock only starts when you start it.

Once you sort a roadmap into those two buckets, the eleven week plan answers itself.

What does not compress

Here is what sat on the critical path of that plan, none of which is code.

Vendor onboarding. You do not integrate a custody provider or a banking partner the way you integrate Stripe on a side project. They run due diligence on you. They want your corporate structure, your licence, your policies, your ownership chain, your risk framework. That process runs on their calendar and their queue, not yours. Your beautiful adapter layer sits finished and idle while it happens.

Key ceremonies. Generating and securing keys in hardware is a scheduled, witnessed, documented event with named participants. It is deliberately slow. That is the entire point of it.

Hiring an accountable person. Regimes require named, qualified, approved humans in specific roles. A money laundering reporting officer is not a service you provision. It is a person you find, vet, hire, and in many cases notify a regulator about. Nobody has ever shortened that by writing better software.

Penetration testing. Booking a reputable firm has lead time. The test has duration. Remediation has duration. Then, if it mattered, the retest has duration.

Audit observation windows. This is the one that ends most arguments. A SOC 2 Type II report is not a document you produce. It attests that your controls operated correctly over a period, and the period is the deliverable. You cannot compress a window whose length is the thing being certified. You can only start it earlier.

Talking to regulators. Correspondence takes as long as it takes. There is no premium tier.

Sum that critical path and you are well past eleven weeks before anyone has written a line of code. Which is roughly what the public record already told us: the platforms in the document took something like a year and a half and two years respectively to reach a first real version, with founding teams full of people who had done exactly this before. They were not slow because they lacked AI. They were slow because most of what they were doing was time-bound.

The tell

Digging through the plan provider by provider, I found the specific confusion underneath it, and it is a good one to watch for.

The plan treated "a vendor provides this" as equivalent to "we have this."

Those are not the same. Buying a custody provider does not give you their capability. It makes you their customer, which means their onboarding, their approval, their timelines, their risk appetite about whether they want you at all. You have not acquired a capability. You have joined a queue.

That single substitution, made a dozen times across a document, is what turned two years of work into eleven weeks on paper. Every individual swap felt like a shortcut. Stacked together they deleted the entire critical path.

What I did instead

I did not take the role as written, and I did not try to win the argument in a meeting. Meetings are where confident plans go to survive.

I wrote it down instead. A package of documents: a gap audit against the current state, a cost analysis, a revised process and delivery flow, a regulatory analysis, a vendor concentration plan, a build roadmap, a scoped MVP specification, and the engagement terms I would actually accept.

The point of writing it down is that it converts one large disagreement into a series of small decisions. A founder can wave away "this is unrealistic." It is much harder to wave away thirty specific clauses, each of which invites an accept, a reject, or a change. The surface area is too big to hand wave, and every clause you accept narrows the argument.

Two things I would do again.

I hedged honestly on the regulatory analysis. I refused to assert specific article numbers or transitional provisions I could not personally defend, and flagged them for counsel instead. It felt weak while writing it. It turned out to be the strongest part of the document, because when new licensing facts surfaced later, nothing I had written needed retracting. Do not borrow authority you do not have. It has a way of getting called in.

I put every external provider behind an interface we owned. Payment rails, custody, KYB, transaction screening, wallet screening, liquidity. Six interfaces, all ours. If a vendor's onboarding stalls, or their pricing moves, or their risk team decides they do not want your jurisdiction, you swap an implementation rather than re-architecting a platform. When large parts of your timeline sit inside someone else's queue, the ability to change queues is worth building for on day one.

What came out of it was a scoped first phase we could actually deliver, with a defined trigger for when the harder capability gets added. Not the document I was handed. Also not a no.

The part that generalises

I do not think this is really about crypto custody, or even about regulation. It is about a planning error that AI has made much easier to commit.

When one category of work suddenly gets several times faster, and it happens to be the most visible category, every plan starts getting written as though it were the only category. The code is what you watch. The code is what demos. So the code becomes the mental model for the whole delivery, and the invisible work quietly keeps its original duration.

So the question I now ask early, on any plan touching money, health, or anything licensed:

What here is effort, and what here is elapsed time?

Effort is where you spend your leverage. AI, headcount, better tooling, all of it goes here, and it genuinely pays.

Elapsed time is where you spend your calendar, and the only lever you have is starting it sooner. So start it sooner. Begin vendor onboarding before the integration exists. Open the audit window before the controls are pretty. Start hiring the accountable person before you are legally required to have one.

AI has made us dramatically faster at building. It has not made anybody faster at waiting. Most plans that fail now are not failing on the building.