Interviews
How platform teams evaluate and adopt integration tooling
Priya Nair
How does your team handle third-party integrations today?
Mostly in-house connectors we wrote and now dread touching. Every partner API is a new snowflake, and when one breaks it's our on-call that pays.
What would have to be true for you to adopt a platform like Halyard?
A real SDK and full observability. If I can't see logs, retries and replay per event, it's a black box I won't trust in production.
How do you feel about usage-based pricing?
Fair in principle — we'd rather pay for volume than seats. But I'd want caps so a runaway loop doesn't wreck the bill.
Lucas Meyer
You're on MuleSoft today — what's the experience like?
Powerful but heavy, and the renewal conversations are brutal. Half my team avoids it because the developer experience is painful.
What would make you switch?
Lower total cost and something engineers actually want to use. But migrating live integrations is the scary part.
Seat-based or usage-based?
At our size I want predictability. Usage-based only works with a committed floor and clear caps.
Hannah Kim
You have no integration layer yet — how are you deciding?
Speed. We're small and I need to ship partner integrations this week, not stand up infrastructure for a month.
What would win you over?
A free tier I can start in an afternoon and great docs. If I hit value fast, I'll happily grow into a paid plan.
Usage-based pricing — reaction?
Love it. Paying for what we actually run fits a small team far better than buying seats we don't have.
Aditya Rao
What matters most when you evaluate an integration platform?
Architecture fit and whether it respects open standards. I won't let a vendor own our data flow or lock us in.
What's your biggest hesitation?
Trust and extensibility. Show me the internals, the SDK, and an escape hatch, or it's a no.
And on pricing models?
Usage-based is fine if it's transparent. Opaque metering is worse than seats.
Grace Mensah
Where does Zapier fall short for you?
Error handling. It can't do the retries, dead-letter queues and alerting our flows need, so we've outgrown it.
What would a better tool have to nail?
Observability and control — I want to see every failure and replay it, not guess.
Usage-based pricing?
Works for us as long as there are caps. Predictable enough, and fairer than paying per seat.
Executive summary
Across interviews the shared job-to-be-done is removing integration plumbing so engineers can stay on core product — but the adoption bar is high: a real, typed SDK and production-grade observability (logs, retries, replay) are non-negotiable before anyone trusts a platform with their data flow. Switching risk centres on migrating live integrations without downtime. On pricing, the split is stark: small/PLG teams love usage-based as fairer, larger orgs will only accept it with committed floors and hard caps.
Key themes
Observability is the trust gate
No engineer will adopt a black box; logs, retries and replay are table stakes.
“If I can't see logs, retries and replay per event, it's a black box I won't trust.” — Priya Nair
“I want to see every failure and replay it, not guess.” — Grace Mensah
Migration is the scary part
The concept is welcome; moving live integrations without downtime is the real fear.
“Migrating live integrations is the scary part.” — Lucas Meyer
Pricing appetite splits by size
PLG teams want usage-based; large orgs want floors and caps.
“Paying for what we actually run fits a small team far better.” — Hannah Kim
“Usage-based only works with a committed floor and clear caps.” — Lucas Meyer
Recommendations
- Make the SDK and observability the first thing a developer sees.
- Offer a zero-downtime migration playbook for live integrations.
- Package usage-based with caps for PLG and committed floors for enterprise.