DEV Community: mattewens

I priced every voice-AI stack for a 10k-minute month - the results surprised me

mattewens — Wed, 26 Aug 2026 15:03:34 +0000

I priced every voice-AI stack for a 10k-minute month. The results surprised me

I was working through pricing for a voice-agent SaaS and got annoyed by how hard it is to answer one basic question.

If I run 10,000 minutes of calls in a month, what do I actually pay?

Not the headline platform fee. Not the nice landing-page number. The real stack cost after you add the phone line, speech-to-text, text-to-speech, and the voice agent provider.

So I put Vapi, Retell, Bland, Twilio Voice, and OpenAI Realtime into the same model and ran a simple 10k-minute month.

The short version is that the cheapest-looking option is not always cheapest. Once you add STT and TTS, the gap moves around fast.

Here is the shape of the comparison I used.

Stack	What is included	What you still need to check
Vapi	orchestration layer for voice agents	model, voice, telephony and usage assumptions
Retell	voice agent platform pricing	included minutes and overage rules
Bland	voice automation platform pricing	campaign style, telephony, and concurrency limits
Twilio Voice	raw telephony building block	STT, TTS, LLM, orchestration, storage
OpenAI Realtime	direct realtime model path	phone carrier, call control, app logic

The mistake I see is comparing Vapi or Retell directly against Twilio Voice. That is not the same product. Twilio is mostly the carrier and programmable voice layer. If you use it raw, you still need the agent brain, streaming, speech recognition, speech generation, logs, retry logic, billing, and all the boring glue.

That glue has a cost even if the invoice does not show up as one line item.

For a 10k-minute month, the calculator makes you separate four questions.

How many minutes are inbound vs outbound?
Which provider charges per minute on top of model cost?
Is speech-to-text bundled or separate?
Is text-to-speech bundled or separate?

The surprising bit was how often the raw telephony path only wins if you already have the engineering time to own the whole stack. If you need to ship a product this week, the platform markup can be cheaper than spending two weeks debugging call streams and usage reconciliation.

The other surprise was that voice choice matters more than people expect. A nice neural voice can turn a cheap call path into a much more expensive one. Same with transcription. If you pick a premium STT provider and a premium TTS provider, your per-minute economics change before the agent provider has even charged you.

Here is a simplified example.

Cost bucket	Why it matters
Telephony	every minute needs a phone network path
Voice agent platform	orchestration, latency handling, tools, call state
STT	turns caller audio into text
LLM or realtime model	reasoning and response generation
TTS	turns responses back into audio
Storage and logs	recordings, transcripts, analytics, compliance

The pricing pages make each bucket look small in isolation. The month total is where it gets real.

This matters if you are selling voice agents to customers. A client does not care that Twilio was cheap if the full product loses money at 2,000 minutes. They also do not care that a platform is elegant if their expected call volume makes the margin disappear.

The sane way to price this is backwards. Start with the customer plan, estimate expected call minutes, add a safety margin for spikes, then choose the stack. Do not choose the stack first and hope the unit economics work later.

For example, if you sell a $199 per month voice-agent plan and the customer uses 10,000 minutes, your gross margin can get wrecked. If you sell a $999 plan with usage caps and overages, the same provider might be fine. The product packaging matters as much as the infrastructure provider.

I also think more voice-AI demos should publish their assumed monthly minutes. A demo that handles five test calls tells you almost nothing about cost at real usage. The calculator forced me to make those assumptions explicit, which made the provider comparison much cleaner.

None of this means one provider is always better. Vapi can make sense when you want a developer-first orchestration layer. Retell can make sense if its bundled path matches your use case. Bland can make sense for certain outbound workflows. Twilio plus your own stack can make sense when you have the engineering team and need control. OpenAI Realtime can make sense when you want to build close to the model.

The point is that you should compare full stack cost, not logo pricing.

I put this into a calculator so anyone can plug their own numbers: https://callforge.dev/calculator

I Rebuilt My Vapi Backend Three Times - Here's What I Learned

mattewens — Sun, 23 Aug 2026 11:14:02 +0000

I rebuilt my Vapi backend three times before I admitted the problem was not Vapi. The problem was the system around it.

The first version was a demo backend. It created an assistant, accepted a webhook, and stored a few call records. That was enough to impress myself and completely insufficient for a customer. The second version added auth and Stripe, but tenant boundaries were bolted on after the fact. The third version finally treated voice infrastructure like SaaS infrastructure.

That sounds obvious once you say it. It was not obvious when the prototype was working and I wanted to move fast.

The demo backend trap

A Vapi prototype can be small. You need an assistant config, a phone number, a webhook URL, and some glue. You can get something speaking to a caller in an afternoon.

The trap is that the prototype teaches you the wrong shape for the app. A single assistant becomes a global assistant. A single webhook handler becomes a pile of conditional logic. A single Stripe customer becomes a note in your database that you promise to clean up later.

Later usually means after the first real customer has already created data you cannot casually migrate.

The mistake I made was starting with calls. The better starting point is tenants.

Every object needs an owner

Voice SaaS gets messy when a call, phone number, assistant, tool, transcript, invoice item, and webhook event are not all tied back to the same account. You need that relationship before you need a clever prompt editor.

The architecture that held up looked like this:

User -> Tenant -> Assistant -> Phone Number -> Call -> Usage Event -> Invoice Item

Vapi sits in the middle of the runtime path, but your app owns the commercial and permission model. That distinction matters. Vapi can run the call. Your backend needs to decide who is allowed to edit the assistant, who pays for the minutes, and where the post-call data lands.

A simple route shape helped:

app.post('/api/tenants/:tenantId/assistants', requireUser, async (req, res) => {
  const tenant = await db.tenant.findFirst({
    where: { id: req.params.tenantId, users: { some: { id: req.user.id } } }
  })

  if (tenant === null) return res.status(404).json({ error: 'tenant_not_found' })

  const assistant = await vapi.assistants.create({
    name: req.body.name,
    model: { provider: 'openai', model: 'gpt-4o-mini' },
    transcriber: { provider: 'deepgram' },
    voice: { provider: '11labs', voiceId: req.body.voiceId }
  })

  await db.assistant.create({
    data: { tenantId: tenant.id, vapiAssistantId: assistant.id, name: req.body.name }
  })

  res.json({ id: assistant.id })
})

The important part is not the SDK call. It is the tenant check before the SDK call and the local record after it.

Webhooks are not logs

My first webhook handler wrote whatever came in to a JSON column and moved on. That felt flexible. It was really just postponing decisions.

A production webhook needs three boring properties: verification, idempotency, and routing. Verification keeps random internet noise out. Idempotency stops retries from double billing. Routing maps the event back to the tenant before any side effect happens.

app.post('/webhooks/vapi', express.raw({ type: 'application/json' }), async (req, res) => {
  const event = JSON.parse(req.body.toString())
  const eventId = event.id || event.message?.call?.id + ':' + event.message?.type

  const exists = await db.webhookEvent.findUnique({ where: { eventId } })
  if (exists) return res.status(200).json({ ok: true })

  const callId = event.message?.call?.id
  const call = await db.call.findFirst({ where: { vapiCallId: callId } })

  await db.webhookEvent.create({ data: { eventId, callId, payload: event } })

  if (event.message?.type === 'end-of-call-report' && call) {
    await db.call.update({
      where: { id: call.id },
      data: { endedAt: new Date(), summary: event.message.summary || null }
    })
  }

  res.json({ ok: true })
})

This is less exciting than a dashboard. It is also what separates a tool from a product.

Billing has to follow the call lifecycle

Metered billing is easy to describe and annoying to implement late. You need to know when usage is final, what unit you bill on, and how you handle provider retries. I found it cleaner to create internal usage events first, then sync those to Stripe.

Do not use Stripe as your source of truth for raw call state. Let Stripe be the billing rail. Your database should know the call duration, tenant, provider call ID, billing status, and invoice item reference.

A practical pattern is:

Store call start when Vapi creates or reports the call.
Store call end and duration from the end-of-call event.
Create one usage event with a deterministic idempotency key.
Sync to Stripe once.
Mark the usage event as billed.

That lets you retry billing safely without rewriting call history.

Prompt templates are product surface, not config

In version one, prompts lived inside code. In version two, they lived in a text box. Both were wrong.

Customers do not want raw prompt control as much as builders think they do. They want safe knobs: greeting, business facts, escalation rules, booking rules, disallowed claims, tone, and fallback behaviour. Store those as structured fields and compile the assistant prompt from them.

That gives you versioning, previews, and rollback. It also makes support easier because you can see which field caused the assistant to behave differently.

The rebuild I would avoid now

If I were starting again, I would not begin with the voice provider integration. I would begin with the boring SaaS skeleton:

tenants and memberships
assistant records mapped to provider IDs
phone number ownership
webhook event storage
usage events
Stripe customer mapping
audit logs for assistant changes

Then I would add Vapi as a provider module, not as the centre of the whole app.

That sounds slower for the first demo. It is faster by the time the second customer asks for their own phone number, their own prompt, their own billing, and their own call history.

The main lesson

Voice AI demos are deceptively close to products. The gap is not speech quality. The gap is ownership, billing, retries, permissions, and lifecycle state.

If you are building on Vapi, Retell, Bland, or any similar provider, treat the provider as runtime infrastructure. Your app still needs to be the system of record.

I rebuilt this stack enough times that I packaged the pattern into Callforge. If you would rather skip the rebuilds, the public preview is at https://callforge.dev/preview.html.

What Breaks When Your Voice Agent Hits Customer #10

mattewens — Sun, 16 Aug 2026 00:53:09 +0000

Three real failures from shipping voice SaaS, and the boring fixes nobody demos

Customer #1 is easy. One phone number, one Vapi assistant, one Stripe subscription you clicked together by hand in the dashboard. Your demo works. Landing page is live. You're ready to scale.

Customer #10 is where it gets interesting.

Same code. Same config. Suddenly everything's on fire. I've hit this wall three times now, building voice-agent SaaS for consulting clients, and honestly the pattern's identical every single time. Here's what actually breaks when you cross that threshold, plus the unsexy infra work that saves you.

The Provisioning Problem

Your first customer gets a Twilio number you bought manually. You hardcoded it into the env vars. It's fine. They're happy. Life is good.

Your tenth customer needs a number too. So you buy one, drop it in the config, redeploy. Still fine. Annoying, but fine.

Your twentieth customer hits at 11pm on a Sunday. You're at dinner. They're in a different timezone and their number isn't working because something broke in your manual process, and now you're debugging Twilio logs on your phone while the restaurant staff give you that look. You know the one.

The real fix isn't sexy. It's a provisioning API that buys numbers automatically. Health checks that retry failed purchases. A pool of warm numbers sitting there ready to assign. All the stuff you skip in the tutorial because "we'll add that later."

Later never comes. Until it burns you.

The boring fix:

// Auto-provision numbers with health checks
async function provisionNumber(customerId: string) {
  const pool = await getWarmNumberPool();
  const number = pool.pop() || await twilio.incomingPhoneNumbers.create({
    areaCode: '415',
    voiceUrl: `${BASE_URL}/webhook/voice/${customerId}`
  });

  // Health check before assignment
  await validateNumber(number.phoneNumber);
  await assignToCustomer(customerId, number.sid);

  // Replenish pool
  if (pool.length < 5) await warmNumberPool(3);
}

The Billing Revelation

Look, seat-based pricing is a trap for voice. Your customer doesn't care about seats. They care about minutes. One agent handling 1000 calls is a completely different beast from ten agents handling ten calls each. Seat pricing makes zero sense here.

I learned this the expensive way. A client had a customer go viral on TikTok. Their phone line just blew up. Weekend call volume hit 50,000 minutes. Under seat pricing? That customer paid $49. Their Twilio bill was $1,247.

That's a fun Monday morning conversation.

Real voice SaaS needs metered billing. Twilio call-status webhooks feeding into Stripe usage records, per-minute billing that tracks what people actually use, not some artificial seat count. It's tedious to build. Everyone skips it. Everyone regrets it.

The boring fix:

// Webhook handler for usage-based billing
app.post('/webhook/twilio/call-status', async (req, res) => {
  const { CallSid, CallDuration, CallStatus } = req.body;

  if (CallStatus === 'completed') {
    const customer = await getCustomerByCallSid(CallSid);
    const minutes = Math.ceil(parseInt(CallDuration) / 60);

    // Push to Stripe usage records
    await stripe.subscriptionItems.createUsageRecord(
      customer.stripeSubscriptionItemId,
      {
        quantity: minutes,
        timestamp: Math.floor(Date.now() / 1000),
        action: 'increment'
      }
    );
  }

  res.sendStatus(200);
});

The Compliance Trap

GDPR sounds theoretical until your first erasure request lands in your inbox. "Please delete all my data."

Simple, right? Except your recordings are scattered across three S3 buckets. Your call logs live in Twilio. Your transcripts are sitting in your LLM provider. Your customer database is in Postgres. And you never built a way to connect any of it.

So now you're grepping through logs at midnight trying to find every trace of one customer, while their lawyer sends increasingly pointed emails. Cool cool cool.

The fix is per-tenant isolation from day one. Separate buckets, consent gates, erasure hooks that cascade through your data model. It's boring infrastructure work. Absolutely critical.

The boring fix:

// Per-tenant storage with cascade erasure
async function eraseCustomerData(customerId: string) {
  const tenant = await getTenant(customerId);

  // S3: Delete all objects in tenant bucket
  await s3.deleteObjects({
    Bucket: `callforge-recordings-${tenant.bucketSuffix}`,
    Delete: await listAllObjects(tenant.bucketSuffix)
  });

  // Twilio: Delete recordings via API
  const recordings = await twilio.recordings.list({
    dateCreatedAfter: tenant.createdAt,
    dateCreatedBefore: new Date()
  });
  await Promise.all(recordings.map(r => r.remove()));

  // LLM provider: Delete stored transcripts
  await deleteLLMTranscripts(tenant.llmSessionIds);

  // Finally: Remove from database
  await db.customers.delete({ where: { id: customerId } });
}

What This Means for Your Stack

Here's the thing. These aren't edge cases. They're the difference between a demo and a business. Every voice-agent tutorial out there shows you how to wire Vapi to Twilio in twenty lines of code. Nobody shows you the three months of infrastructure work that follows.

We learned this by building voice SaaS for clients, and by tearing down 25 open-source voice-agent repos to see where everyone skips the exact same steps. Spoiler: it's always the same steps.

If you're serious about shipping voice agents that don't fall over at customer #10, start with the boring stuff:

Automated provisioning with health checks
Metered billing tied to actual usage
Per-tenant data isolation with erasure hooks

The flashy features can wait. Your 3am self will thank you.

Check the teardown: I analyzed 25 voice-agent repos to find exactly where teams skip this infrastructure. See the full breakdown at callforge.dev/teardown, or grab the boilerplate that already handles provisioning, billing, and compliance out of the box.

Linear's Waitlist Playbook: How to Build Hype Without Being Annoying

mattewens — Sat, 15 Aug 2026 23:51:00 +0000

TL;DR

Linear didn't treat the waitlist like a sad little email capture box. They treated it like the first product surface. The result was scarcity, social proof, and a bunch of devs convincing each other they needed access before most of them had even touched the app.

The Pre-Launch Breadcrumb Trail

Linear started building demand months before broad availability. Not with some grand "coming soon" campaign. With breadcrumbs.

Team members posted UI prototypes. Screenshots appeared with casual "wip" captions that somehow showed exactly enough to make design Twitter lean in. Founders talked about engineering decisions instead of dumping feature lists. For a while, there wasn't even a heavy waitlist push.

That's the clever bit. They made the conversation feel discovered, not forced.

Curiosity did the work. Everyone could tell something polished was coming, but nobody knew when they'd get it. That uncertainty became fuel instead of friction. Honestly, it probably made the product feel more real, because the team was showing receipts instead of polishing a launch slogan.

The Waitlist Launch: Small Pond, Big Splash

When Linear finally opened access, they didn't sprint straight to Product Hunt or buy ads like a panicked B2B startup with a new logo and too much coffee.

They started with a tight audience: founder followers, team networks, and design-heavy circles that cared about craft. Then they added referrals. Get friends to sign up, move up the queue.

That mechanism matters because the product's audience already liked tasteful tools and status-y early access. Linear didn't need a giant top-of-funnel. It needed the right people to feel like they were early.

Twenty thousand signups from a small base sounds wild, but the loop was clean: want access, invite friends, signal taste, repeat. Yeah, that's a pretty good loop.

The Referral Mechanics Scaled Because They Sold Access

The reward wasn't a discount. Thank god. Discount-driven referrals tend to attract people optimizing for coupons, not people who care about the product.

Linear gamified access instead.

Action	Reward	Psychology
Sign up	Place in queue	Commitment
Refer 1 friend	Position bump	Investment
Refer 3 friends	Private beta access	Status
Refer 10+ friends	Founding-user badge	Identity

The brilliant part is that each step deepened identity. You weren't just waiting. You were becoming the kind of person who found Linear early, invited the right people, and maybe got let in before everyone else.

A little ridiculous? Sure. Also very human.

The Invite Email Respected the Moment

The invite email didn't waste time. "You're in" did the heavy lifting. A single download link sat near the top. A screenshot reminded you what you'd just been given. "Questions? Reply to this email" made access feel personal, not automated.

That last detail punches above its weight. Early users want proximity. They want to feel like their feedback matters and that a real person might actually read the reply.

Linear also throttled invites. Weekly batches kept the conversation alive, and every new wave created fresh social proof. If everyone gets in immediately, the waitlist stops being a waitlist and becomes a form with better typography. Look, sometimes the delay is the feature.

The Anti-Patterns They Dodged

Most waitlists are where momentum goes to die. You enter an email, get a limp "we'll let you know," and then hear nothing until a launch email lands three months later like a damp napkin.

Linear avoided that by keeping the product visible during the wait. Development updates, screenshots, replies, invite waves, and user posts all made the wait feel active.

They also avoided the usual mistakes. There was no generic dead-end confirmation, no single flat reward, no total silence, no bland access email, and no instant full availability that killed scarcity.

The wait had texture. That's rare.

The Twitter Amplification Loop

Linear's founding team posted constantly during the waitlist phase, but it didn't feel like scheduled content sludge. It felt like builders showing receipts.

They shared screenshots of real usage, talked through engineering problems, replied quickly, and celebrated users who got invites. Every "I'm in" tweet became proof that people wanted the thing. Every batch release became another excuse for the network to talk about it.

That's the loop: product tease creates desire, invite creates status, status creates posts, posts create more desire.

Simple. Brutal. Effective.

The Launch Day Strategy

By the time Linear launched publicly, the launch wasn't really the beginning. Existing users had habits. Waitlist veterans had identity investment. Product Hunt had real stories to point at instead of promises.

That's why it didn't land to crickets. They weren't announcing a mystery product to strangers. They were widening access to something a specific crowd already wanted.

Launch day was basically the victory lap. Kind of annoying, because when it works this cleanly it looks obvious afterward.

What to Steal for Your Own Waitlist

Linear Technique	Your Application
Referral tiers	"Share with 2 dev friends, get priority access"
Breadcrumb tease	Post screenshots before public beta
Engineering transparency	Thread on why your architecture works this way
Founder accessibility	Reply personally to early signups
Batch throttling	Weekly onboarding waves instead of instant access
User celebration	Repost every "got my invite" mention

The key is not to fake exclusivity. If access is limited, make the limitation useful: better onboarding, faster feedback, tighter product loops.

Conversion Score: 9/10

Linear made the waitlist feel like part of the product instead of the waiting room. That's the whole game.

The risk, obviously, is over-hype. Scarcity creates expectations, and expectations are expensive. Linear got away with it because the product shipped at the level the story promised.

Annoying how clean that is.

This teardown is part of a series on developer tool conversion.

Have you run a waitlist that actually worked? Or one that flopped? Tell us what happened in the comments.

Why Stripe's API Docs Convert Better Than Your Landing Page

mattewens — Sat, 15 Aug 2026 09:51:08 +0000

Stripe's API docs aren't just reference material. They're a conversion funnel wearing a hoodie. You arrive with a vague intent, copy a snippet, get a charge working, and suddenly Stripe feels like the obvious choice.

The Three-Panel Layout Works Because Devs Skim

Most docs still behave like a blog post with a sidebar. Stripe understood the assignment better: navigation on the left, explanation in the middle, request and response examples on the right.

That's not decoration. It's workflow design.

Developers don't read docs like novels. We jump around, search for the endpoint, steal the code, run it, swear once, then come back for the parameter we missed. Stripe supports that messy loop instead of pretending everyone is calmly progressing through Chapter 1.

The layout lets you orient, understand, and act without changing context. That sounds small until you've used docs that make you open six tabs just to send one request. Yeah, those still exist.

Interactive Code Blocks Remove the First Excuse

Stripe's code examples are built for action. Your API key can be injected. Every block has copy-to-clipboard. Language tabs remember what you picked. The examples are runnable, not museum pieces.

This is where the conversion happens. Not in a hero headline. Not in a fancy "for ambitious teams" paragraph. It happens when a dev gets a working API call in under a minute and thinks, "Well, that was easy."

Momentum is underrated. Once someone has a working charge, ripping Stripe back out feels more annoying than continuing.

Sneaky? A little. Effective? Absolutely.

They Avoid the Classic Quickstart Faceplant

A lot of API docs start like this: install the SDK, learn authentication, read the core concepts, understand the object model, then maybe you get to make a request if you're still awake.

Stripe flips it. First, make a charge. Then understand what happened. Then dig into setup and edge cases.

That ordering matters because the first win buys patience. After the dopamine hit, people are more willing to read the boring-but-important details. Before it, those details feel like homework.

Your docs should copy this shamelessly. Don't open with architecture. Open with "get your first API call working in 30 seconds," then explain the machinery after the user has seen output. Honestly, nobody complains because the docs gave them a win too quickly.

Search That Feels Like It Knows What You Meant

Stripe search is doing more than matching keywords. It handles fuzzy intent, pushes common actions to the top, links directly into useful code samples, and remembers language preferences.

That's how docs become muscle memory. You stop thinking "where is that page?" and start typing the intent. Create a charge. Set up a webhook. Refund a payment. Boom, you're there.

Good search is one of those unglamorous features that makes the whole product feel sharper. Bad search makes even great docs feel like a junk drawer. Look, if search can't find "webhook retry," people assume the rest of the product has the same weird gaps.

Use-Case Journeys Beat Pure Reference

Reference docs answer "what does this parameter do?" That's necessary, but it's not enough.

Stripe also gives paths around real jobs: accept a payment, set up a subscription, build a marketplace, handle refunds. Those guides map to what the dev is trying to ship, not how Stripe happens to organize its internal nouns.

That distinction is huge. Users don't wake up wanting to "instantiate a PaymentIntent object." They want to take money without breaking production.

You need the same split. Keep the reference clean, but build guides around actual jobs: set up authentication, handle errors, monitor rate limits, migrate from a competitor.

The Trust Infrastructure Is Everywhere

Every page quietly says, "someone maintains this." API status is visible. Security posture is visible. Changelog freshness is visible. Feedback buttons are right there.

None of that is flashy, and that's the point. For payments, abandonment fear is real. If your docs look stale, people assume the SDK is stale, support is slow, and the integration will bite them later.

Stripe keeps sending the opposite signal: we're here, we're watching, and you probably won't get stranded. Basically, it makes the boring parts feel cared for.

What to Steal for Your Own Docs

Stripe Technique	Your Application
Three-panel layout	Left nav, middle explanation, right live API output preview
Try-first quickstart	"Get your first API call working in 30 seconds" before deep dives
Interactive code	Curl command populated with the user's real API key
Use-case paths	Set up auth, handle errors, monitor limits, migrate data
Feedback loops	"Was this example useful?" on every code block

The big lesson is that docs shouldn't merely explain the product. They should get the user to a small win before doubt has time to put its shoes on.

Conversion Score: 9/10

Stripe's docs did what marketing usually can't: they made integration feel inevitable. The only ding is depth. Simple use cases can still feel buried if you don't already know the payments domain.

But the invisible win is massive. The docs reduce support load while increasing conversion. That's the good stuff.

This teardown is part of a series on developer tool conversion.

What's the worst API documentation you've had to wrestle with? Name and shame in the comments.

Linear's Waitlist Playbook: How to Build Hype Without Being Annoying

mattewens — Fri, 14 Aug 2026 18:51:10 +0000

The Pre-Launch Breadcrumb Trail

Linear started building demand months before broad availability. Not with some grand "coming soon" campaign. With breadcrumbs.

That's the clever bit. They made the conversation feel discovered, not forced.

The Waitlist Launch: Small Pond, Big Splash

When Linear finally opened access, they didn't sprint straight to Product Hunt or buy ads like a panicked B2B startup with a new logo and too much coffee.

They started with a tight audience: founder followers, team networks, and design-heavy circles that cared about craft. Then they added referrals. Get friends to sign up, move up the queue.

Twenty thousand signups from a small base sounds wild, but the loop was clean: want access, invite friends, signal taste, repeat. Yeah, that's a pretty good loop.

The Referral Mechanics Scaled Because They Sold Access

The reward wasn't a discount. Thank god. Discount-driven referrals tend to attract people optimizing for coupons, not people who care about the product.

Linear gamified access instead.

Action	Reward	Psychology
Sign up	Place in queue	Commitment
Refer 1 friend	Position bump	Investment
Refer 3 friends	Private beta access	Status
Refer 10+ friends	Founding-user badge	Identity

A little ridiculous? Sure. Also very human.

The Invite Email Respected the Moment

That last detail punches above its weight. Early users want proximity. They want to feel like their feedback matters and that a real person might actually read the reply.

The Anti-Patterns They Dodged

Most waitlists are where momentum goes to die. You enter an email, get a limp "we'll let you know," and then hear nothing until a launch email lands three months later like a damp napkin.

Linear avoided that by keeping the product visible during the wait. Development updates, screenshots, replies, invite waves, and user posts all made the wait feel active.

The wait had texture. That's rare.

The Twitter Amplification Loop

Linear's founding team posted constantly during the waitlist phase, but it didn't feel like scheduled content sludge. It felt like builders showing receipts.

That's the loop: product tease creates desire, invite creates status, status creates posts, posts create more desire.

Simple. Brutal. Effective.

The Launch Day Strategy

That's why it didn't land to crickets. They weren't announcing a mystery product to strangers. They were widening access to something a specific crowd already wanted.

Launch day was basically the victory lap. Kind of annoying, because when it works this cleanly it looks obvious afterward.

What to Steal for Your Own Waitlist

Linear Technique	Your Application
Referral tiers	"Share with 2 dev friends, get priority access"
Breadcrumb tease	Post screenshots before public beta
Engineering transparency	Thread on why your architecture works this way
Founder accessibility	Reply personally to early signups
Batch throttling	Weekly onboarding waves instead of instant access
User celebration	Repost every "got my invite" mention

The key is not to fake exclusivity. If access is limited, make the limitation useful: better onboarding, faster feedback, tighter product loops.

Conversion Score: 9/10

Linear made the waitlist feel like part of the product instead of the waiting room. That's the whole game.

The risk, obviously, is over-hype. Scarcity creates expectations, and expectations are expensive. Linear got away with it because the product shipped at the level the story promised.

Annoying how clean that is.

This teardown is part of a series on developer tool conversion. Previously: Vercel's pricing psychology and Stripe's API docs.

Have you run a waitlist that actually worked? Or one that flopped? Tell us what happened in the comments.

How Vercel's Pricing Page Converts Developers (Teardown)

mattewens — Fri, 14 Aug 2026 17:04:22 +0000

Vercel's pricing page isn't really selling servers. It's selling the feeling that you can ship tonight without babysitting infra at 2 a.m. That's the trick. And yeah, it works.

The Hook Above the Fold

They put the free tier right up front. Not buried in a footnote. Not hidden behind a "start trial" button with a card form waiting to mug you.

That matters because devs are allergic to pricing games. Honestly, the "Hobby" label is doing quiet work here. It doesn't say "free because you're broke." It says "this is for side projects, experiments, weird weekend builds, and all the other stuff devs actually care about."

That's smart framing. You're not being downgraded into the cheap seat. You're being invited to start where you are.

The Three-Tier Dance

Most SaaS pricing pages run the same Goldilocks routine: cheap plan, target plan, scary enterprise plan. Vercel does that, but with a better identity wrapper.

Tier	Price	Frame	Psychology
Hobby	$0	For hobbyists	Zero-risk entry
Pro	$20/mo	For professionals	Identity upgrade
Enterprise	Custom	Contact sales	Status and procurement

The move isn't "pay for feature X." It's "graduate into the kind of builder you already think you are." Look, a lot of pricing pages miss this and drown you in usage limits before you've even decided whether the product belongs in your workflow.

Vercel sells the self-image first. The feature table comes later.

Feature Tables That Pass the Glance Test

The comparison table is built for skimming, which is good because nobody lovingly reads pricing tables unless something has gone badly wrong.

Green checks beat gray minus icons. "Everything in Hobby, plus..." makes Pro feel additive instead of punitive. And the "soft limits" language is doing more than it looks like, because it suggests judgment instead of a robot instantly smacking your account when traffic spikes.

What they don't do is just as important. There's no "Vercel vs AWS" cage match. No competitor dunking. No desperate "save 40% compared to X" box. They own the frame and stay in it. Basically, they don't beg.

The Fair-Use Trust Play

Vercel lists bandwidth limits instead of hiding them until you're already annoyed. That sounds basic, but plenty of hosting companies still treat billing surprises like a retention strategy. Spoiler: they're not.

"Soft limits, don't worry, we'll reach out first"

That line works because it acknowledges developer PTSD. Everyone has either eaten a surprise cloud bill or knows someone who has. By naming the boundary early and making it feel human, Vercel lowers the anxiety before it turns into an objection.

Tiny copy. Big effect.

The CTA Placement Pattern

The calls to action are boring in the best way. "Get Started" appears where you'd expect it. The upgrade path stays visible. Enterprise gets "Talk to Sales," because at that point you're not impulse-buying, you're starting a procurement conversation.

Here's the thing: the language progression matters. Start with deployment, end with relationship. They don't say "Buy Pro" because devs don't wake up wanting to buy a plan. They want to ship something and stop thinking about the plumbing.

What to Steal for Your Own Pricing Page

Vercel Technique	Your Application
Identity-based tiers	Builder (free), Founder (paid), Agency (custom)
Soft-limit language	"First 50 hours included, then $Y/hour. We'll warn you before it gets spicy."
Fast visual hierarchy	Simple checkmarks and plain-English differences
Action-first CTAs	"Analyze My Repo" instead of "Subscribe"

The broader lesson is simple. Make the pricing page feel like a path to momentum, not a toll booth.

Conversion Score: 8/10

Vercel loses a couple points because the Enterprise flow is vague. "Contact sales" is fine, but a rough scale estimator would keep more serious buyers moving instead of dumping them into a form.

Still, the page is annoyingly good. The identity framing, plain developer language, and honest limit handling make it one of the cleaner dev-tool pricing pages out there.

This teardown is part of a series on developer tool conversion. Next up: Stripe's API docs.

What's your biggest pricing page pet peeve? Drop it in the comments.

Building the multi-tenant plumbing every voice-agent tutorial skips

mattewens — Sat, 08 Aug 2026 12:38:25 +0000

Every voice-agent tutorial has the same arc.

You wire a browser mic into an LLM, add a pleasant synthetic voice, ask it to book an appointment, and declare victory somewhere around minute 37.

That's fine as a demo. It is not a product.

The gap shows up the first time you try to sell it to an actual customer. They do not want to open your web app and click a microphone button. They want a phone number. Their customers want to call it. You need to know which tenant owns that number, which assistant should answer, where the transcript goes, how long the call lasted, whether that usage should be billed, and what happens when someone texts STOP because the carrier rules are not optional.

That is the boring plumbing every tutorial skips.

And, annoyingly, it is most of the work.

The demo is easy. The tenant boundary is not.

A single-tenant voice agent can get away with a pile of environment variables:


bash
TWILIO_NUMBER=+15551234567
VAPI_ASSISTANT_ID=asst_abc123
STRIPE_PRICE_ID=price_xyz