# Zulu Case Study: Meetings Workspace Rebuilt Source: https://www.plutonapps.com/work/zulu Published 2026-09-30, updated 2026-10-28. By Irfan Habib (https://www.plutonapps.com/authors/irfan-habib). This case study covers the system Plutonapps rebuilt under the client's screens: one workspace walled off from the next, booking times that hold across daylight saving, a transcript written once, and links nobody can forge. ## At a glance Zulu is a meetings workspace for teams: video rooms with live captions, booking pages, events, forms and a contact book, where each call can become a searchable memory. The client brought a working prototype; Plutonapps kept its screens and rebuilt the system underneath, from workspace isolation to time-zone-safe booking. It is pre-launch, with 792 automated test cases, one of which checks all 67 workspace-scoped tables for leaks between tenants. - **Product:** Meetings workspace: video rooms, live captions, booking pages, events, forms, contacts and meeting memory - **Plan:** Plutonapps Custom (Growth) plan - **Status:** Pre-launch - **Front end:** React 19 with TanStack Router and TanStack Query - **API:** Hono on Bun, in TypeScript; the same build runs request traffic and, as a second service, background jobs - **Database:** PostgreSQL with Drizzle ORM: 70 tables, 15 migrations - **Real time:** Agora video calls and speech-to-text captions - **Services:** Clerk sign-in, Resend email, Google Gemini recaps - **Tests:** 41 test files, 29 of which run on PGlite, PostgreSQL compiled to WebAssembly, rather than a mock - **Timeline:** Repository opened August 31, 2026. Its history starts with one commit that brought up the whole monorepo, followed by ten feature commits to September 3, 2026 - **Figures:** Counted from the product's own repository, its code, schema and test files, at its last commit on September 3, 2026 > The shipping speed with the detailed documentation is what fascinated me. > > — Zulu · Custom plan ## What did the client bring to Plutonapps? The client arrived with a working prototype of the whole product: meetings and rooms, events with registration, booking pages, forms, contacts and a memory of past calls. Its screens and navigation were right, and we kept them. The signed-in shell, the event grid and the home screen were ported from it. What sat underneath was not ready for other people's data, so we rebuilt it. ## Why could it not go live as it was? The prototype left workspace separation to the database's row policies, and six of its twelve meeting operations matched on an id alone. Its browsers elected their own caption writer, so one dropped message removed a sentence from everyone's transcript for good. Its booking check never consulted the schedule, its confirmation emails waited on a job nobody ran, and two of its token signers fell back to a public key or a fixed string when a secret was missing. Plutonapps rebuilt six parts of the system under the prototype's screens: workspace isolation, the live transcript, availability across daylight saving, slot holds, signed links, and saves and emails. Each row sets the risk beside what replaced it. ## Product decisions ### One workspace, every kind of meeting Meetings and rooms, events with registration, booking pages, agendas, forms and a contact book sit in one workspace, under one navigation ported from the prototype. Modules not built yet stay in the menu, disabled, so the order never has to be decided again. ### Meetings that leave something behind When a call ends, its transcript becomes the meeting's memory: searchable line by line, with a recap of decisions and action items. Items a person wrote or edited survive a regeneration unless they choose to discard them. ### Guests without accounts A guest joins from a link, a visitor books from a public page, and a registrant manages their place from their email. Each link grants exactly one thing, and nothing else in the workspace. ## What did Plutonapps engineer? ### One workspace walled off from the next Risk in the prototype: The prototype left separation to the database's row policies, and six of its twelve meeting operations matched on an id alone. One of its four memory searches read across workspaces. Zulu's workspace boundary now lives in the application, where the unsafe query cannot be written by accident. Every read and write goes through one object that adds the workspace to the condition itself, and bypassing it takes a named call that can be found and reviewed. 67 of the 70 tables carry their workspace directly. The other three sit above any one workspace: the workspaces table itself; users, who can belong to several; and incoming payment events, recorded before their workspace is known. A test lists the 67 from the schema, fills two workspaces with the same data and proves one cannot read, change or delete the other's rows. A foreign id answers not found. ### A transcript written once, without holes Risk in the prototype: Captions reach every browser in a call. The prototype let the browsers elect a writer among themselves, so two could write every sentence, one bad id silenced the room, and one dropped message deleted a line for everyone. Zulu's server elects the writer under a lock and gives it a lease that expires, so if the writer's laptop closes, the next person to ask takes over with no tiebreak. Each line has a natural key of speaker, time and text, which makes a retry after a network drop safe: a duplicate cannot land. Lines carry the speaker's name rather than six digits of a hash, and a late joiner is shown the latest lines, not the first ones. ### Booking times that survive daylight saving Risk in the prototype: A booking page that offers a time its host cannot keep puts a stranger in front of an empty room. Zulu does all its booking clock arithmetic in PostgreSQL, which carries the time-zone database. Days are generated as calendar dates, never as 24-hour steps, so a 23- or 25-hour day can neither skip nor repeat a slot. The host's preview and the visitor's page run the same query, which subtracts bookings, live holds and the host's own meetings, and applies buffers, minimum notice and the daily limit when it is read. ### Two visitors, one slot, one booking Risk in the prototype: Two people can reach for the same half hour at once, and the prototype's booking check never consulted the schedule: a request for 03:00 on a Sunday was accepted. In Zulu, holding a slot takes a transaction lock keyed on the host's schedule rather than the instant, so overlapping times on sibling pages queue behind each other too. Inside it the whole availability check runs again for that one instant before a ten-minute hold is written, and abandoned holds are reclaimed on the next attempt. A unique index lets only one confirmed booking exist per page and start time, whatever the application does. ### Links nobody can forge Risk in the prototype: Guest invites, booking links and recording URLs are credentials. Two of the prototype's signers fell back to a public key or a fixed string when a secret was missing, so every token they minted could be forged. Every signed link Zulu mints now comes from one signer, tested in one place. Keys live on a ring, so a new key signs while the old one still verifies and rotation is a window, not an outage. Links kept in the database are stored only as hashes, and a leaked guest link can be revoked before it expires. The server refuses to boot on a missing, short or placeholder secret, and names every one at once. The prototype's seven competing settings for the app's own address, each with its own fallback, became one, checked at boot. ### Saves that finish, emails that arrive Risk in the prototype: The prototype's instant booking confirmations were queue rows drained by a job nobody ran, and saving a weekly schedule deleted the old hours before writing the new ones, outside a transaction. Zulu sends a confirmation as soon as the booking commits, and a mail outage cannot roll back an appointment that already exists. A schedule's week is replaced in one transaction, so a failed save leaves the old hours standing rather than an empty calendar. The background-jobs service checks at boot that it serves no public routes, so an unwatched second copy of the API cannot appear by accident. ## What were the results? - **792** Automated test cases, across 41 test files - **67 of 70** Database tables scoped to a workspace and swept by a cross-tenant test - **21** API modules, from meetings and captions to bookings and contacts - **0** Meeting operations that match on an id alone, down from 6 of the prototype's 12 - **0** Token signers that fall back to a public key or fixed string, down from 2 - **1** Setting for the app's own address, checked at boot, in place of the prototype's 7 ## Outcomes - 792 automated test cases across 41 test files. - 70 database tables, 67 scoped to a workspace and swept by a cross-tenant test. - One signer for every signed link the product mints, with keys that rotate. - Pre-launch: built, tested and documented on a custom-priced (Growth) plan. ## What do we hold ourselves to while it runs? - **Tenancy:** Every query scoped to one workspace, swept by a test - **Bookings:** One confirmed booking per slot, enforced by the database - **Transcripts:** One elected writer; a retried line never lands twice - **Secrets:** No fallback keys; the server will not boot without them ## What else should you know about Zulu? ### How does Zulu handle time zones? The day a person sees as today is worked out in their own time zone, not the server's, and booking availability is computed in the database's time-zone rules, so a day made shorter or longer by a clock change neither skips nor repeats a slot. ### What did Plutonapps build for Zulu? The system under the client's prototype: workspace isolation on every query, a booking engine that works out availability in the database's time-zone rules, a server-elected transcript writer, one signer for every signed link, and an automated test suite that runs most of its files on a real PostgreSQL engine. ### What does a Zulu meeting leave behind? Its transcript becomes the meeting's memory, searchable line by line, with a recap of decisions and action items. Items a person wrote or edited survive when the recap is generated again, unless they choose to discard them. A memory can be shared by a link that is stored only as a hash. ### Can guests take part without an account? Yes. A guest joins a call from an invitation link, a visitor books from a public page, and a registrant manages their place from their email. Each link is signed for one purpose, and a leaked guest link can be revoked before it expires. ### Is Zulu live? Not yet. Zulu is pre-launch: its system is built and tested, and it is being hardened for launch.