Podcast studio booking software

The problem is rarely "we need a calendar". It is that a studio's price list doesn't fit a calendar tool's idea of a service. A salon sells a 45-minute haircut. A studio sells Studio Two for however many hours the client wants, with a wide-angle lens, cloud storage and an on-screen logo priced separately. Most of the software you'll find is built around the first shape.

Start from what you sell in an hour

Write the rate card out before opening a single pricing page. For a studio group it usually holds four things: the rooms and the hourly rate of each, the session lengths you'll actually sell, the extras and how each is priced, and whatever is included in the rate (an engineer, for many studios).

Each of those maps to a software question. Rooms with different rates means one bookable item per room. Session lengths mean the same room can be booked for different durations without the room double-booking. Extras mean add-ons chosen at checkout that change the total. An included engineer means it's the room's availability you compute, not a person's, unless engineers are booked separately.

Five questions a demo has to answer

Ask these of any tool, and ask for them to be shown, not described:

1. Book Studio Two for three hours on a Thursday. Now try to book it for one hour inside that window. Does the second attempt fail?
2. Add a per-hour extra to a three-hour booking. Does the total change on its own?
3. Give two rooms different hourly rates. Is that a setting or a workaround?
4. Where does the customer actually book, on your domain in your design, or on a page you can only partly style?
5. A customer reschedules from two hours to one. What happens to the price and the extra?

The first is the one that separates tools. Some tools have you create a "one hour" service and a "two hour" service per room. Whether those block each other depends on how the tool ties them to the same calendar, so don't take the sales page's word for it. Ask, then watch it happen.

Podyx, and what it costs

Podyx is the dedicated option. It is built for podcast studios, and the public pricing page lists two plans: Essential at $49 a month and Premium at $99, both with a 30-day free trial. Stripe payments carry a 1% fee on top. Both plans include multi-room, multi-setup booking, bundles and packages, add-ons at checkout and a branded booking page. Premium adds iframe embeds, custom fonts, subscriptions, a client CRM, analytics and a customer success manager.

If you want operations software for a studio, with the CRM and the analytics, and you have nobody who'll build a booking flow, I'd pick Podyx over anything I sell. The trade is design control. The booking page is theirs and branded for you, and embedding it in your own site is a Premium feature. I couldn't confirm from their public pages whether a page can sit on your own domain, so ask in the demo.

Read the Opencals columns with their conditions. The fixed plan's $14.98 covers 300 appointments a month, and flexible duration, the feature that lets a customer choose one, two or three hours, is a $9.98 add-on on that plan, so a studio needing it pays $24.96 a month before card fees. On the per-booking plan every feature is included, and it is only cheaper than the fixed plan below about 15 bookings a month. A studio doing 100 sessions a month pays roughly $25 on the fixed plan and about $99 on per-booking pricing. I checked these on the pricing page today; they change, so check again.

When the generic storefront is enough

Every Opencals store comes with a hosted storefront, and you can point a studio at it without writing code. You model each studio as a product with custom duration, attach the add-ons, and the storefront shows options and extras during booking, with some logic about when to show them. It will not look like a bespoke site. It will look like a clean, configurable booking page, and for many studios that's sufficient.

I'd start there. The reason to leave it is a flow the storefront can't express: a package builder that rewrites the room list as the client picks a format, a booking step that sits between two screens of your own marketing pages, or a design where the booking is the site. That's where the API comes in.

What building on the API looks like

A London studio group with five studios did exactly that. They built their booking widget on the Opencals Storefront API in an evening, in their own design, with hourly rooms and priced add-ons. Two UK podcast studios now run custom integrations this way.

The building is less work than it sounds because the API owns the hard parts: availability across rooms, session lengths, add-on pricing, payment and reminders. What you write is the part the customer sees. And you write it against a free development store, so nothing is paid until you switch to production. The full walkthrough, with the calls, is in the developer guide to a podcast studio booking flow. If you'd rather hand the build to an AI tool, the Lovable, v0 and Base44 articles cover the setup.

What a studio still has to solve elsewhere

Opencals is booking, payments and reminders. It is not a client CRM built around your guests, and it won't run your editing queue or track gear. If those matter as much to you as the calendar, Podyx's Premium plan is aimed at exactly that, and I'd weigh it seriously.

The development store also ships with sample businesses for salons, a barbershop, a clinic, a gym and a spa, but not a studio, so you enter your rooms and rates yourself. And the hosted API is closed-source; the SDK and the templates are MIT-licensed. If you want the general picture of that split, the booking API overview explains it.

If you are choosing today: a studio with no developer and an operations wish list should take a 30-day Podyx trial. A studio whose booking page is part of its brand should create a free development store and put one real booking through it. That takes an evening, and it costs nothing to find out that it doesn't fit.