Proof of work
·
2025
·
3 min read
Scaling Integrations
Where it all started
When I joined Fireflies in August 2024, we had 45 integrations and a painful truth underneath. Every single one had its own dedicated codebase. No shared logic, no reusable patterns. If a customer asked for a new integration, the honest answer was: give us a month.
In a category where being the most connected tool wins, one integration per month is not a roadmap. It is a liability.
The more I looked, the clearer it became. We did not have an integrations problem. We had a framework problem.
Strip it back to first principles
There are really only two types of integrations.
Push: Fireflies sends meeting notes out to CRMs and project tools.
Pull: Fireflies pulls calls in from dialers and transcribes them.
The patterns were almost identical every time. We were rebuilding the same house from scratch when we could have been snapping walls together from shared blueprints.
The proposal: own the infrastructure
The obvious move was iPaaS. Zapier, Make, done. We considered it and walked away. The problem was reliability on a third party we could not control, support issues with a chain of blame, and building on someone else's foundation at the exact moment we needed to own ours.
Instead we built an internal connector framework. Manifest-driven, consistent, and clean. Define each integration once. The framework handles the rest. Engineers stop writing from scratch and start configuring against a known system.
We built it in under a month. What it unlocked was immediate.
Before: 3 to 4 weeks per integration. After: under one week. The simplest integrations: 2 to 3 days.
Then we found our hidden developer community
Digging into the ecosystem, we found developers who had already built on Fireflies' API on their own without ever telling us. They had seen the value, done the work, and gotten nothing back.
We brought them in. Formal partner program, free trials, direct PM access, warm leads pushed back to builders. New integrations started coming in from the outside.
The program does not create enthusiasm. It captures enthusiasm that already exists.
Then we handed it to AI
We fed Devin the full framework documentation and a handful of example integrations. It could take a brief, ingest the endpoint details, and produce a working draft with minimal human involvement. Engineers shifted from writing code to reviewing it.
Average time dropped to 1 to 2 days. The fastest integration ever shipped: under 24 hours from brief to live.
We did not just build a faster framework. We built a framework AI could work with.
Where it stands today
45 integrations to 110+ in a year. Most integrated AI notetaker in the market. Under 48 hours to ship an integration with AI assistance. Now a key differentiator in competitive displacement conversations across the sales team.
What this taught me
A framework is a product. Treating infrastructure as a first-class product decision changes everything you build on top of it.
Speed compounds. Going from 4 weeks to 1 week does not just save time. It changes what you are willing to attempt.
AI works best with well-designed systems. Devin did not make us faster because AI is magic. It worked because the framework was clean enough for a model to reason about. Messy systems do not get faster with AI. They just get messier, faster.
