Publishing Your App

Third-party apps are submitted and deployed via GitHub. This gives code review, CI/CD, and audit trails for free.

How it works

1. You build your app in your own private GitHub repo
2. You grant read access to the Saaslivery GitHub org
3. You submit via apps.saaslivery.com/developers
4. Automated CI validates your app
5. The platform team reviews your code
6. Approved apps deploy to staging, then production

Repository structure

Your app lives in its own repo. On the platform side, it's mounted as a git submodule:

microcessor/                    (platform — private)
├── apps/                       (core apps)
├── plugins/                    (third-party apps)
│   ├── acme-invoices/          ← submodule → your private repo
│   ├── bob-timetrack/          ← submodule → bob's private repo
│   └── ...

Developers never see each other's source code. Each developer owns their private repo.

Pre-submission checklist

Before submitting, verify your app meets all platform requirements:

• [ ] manifest.py has all required fields (name, slug, publisher, version, description, plugin)
• [ ] Slug follows naming rules (lowercase, alphanumeric + hyphens, starts with a letter, max 30 chars)
• [ ] plugin.py uses App(debug=False)
• [ ] plugin.py does NOT register ASSETS(), CORS, or sessions
• [ ] UI routes are on the wildcard subdomain under the /app/{slug}/ prefix, never a named subdomain
• [ ] All handlers are type-annotated: (req: Request, res: Response, ctx: Context)
• [ ] All status codes use HTTPStatus constants
• [ ] Templates are flat in templates/, namespaced via app.TEMPLATES(..., prefix="{slug}")
• [ ] Protected routes have entries in authz.py, and handlers read pre-loaded resources from ctx.authz
• [ ] Maximum 10 tables in migrations/, all migrations idempotent
• [ ] All tables include a workspace_id column, and every raw query filters on it
• [ ] All emitted events are declared in the manifest
• [ ] Event names use ext.{publisher}.{app}.* namespace
• [ ] All event handlers are idempotent
• [ ] No direct imports from other apps
• [ ] No JavaScript build step
• [ ] HTMX for server interactions, Alpine.js only for client-side logic
• [ ] API routes namespaced under /{slug}/*
• [ ] Tests pass via Earth test client

Submission flow

1. Build your app

Follow the project structure and the manifest spec.

2. Register as a developer

Create a developer account at apps.saaslivery.com/developers. Choose your publisher ID — this is globally unique and permanent.

3. Grant repo access

Add the Saaslivery GitHub bot (or org) as a read-only collaborator on your repo.

4. Submit

Fill out the submission form at apps.saaslivery.com/developer/apps/new:

• Repo URL
• Long description (Markdown, max 5000 chars)
• Up to 5 screenshots
• Category and tags

5. Automated CI runs

The platform validates:

6. Code review

The platform team reviews your code for security, quality, and compliance.

7. Staging deployment

Approved apps are added as a submodule and auto-deployed to staging for QA.

8. Production deployment

After QA passes, the submodule ref is updated on the main branch and auto-deployed to production. Your app appears on the marketplace.

Updates

1. Push updates to your repo
2. Open an "update request" via the developer dashboard (or webhook)
3. CI re-validates the new code
4. Platform team reviews (automated-only for patch versions)
5. Approved updates deploy through the same staging → production pipeline

Revenue

For paid apps, the revenue split is:

Payouts are monthly, 30 days after the billing period closes. Minimum payout: $50 (rolls over).

Track your revenue at apps.saaslivery.com/developer/revenue:

• Total revenue across all published apps
• Per-app breakdown by pricing dimension
• Install counts and active workspaces
• Payout history