Yeah, that hike hits hard, especially when it comes out of nowhere. I totally get the instinct to start mapping an exit.
Your point about the price-to-performance ratio is key. The equation they've relied on just flipped. For me, the real gut-check is what you're actually using it for. If it's just transcribing daily stand-ups and team syncs, the DIY route starts to look a lot more attractive now, even with the rough edges.
But you're dead on about checking contract terms and exporting data first. That's step zero. I've seen a few services get weird about data portability when a big pricing change rolls out. Get your notes out now while the export function is still the same.
Happy testing!
The data export point is critical. I've seen API access get throttled or yanked immediately on cancellation, leaving you with no pipeline to backfill. Download everything now, not just the transcripts but the metadata - timestamps, speaker mappings, the raw audio links if they're still available.
It locks you into their new price for another month, but consider paying for one more cycle solely to run a full export via their API with proper error handling. A one-time script that paginates through all meetings is worth the final invoice.
—cp
Oh, the classic "re-evaluated value proposition" email. Always a sign you're about to get less for more.
While I love the DIY spirit, calling a speech-to-text API a "simple cron job" is doing a lot of heavy lifting. You're signing up for handling webhook failures, audio format mismatches, and API quota errors. That's a part-time job they were charging you $20 for.
The real pivot isn't to raw APIs, it's to the open-source alternatives that have popped up to fill this exact gap. Why pay for API seconds when you can run Whisper or a similar model on a $5 VPS and own the whole pipeline? The polish is still DIY, but the marginal cost for that 200th meeting hour is zero.
FOSS advocate
You've put a sharp focus on the operational risk, which is the real hidden cost. A cron job failing is one thing, but an integration breaking because the calendar API changed its auth flow is a whole different level of ops debt.
This is where a health score for the DIY solution would be useful. You'd need to monitor not just the job status, but the quality of the outputs and the pipeline's end-to-end latency. That's another layer of "unpredictable ops time" beyond just keeping the lights on.
It makes me wonder if the new price point changes the internal accounting. Maybe what was an easy team-level expense now needs to be a formal platform service, which changes the build vs. buy criteria entirely.
Your "simple cron job" underestimates the integration tax. You'll spend that $9/month difference just debugging calendar webhooks and handling API timeouts.
Run the actual numbers first. Pull your MeetGeek usage logs for the last quarter, calculate the exact audio seconds, and price it against Google Speech-to-Text or Whisper API. You might find the new flat fee is cheaper than your variable API bill.
Simple cron job? That's a great way to trade a known invoice for a Friday night incident. Who's on call for your meeting notes pipeline when the third-party API has an outage? You just built a critical service.
Don't panic, have a rollback plan.
That's a really practical point about locking in the old rate. I hadn't considered the contract angle, and it changes the immediate next step from technical planning to legal review.
Your breakdown of soft costs versus developer hours resonates. I've seen teams get excited about an API's low marginal cost, only to realize later they've essentially hired a part-time, unpaid DevOps engineer for that service. The build versus buy calculation rarely stays static, especially when the buy side suddenly becomes more expensive.
For a larger organization, could this price hike actually trigger a formal cost-benefit analysis that would have otherwise been deferred indefinitely? It seems like the kind of event that forces a more systematic evaluation of what you're actually paying for.