Coordinate launches across every reviewing function. Launchers get a generated checklist, reviewers get a clean queue, stakeholders get the calendar.
Why it exists
Every company big enough to have a legal team has a launch process, and almost none of them have it written down in one place. It lives in a spreadsheet somebody inherited, a doc that was accurate two quarters ago, and the memory of the one person who has shipped enough times to know who signs off on what. New launchers find out they needed a privacy review the week they were supposed to ship.
LaunchCal makes the process the product. A launcher describes what they are shipping, and the checklist assembles itself from the templates each reviewing function owns. Reviewers stop being interrupted in chat and get a queue instead. Everyone else gets a calendar that says what is going out and when, which is the question most of the company actually has.
Inspired by the way this was run at Google: the parts that earned their keep, without the parts that only work at that scale.
What you get
- Launch step templates per functional team
- Reviewer queues with approve / deny / exception
- Press release, dashboard and learnings artifacts
- Launch calendar and steps Gantt for stakeholders
How it works
- 1Each function writes its steps onceLegal, privacy, security, support, marketing: whoever has to look at a launch owns a template of what they need and when they need it. Written once, it applies to every launch that follows.
- 2A launcher describes the launchThey fill in what it is, who it affects and when it should go out. The checklist builds itself from the templates that apply, so nobody has to know the process to follow it.
- 3Reviewers work a queueEach function sees the steps waiting on them, and approves, denies or grants an exception with a reason attached. The launcher watches the whole thing move without chasing anyone.
What teams use it for
Shipping to a deadline that already slipped once
The calendar shows which steps are blocking and who holds them, so the conversation is about the actual dependency rather than about who forgot to reply.
Onboarding somebody launching for the first time
They do not need the tribal knowledge. The checklist tells them what is required, and the exceptions tell them what was waived and why.
Answering “what is going out this quarter?”
The launch calendar and the steps Gantt are the answer, and they are current, because they are the same thing the launchers are working from.
Common questions
- Do we have to change how we run launches?
- No. The step templates describe the process you already have: LaunchCal is where it lives rather than a different process. Most teams start by writing down what they already ask for and refine it after a launch or two.
- What happens when a step does not apply?
- A reviewer grants an exception, with a reason. It is recorded on the launch rather than silently skipped, so the next person to ask why can see the answer.
- Can stakeholders see launches without a seat?
- Seats are for the people doing the work: launchers and reviewers. The calendar is what most of the company wants, and it does not need one.
- How does this relate to our issue tracker?
- A tracker holds the engineering work. LaunchCal holds the approvals and the date, which is the part that tends to live in chat and spreadsheets instead.
The rest of the platform
One workspace, one bill, one set of members. Add an app whenever you need it.