Use case
Booking System for Meeting Rooms
If your company runs on Office 365, you already own a meeting room booking system and nobody told you.
Room mailboxes in Exchange do this. You create the room as a mailbox, set it to auto-accept when free and decline when busy, and it appears in the room finder in Outlook. It handles double-booking, it handles recurring meetings, and it costs nothing extra because you are already paying for it. Microsoft Bookings is the adjacent product people find first, but for internal rooms the room mailbox is the right tool.
Do that. Genuinely. Most people who search this phrase have the answer sitting in a tenant they already pay for, and a page that sells them something instead is wasting their afternoon.
The three reasons that answer fails
Not on Microsoft. Google Workspace has calendar resources that work the same way. If you are on neither, the free option disappears and the shortlist becomes real products.
You need the panel by the door. Exchange handles the booking; it does not light up a tablet outside the room in red or green, and it will not release a room when nobody shows up. That combination, a display plus auto-release, is what most paid room-booking products actually sell, and it is why the category exists on top of a calendar that already works.
The rooms are not yours. If you are booking rooms for customers, charging for them, or embedding the booking flow into a product you sell, a room mailbox is the wrong shape entirely. That is a product feature, and it is where building starts to make sense.
The parts that are harder than they look
Where a weekend build usually breaks
Double-booking is a database problem, not a UI problem
Checking availability and then inserting is a race: two people booking the same room in the same second both pass the check. The correct fix is a constraint the database enforces, which in Postgres means an exclusion constraint over a time range with a GiST index. Doing it in application code means you will eventually double-book the boardroom.
Recurrence is not a repeat checkbox
A weekly standup that moves once, skips a bank holiday, and ends after a quarter is the normal case, not the edge case. Storing a rule plus a set of exceptions, then expanding it into occurrences for a date range, is the design everyone converges on after first trying to store every occurrence as a row.
Time zones, and specifically working hours
Storing timestamps with a zone is the easy half. The hard half is that 'available 9 to 5' means a different absolute time in each office, and that the answer changes twice a year on dates that differ between countries.
No-show release is what people actually want
Rooms sitting empty on a full calendar is the complaint that gets a booking system funded. Solving it needs a check-in action and a scheduled job that frees the slot, which means you now have background work as well as a web app.
What the calendar pack gives you, precisely
pack-calendar is a working calendar: five views, drag to reschedule, event invites, and working hours. It installs a
CalendarEvent model with a title, description, colour, startAt and endAt, an organiser, and an array of attendee
ids, all scoped to an organisation.
That is a solid foundation for people booking time. It is not yet a room booking system, and the gaps are specific rather than vague.
What you add on top
- A room is not a model yetThere is no Room or Resource anywhere in the registry. Rooms need their own table with capacity, floor, and equipment, plus a foreign key from the event. Right now an event has attendees, not a location you can prevent from being booked twice.
- The exclusion constraintOnce rooms exist, the no-double-booking rule is a migration you write by hand. Prisma will not generate a Postgres exclusion constraint for you, so it goes in as raw SQL.
- RecurrenceCalendarEvent stores a single startAt and endAt. There is no recurrence rule and no exception list, so repeating bookings are a schema addition and an expansion function.
- Per-attendee responsesattendeeIds is a plain array of ids, so it records who was invited and not who accepted. Room booking rarely needs RSVP, but if you want no-show release you need some per-person state to hang check-in off.
- The tablet, and the job that frees the roomA panel view and a scheduled task to release unclaimed slots. The template runs Valkey locally, so there is somewhere to put a queue, but the worker is yours.
pack-calendar requires the starter-saas-workos pack, so authentication and organisations arrive with it rather than being separate work.
Is that a better trade than buying one
For an internal room booker, usually not, and you should take the room mailbox.
For a room booking feature inside a product you are selling, it is a good trade, because the calendar, the auth, the organisations, and the drag-to-reschedule interface are the parts you were going to spend the first month on. What is left is the room model, one SQL constraint, and a recurrence rule, which is a much smaller and more interesting problem than starting from an empty repository.
The install below is where that starts. open-calendar is the template to look at first, since it is the one built
around this pack.
What is Hype Stack?
Every product starts with the same month of work nobody pays you for: sign-up and login, teams and permissions, taking payments, notifications, an admin panel to run the business. Hype Stack is that month, already built and tested. Start from the free open-source app, add the pieces you need with one command, and keep going on the part that is actually your idea.
Everything lands as real code in your own repository, so there is nothing to rent and nothing anyone can switch off. For the engineers: React 19, Hono, Postgres, and a desktop build, typed end to end.
See it running
Templates are curated project starters built on this stack: a layout, feature packs, a custom theme, and bonus pages. The previews below are recordings of the real apps.
Packs in this stack
Every pack ships real source code: frontend, backend, and admin surfaces where the feature needs them. The ones this stack installs come first; the rest can be composed in later.
Two ways to install features
Same features underneath, different starting point. Either command resolves what the packs depend on, copies the source into your repository, and merges the Prisma schema.
Take a template
A landing page, a design system, a themed layout, and the features already wired into it. Rebrand it, put your product in the middle, ship.
npx @hype-stack/cli template$ hype-stack compose
Compose your own design
Your design and your choices, without rebuilding auth, billing, or notifications. Tick the packs you want and the CLI wires them into the open-source starter.
npx @hype-stack/cli composeQuestions, answered
More stacks
Turn your ideas into
Real applications.
Start free and own every line you ship. When you want more, one All-Access license unlocks every premium pack and template for a year.