Developer tools · API infrastructure

Testing a seat-to-usage pricing switch with 16 engineering buyers — before touching the billing code

A code-first API-integration platform pressure-tested a risky pricing migration against real technical buyers, in 48 hours.

Halyard's team suspected usage-based pricing fit their product better than seats — but a mispriced migration could tank revenue and anger enterprise accounts. Instead of guessing, they ran three synthetic studies against 16 engineering personas spanning PLG startups to 1000+ orgs.

engineering personas

studies in 48h

2-tier

pricing model shipped

billing code touched first

The challenge

The product team believed seat-based pricing under-monetised heavy users and over-charged small teams, but the finance and sales orgs feared a usage-based switch would create unforecastable bills and spook enterprise buyers. No one had strong evidence either way, and running a real pricing survey across engineering leaders would take weeks of recruiting.

Our approach

Halyard defined an audience of 16 engineering personas — platform, backend, integration and DevOps engineers plus their managers and VPs — across three company-size bands and five 'current approach' segments (in-house, Zapier, Workato, MuleSoft, none). They ran a packaging & pricing questionnaire, a jobs-to-be-done interview on how teams adopt integration tooling, and a live group conversation reacting to the proposed usage-based model.

The results

The evidence was decisive: usage-based pricing splits cleanly by company size. PLG and mid-market teams welcome it as fairer than seats, while 1000+ orgs will only accept it with a committed floor and hard caps. The team also learned the real must-have was observability and a typed SDK — not more connectors — and that a transparent, self-serve usage calculator would sell the pricing page better than a 'contact sales' wall. Halyard shipped a hybrid model: usage-based with caps for self-serve, a committed-floor plan for enterprise.

Research brief

Research goals

Test appeal of a code-first integration platform vs. current approachesValidate a switch from seat-based to usage-based pricingSurface the real blockers to adoption for technical buyers

Hypotheses

Teams on in-house glue code have the highest appealUsage-based pricing is preferred by smaller/PLG teams but feared by large orgsObservability and a real SDK are the true must-haves, not more connectors