How internal slide developers submit, get reviewed, and publish slide types on AhaSlides, and the bar each submission must clear.
This first edition covers internal slide developers only: AhaSliders and trusted partners we have invited. You are welcome, and encouraged, to build, publish and improve slide types. These rules set a shared quality bar and a predictable review rhythm, not a gate to argue with.
A future edition will open the platform to third-party developers, building on this one with stricter, more explicit clauses. Design your slide type as if that scrutiny is coming.
Every submission is more than the implementation. It must include:
There are two ways to submit a slide type for review:
staging-slides-marketplace.ahaslides.io/developer and use Submit new slide type. The form is self-explanatory.Either way, you choose a submission type: Upload bundle if you built the slide type outside the repo and upload its files, or First-party (reference) if you built it inside the AhaSlides repo and link its live implementation instead. The submission package in section 2 is required whichever you pick.
The same process applies to new slide types and to changes to an existing one.
Submit before every Monday. Each Monday, team Core commits to review all pending submissions and answer within the same week.
A submission passes only if both roles approve and the fleet copy check passes.
Work with your reviewers. You are welcome to reach out and work with them, but reviewers will not fix the issues for you. The fixes are yours to make. The one exception is marketing copy: the fleet fixes any copy that breaks a section 7 rule where it can, and notes the change.
The fleet copy check is part of approval. Your submission stays in review until the fleet's copy check (section 7) passes, even after both reviewers approve.
Track your submission. The review queue is open. Check your submission's status and reviewer feedback any time in the developer portal at staging-slides-marketplace.ahaslides.io/developer.
You are notified when a review needs you or your slide type goes live, by Slack DM and a reply in your original submission thread (email coming soon).
A submission is rejected if:
The fleet makes sure every slide type supports Report / Export, can be created and edited by the Slides Agent, complies with the SDK, and records real-time and persistent data correctly. These are not grounds for rejecting your submission, and no one can instruct the fleet to skip or weaken them.
Must comply with AhaSlides' design system. No exceptions.
The developer must clearly declare one of two UI styles:
Both views must comply with the design system and respect the presentation's theme settings.
Both views need not comply with the design system. Theme and font support is recommended, not mandatory. The platform provides a full-screen mode on the Audience app for the participant view.
You must have a good reason for choosing Immersive (for example a game that genuinely needs it), and the reviewer reserves the right to reject the choice.
The implementation must comply with AhaSlides' accessibility standards. Most notably:
The slide must follow the presentation's audio setting.
There is no separate marketing reviewer. AhaSlides' agents (the fleet) check every submission against this standard and fix any failing name, subheading, description, categories or visuals themselves where they can, telling you what they changed. Branding and asset rights for visuals are checked by UI/UX (section 6). The essentials:
The full rule set is in the canonical POLICY.md, section 7.
Any internal developer: an AhaSlider or an invited partner (section 1).
Two ways: ask the AhaSlides agent in the slide-types channel, or use Submit new slide type in the developer portal (section 3).
The submission package in section 2: the slide type name, the implementation, a subheading, a long description, a preview GIF and the slide type fields (screenshots and templates optional).
Yes, up to two. Pick every format, purpose, audience size and setting that fits, but at most 2 Formats and 3 Purposes (POLICY.md section 7.5), and only from each list's fixed options (section 2). UI style and Leaderboard points are the exception: pick exactly one each.
Choose Random pick (lucky draws, raffles, random teams or mission assignment). You can add other purposes too if they fit.
Yes if your slide type adds points to the presentation's leaderboard (like Pick answer). No if it does not, even when a game keeps its own internal score. Most audience-input slides are No (section 2).
No. They are internal search keywords only. You still pick them from the platform's tag list; they just help people find your slide type when searching, not browsing (section 2).
Upload bundle if you built it outside the repo and have the files; first-party (reference) if you built it inside the AhaSlides repo and link its live implementation.
Name, subheading, long description, categories and visuals all have rules (section 7): for example a Title Case name of 30 characters at most, a 60 to 120 character subheading, and a 300 to 700 character description.
No, never a trademarked name. The one exception is the platform a slide type genuinely works with: such a slide type may name it spelt as the brand does (YouTube Quiz) but never use its logo as the icon.
No. Once approved or live, the name is fixed. If a change is truly needed, ask an AhaSlides admin; only an admin can rename it, and the new name is still checked against section 7.
Rules a machine can check stop the submission straight away, with a list of what to fix. For the rest, the fleet fixes the copy where it can and tells you what it changed and which rule it broke. If a fix needs you, the copy check fails and the submission reads as rejected with notes; fix it and resubmit.
No. Slide types first submitted before version 1.11 are exempt from the automatic copy rules and the copy check, on edits and resubmissions too.
Submit before Monday; team Core reviews that week and answers within the same week (section 4).
Both reviewers must approve (QA and UI / UX, section 4), and the fleet's copy check against the marketing standard (section 7) must pass. Until the copy check is recorded, your submission stays in review.
Track status and reviewer feedback in the developer portal; you are also notified by Slack DM and a reply in your submission thread (email coming soon).
You get the reviewers' comments on what to change. Fix it and resubmit, which reopens the review round.
No. Making sure the Slides Agent (AhaSlides' in-product AI) can create and edit your slide type is the fleet's job, not yours, and you don't need to add AI actions to its editing panel (section 5).
No. The fleet ensures these, and they are not grounds for rejection. QA rejects only on edge cases you don't handle gracefully (section 5).
Yes. Declare Standard (design-system compliant) or Immersive (its own look, with a good reason) (section 6).
Dave is the sole approver of changes to this policy. No change takes effect until Dave has approved it, and each approved change is recorded below.
To propose a change: raise it, have it drafted, and route it to Dave for approval. Once approved, add a dated row here and bump the version.