Every integration developer knows this story.
A request comes in: a business team needs a new integration, a new SaaS tool needs connecting, a workflow needs a connector that doesn't exist yet. However it starts, it always goes the same way.
Call the vendor. Wait for a scoping call. Wait for a services quote. Wait for a consultant, someone who spent six months getting certified in a proprietary Ruby framework that nobody outside that vendor's ecosystem has ever heard of. They finally show up, start the clock, say it'll take two weeks, and deliver in four months.
The next time a request comes in, you decide to go it alone. You crack open the documentation, built on languages and frameworks the industry left behind years ago. You dig, you search, you find a Stack Overflow thread from 2014 that almost answers your question. You post in the vendor's community forum. You wait three days to hear nothing back.
Both paths end the same way: stuck. Hostage to a vendor's backlog, a consultant's calendar, or documentation written for a different era.
If you're an integration developer, that era is over. AI integration requirements are arriving faster than any hand-built connector model can absorb, and platforms still built around that model are already falling behind.
The cost of hand-built iPaaS connectors
The iPaaS industry spent years dressing up proprietary connector frameworks in Java or Ruby as "engineering rigor." It wasn't. It was a tax paid in developer hours, maintenance overhead, and a connector backlog that never actually shrunk.
Some vendors doubled down on Java. Others bet on Ruby. Both choices reflect the same thing: platforms built for a world that no longer exists, optimized for what their teams already knew rather than where enterprise development was going.
When their own connector frameworks became too much for customers to handle alone, they didn't fix the framework. They sold a services engagement. Your integration roadmap became their revenue opportunity, connectors that should take days stretched into quarters, and every delay had a consultant invoice attached to it.
Integration teams have been inheriting this debt since ancient times (aka the early 2010s). The truth is that connector development has always been a bottleneck. It just took AI to make that fact impossible to ignore.
Tray CDK was built for this moment
When we first launched the Tray Connector Development Kit (CDK), we made a deliberate bet. Instead of optimizing the old way of building connectors, we started from scratch.
CDK is TypeScript-first, with a clean CLI, a defined project structure, standardized authentication patterns, and explicit input/output schemas. Every connector follows the same shape. Every operation is predictable. Every deployment follows the same path.
That consistent, modern structure is exactly what makes the next step possible: you can now use Claude to build connectors.
You can now use Claude to build connectors
Claude Code is Anthropic's CLI tool that brings Claude directly into your terminal. Pair it with TRAY_CDK_GUIDE.md, a reference file that gives Claude full context on CDK conventions, CLI commands, project structure, and patterns, and the way you build connectors changes.
You stop writing them. You describe them. In other words, the prompt is the spec.
Claude Code scaffolds the operation directory, configures the HTTP handler, sets up pagination in the input schema, and writes the test. It knows CDK. It knows the patterns. It knows what a well-structured connector looks like.
Done. auth.ts and connector.json updated with the correct configuration.
Done.
That's the full development lifecycle: build, test, debug, deploy, driven by natural language and grounded in deep CDK knowledge.
Read the Claude Code + CDK guide →
Why other iPaaS platforms can't simply bolt this on
This is where it gets uncomfortable for the rest of the market.
AI-native development can't be retrofitted onto a platform built for hand-coding. If your connector framework is a sprawl of language-specific idioms and institutional knowledge, Claude can't help you. AI needs structure and predictability, a codebase where patterns are consistent enough to learn from and generate against.
And if your platform is really three or four legacy products acquired over the years, rebranded under one logo, and held together with integrations between the integrations, an AI layer on top doesn't fix the foundation underneath.
Tray was built as a unified platform from the ground up: no legacy baggage, no acquired product grafted into the core, no decade-old Ruby framework propped up by a professional services org. The architectural decision we made years ago now makes AI-native connector development possible today. There’s no way to “acquire” your way to this. You either built for the future or you didn't.
What this means for your integration roadmap…
AI has already changed how connectors get built. The question worth asking now is whether your platform's foundation is compatible with that change.
With Tray CDK and Claude Code, the path from "we need a connector for X" to that connector in production is measured in hours, not quarters. Drop TRAY_CDK_GUIDE.md into your project as CLAUDE.md, launch Claude Code, and you have a collaborator that understands CDK deeply, one that can scaffold, debug, and deploy alongside you without a services engagement attached to every request.
…and what this means for your bottom line
iPaaS development is at an inflection point. The hand-built connector model, proprietary frameworks, certified consultants, perpetual backlogs, is beyond inefficient. In the context of what's now possible, the costs in time, money, and developer patience are no longer defensible.
Tray built CDK on modern principles precisely because we knew this moment was coming. With Claude Code now part of the workflow, we're not just ready for it, we're building ahead of it.
The hand-built iPaaS connector is dead. What replaces it is faster, smarter, and already here.
Want to see what AI-native connector development looks like in practice?
Talk to our team. We'll show you how CDK + Claude Code can change the way your organization builds integrations.
