SaaS-replacement extensions

Each extension replaces a standalone SaaS product. Install it or build your own with AI.

Move Big Rocks extensions replace entire standalone SaaS products — ATS, error tracking, analytics, CRM, feature requests — on the same shared base. Every extension you install is one fewer vendor with access to your data, your credentials, and your employees' identities. The first-party set is currently free. Teams can also build their own extensions with Claude Code, Codex, or any AI coding assistant, using the same SDK and runtime model as the first-party extensions.

Read install guide Build an extension

Agent-first route: Start at /agents, inspect /docs/cli, and drop into this page when you need proof, detail, or rollout guidance.

Agent-first route

Humans should usually delegate first-pass evaluation to an agent. Agents should start at /agents, use /docs/cli as the official product tour, and open /docs/graphql only when needed.

Agent-ready surface

Start with the CLI, not browser guesswork.

Preferred route: /agents, then /docs/cli, then /docs/graphql only when lower-level integration details matter.

$ mbr spec export --json
$ mbr auth whoami --json
$ mbr queues list --workspace ws_preview --json

Open GraphQL reference | Open schema.graphql

Best extended from a team-owned base

Extensions are useful here because the core already owns identity, permissions, queues, cases, knowledge, audit, routing, CLI, and GraphQL.

Public extension rack

ATS, community feature requests, error tracking, sales pipeline, and web analytics are the current free public first-party bundle set.

Bundle-first by default

Start with a workspace-scoped standard-risk bundle extension. Only move to a service-backed runtime when the requirement truly needs it.

Owned schema when needed

Service-backed extensions can own their own `ext_*` PostgreSQL schema and migration history instead of leaking state into core tables.

Proof

Definition docs/ARCHITECTURE.md Defines runtime classes, shared routing, event-driven integration, and extension-owned `ext_*` PostgreSQL schemas.
Definition docs/EXTENSION_ENDPOINT_MODEL.md Defines endpoint classes, core-owned routing, and concrete analytics and error-tracking endpoint patterns.
Definition docs/EXTENSION_SECURITY_MODEL.md Defines trust classes, review gates, and the requirement that extensions use the same outbox and event-bus pattern as core.
Implementation internal/platform/domain/extension.go Defines runtime class, storage class, endpoint class, and manifest fields for extensions.
Implementation internal/platform/domain/extension_runtime.go Enforces that only service-backed `owned_schema` extensions can register owned schemas.
Implementation internal/infrastructure/stores/sql/extension_runtime_store.go Stores extension package registrations and schema migration history in the shared core runtime store.

Same outbox and event model

Extensions publish and consume typed events through the same outbox and event-bus pattern as core.

Proof

Definition docs/EXTENSION_SECURITY_MODEL.md Requires extensions to use the same outbox and event-bus pattern as core whenever they publish or consume events.
Implementation internal/infrastructure/stores/shared/interfaces.go Defines the shared outbox and idempotency interfaces used for reliable event publishing and handling.
Implementation internal/infrastructure/stores/sql/analytics_db.go Shows the analytics extension using its own `ext_demandops_web_analytics` schema.
Implementation internal/infrastructure/stores/sql/error_monitoring_store.go Shows the error-tracking extension using its own `ext_demandops_error_tracking` schema.

Used by the builder

The first-party extensions started as things Adrian McPhee needed in the DemandOps portfolio. Error tracking and web analytics replaced separate SaaS tools in daily use, ATS and sales pipeline are in active use, and the extension path was then made public so other teams and agents can use the same model.

Table of contents

Section map.

Jump directly to the part you need.

The first public bundle set should feel like a real add-on catalog, not a hidden implementation detail. First-party catalog Move Big Rocks is worth extending because the hard shared boundaries are already in place. Why extend here An extension is a bounded capability slice on the shared product base. What an extension is Bounded means powerful, but not sovereign. What bounded means The extension architecture is explicit about runtime class, storage, routes, and events. Runtime architecture Extensions fit when the workflow needs more than the shared core but still belongs on the same base. In Practice The default extension setup path is intentionally simple. Setup path The repo and publication model should stay explicit. Repo and publication model Bounded extensions move through a sequence a human or agent can reason about. Lifecycle and constraints

First-party catalog

The first public bundle set should feel like a real add-on catalog, not a hidden implementation detail.

The current public positioning is straightforward: publish the standard-risk first-party extension set as signed OCI bundles from the first-party extensions repo, make the install refs obvious, and keep the runtime policy explicit in each manifest.

ATS

Applicant tracking with careers-site and candidate workflow depth on the shared base. Public source lives in `extensions/ats` and installs from `ghcr.io/movebigrocks/mbr-ext-ats`.

Community feature requests

Public idea collection and voting on the same base. Public source lives in `extensions/community-feature-requests`.

Web analytics

Privacy-first analytics as a first-party service-backed extension with public ingest, admin dashboards, and extension-owned analytics state. Public source lives in `extensions/web-analytics`.

Error tracking

Sentry-compatible ingest and issue workflows on the same operational base. Public source lives in `extensions/error-tracking`.

Sales pipeline

Lightweight opportunity management with extension-owned state, seeded intake, and an admin board. Public source lives in `extensions/sales-pipeline`.

Enterprise access

First-party privileged identity extension with instance-scoped install, OIDC configuration, and owned provider state in the shared first-party extensions repo.

The intended public OCI refs are `ghcr.io/movebigrocks/mbr-ext-ats:<version>`, `ghcr.io/movebigrocks/mbr-ext-community-feature-requests:<version>`, `ghcr.io/movebigrocks/mbr-ext-error-tracking:<version>`, `ghcr.io/movebigrocks/mbr-ext-sales-pipeline:<version>`, and `ghcr.io/movebigrocks/mbr-ext-web-analytics:<version>`.
The current public default is OCI distribution, not a marketplace catalog.
The source and machine-readable release catalog live in the first-party extensions repo at `MoveBigRocks/extensions`, including `catalog/public-bundles.json`.
The public runtime source for service-backed first-party extensions now lives under `error-tracking/runtime` and `web-analytics/runtime` in `MoveBigRocks/extensions`.
Release tags in the first-party extensions repo follow `ats-v<version>`, `community-feature-requests-v<version>`, `error-tracking-v<version>`, `sales-pipeline-v<version>`, and `web-analytics-v<version>`.
Public signed bundles can install directly from GHCR without a token. Controlled instance-bound bundle flows can still use `--license-token`.

Why extend here

Move Big Rocks is worth extending because the hard shared boundaries are already in place.

A good extension base is not just a plugin slot. It is a system that already solved identity, routing, work records, knowledge, CLI access, API access, and audit. That is why extensions here can stay focused on domain depth instead of rebuilding those foundations.

Proof bundle

Definition docs/ARCHITECTURE.md Defines extensions as bounded runtime classes attached to shared primitives, not disconnected product silos.
Definition docs/INSTANCE_AND_EXTENSION_LIFECYCLE.md Defines when work belongs in the instance repo versus a separate extension repo.
Contract docs/EXTENSION_SECURITY_MODEL.md Defines trust classes, unsupported extension categories, review gates, and allowed runtime slices.
Implementation extension-sdk/README.md Shows the canonical public scaffold for bounded custom extension authoring.

Shared identity and permissions

Extensions inherit workspace and team boundaries instead of inventing a separate auth and RBAC stack.

Shared work records

Extensions can request or attach to forms, queues, conversations, cases, and contacts instead of re-creating ticketing, inbox, or CRM fragments.

Shared knowledge and concepts

Extensions can seed and use the same Markdown-first knowledge and concept surfaces that humans and agents already use.

Shared operating surfaces

The CLI, GraphQL API, and admin shell already exist, so extensions can be inspected and operated through the same public and admin-facing surfaces.

Shared audit and rollout model

Install, validate, activate, monitor, and deactivate remain explicit human-visible lifecycle steps.

What an extension is

An extension is a bounded capability slice on the shared product base.

Extensions exist so Move Big Rocks can stay explicit about what belongs in core versus what belongs in a focused product slice. They are not supposed to reintroduce app sprawl under a different name.

Focused capability

An extension adds domain-specific depth such as recruiting, analytics review, or another operational slice.

Bounded state

It can own focused structured state and routes without owning the whole trust model.

Shared primitives

It still relies on the shared workspaces, teams, work records, knowledge, permissions, and audit surfaces.

Explicit lifecycle

Packaging, deployment, validation, activation, and rollback stay explicit.

What bounded means

Bounded means powerful, but not sovereign.

The extension model is useful because it draws a firm line between focused product depth and shared operational boundaries.

No new app silo

An extension should not become a completely separate operational system with hidden context and separate governance.

Shared identity and permissions

The access model remains connected to the same workspace and team boundaries people already manage.

Shared audit

Important actions and lifecycle changes remain visible in one place.

Shared evaluation flow

Agents and humans can evaluate the extension through the same public docs, CLI, and owned-runtime lifecycle.

Runtime architecture

The extension architecture is explicit about runtime class, storage, routes, and events.

The extension model is concrete, not hand-wavy. Bundle extensions are for bundle-first product extensions that own product vocabulary, assets, and workflows while still running on shared primitives. Service-backed extensions add handlers, jobs, event consumers, and extension-owned data while still going through core-controlled routing and lifecycle controls.

Proof bundle

Definition docs/ARCHITECTURE.md Defines runtime classes, shared routing, event-driven integration, and extension-owned `ext_*` PostgreSQL schemas.
Definition docs/EXTENSION_ENDPOINT_MODEL.md Defines endpoint classes, core-owned routing, and concrete analytics and error-tracking endpoint patterns.
Definition docs/EXTENSION_SECURITY_MODEL.md Defines trust classes, review gates, and the requirement that extensions use the same outbox and event-bus pattern as core.
Implementation internal/platform/domain/extension.go Defines runtime class, storage class, endpoint class, and manifest fields for extensions.
Implementation internal/platform/domain/extension_runtime.go Enforces that only service-backed `owned_schema` extensions can register owned schemas.
Implementation internal/infrastructure/stores/sql/extension_runtime_store.go Stores extension package registrations and schema migration history in the shared core runtime store.

Bundle versus service-backed

Use `bundle` runtime for bundle-first product extensions such as ATS, where the extension owns workflow vocabulary and presentation but still runs on shared primitives. Use `service_backed` only when you need custom server-side handlers, event consumers, scheduled jobs, or extension-owned data.

Owned PostgreSQL schema

A service-backed `owned_schema` extension can register its own `ext_*` PostgreSQL schema and track its schema migrations separately from core.

Core-owned routing

Core Move Big Rocks owns external routing, auth, rate limits, request tracing, and audit boundaries. Extensions declare endpoint classes and core mounts them into approved path families.

Typed events and outbox

Extensions should publish and consume typed events through the same outbox and event-bus pattern as core so retries, auditability, and operational visibility stay consistent.

Shared runtime registry

Extension installation state, desired schema version, current schema version, and migration history are tracked in the shared runtime store instead of being hidden in ad hoc deploy scripts.

In Practice

Extensions fit when the workflow needs more than the shared core but still belongs on the same base.

First-party and self-built extensions show what “bounded” looks like in practice. These extensions go deeper on the same shared base instead of turning into separate app stacks.

Proof bundle

Definition README.md Documents the first-party extensions repo, install refs, and release tag model.
Catalog catalog/public-bundles.json Machine-readable catalog for the free public first-party bundle set.
Release .github/workflows/public-bundles.yml Publishes the free public first-party bundle set to GHCR from the first-party extensions repo.
Definition extension-sdk/README.md Explains the bundle-first default and when to move into service-backed endpoints, jobs, consumers, and owned-schema migrations.
Definition extension-sdk/START_HERE.md Gives the local lint, verify, and sandbox lifecycle for a custom extension.
Definition docs/EXTENSION_ENDPOINT_MODEL.md Uses ATS, community feature requests, sales pipeline, web analytics, and error tracking as concrete endpoint and runtime examples.

ATS

ATS is a workspace-scoped first-party extension with vacancy lifecycle, branded careers assets, structured application intake, staged candidate review, and bundled agent skills. It is part of the free public first-party bundle set.

Community feature requests

Community feature requests is a first-party service-backed extension with a public board, voting flow, seeded triage queue, and admin status management. It is part of the free public first-party bundle set.

Web analytics

Web analytics is a first-party service-backed extension class because it needs public ingest endpoints, admin dashboards, extension APIs, and its own analytics data model while still fitting the shared routing and admin shell. It belongs in the free public first-party bundle set.

Error tracking

Error tracking is a first-party service-backed extension class because it needs Sentry-compatible ingest aliases, issue grouping, extension-owned state, and typed issue events that feed back into support and automation. It belongs in the free public first-party bundle set.

Sales pipeline

Sales pipeline is a first-party service-backed extension with extension-owned deal state, seeded intake handoff, and a workspace-native admin board. It is part of the free public first-party bundle set.

Private workflow extensions

Customer-built private extensions can add bounded operational portals, domain workflows, or admin surfaces without breaking shared identity, audit, and work records.

The free public first-party bundle set is ATS, community feature requests, error tracking, sales pipeline, and web analytics.
`enterprise-access` lives in the same first-party extensions repo and keeps its privileged identity policy through manifest and runtime rules.
The source, release workflow, and machine-readable catalog all live in `MoveBigRocks/extensions`.

Install the free public bundle set

The free public first-party bundles install directly by OCI ref. If an instance uses a controlled instance-bound bundle flow, operators can still pass `--license-token`, but the public bundle set does not require it.

$ mbr extensions install ghcr.io/movebigrocks/mbr-ext-ats:v0.8.21 --workspace WORKSPACE_ID$ mbr extensions install ghcr.io/movebigrocks/mbr-ext-community-feature-requests:v0.1.0 --workspace WORKSPACE_ID$ mbr extensions install ghcr.io/movebigrocks/mbr-ext-error-tracking:v0.8.20 --workspace WORKSPACE_ID$ mbr extensions install ghcr.io/movebigrocks/mbr-ext-sales-pipeline:v0.1.0 --workspace WORKSPACE_ID$ mbr extensions install ghcr.io/movebigrocks/mbr-ext-web-analytics:v0.8.20 --workspace WORKSPACE_ID$ mbr extensions validate --id EXTENSION_ID$ mbr extensions activate --id EXTENSION_ID

Setup path

The default extension setup path is intentionally simple.

Start with one public core repo, one private instance repo, and zero extra extension repos unless you are building real new extension logic. For a self-built extension, start from the extension SDK and stay bundle-first unless the requirement truly needs service-backed behavior.

Proof bundle

Definition README.md Documents the first-party extensions repo, install refs, and release tag model.
Catalog catalog/public-bundles.json Machine-readable catalog for the free public first-party bundle set.
Release .github/workflows/public-bundles.yml Publishes the free public first-party bundle set to GHCR from the first-party extensions repo.
Definition extension-sdk/README.md Explains the bundle-first default and when to move into service-backed endpoints, jobs, consumers, and owned-schema migrations.
Definition extension-sdk/START_HERE.md Gives the local lint, verify, and sandbox lifecycle for a custom extension.
Definition docs/EXTENSION_ENDPOINT_MODEL.md Uses ATS, community feature requests, sales pipeline, web analytics, and error tracking as concrete endpoint and runtime examples.

Stay `workspace` scoped, `standard` risk, and `bundle` runtime unless the requirement clearly needs more.
Move to `service_backed` only when you need custom server-side handlers, event consumers, scheduled jobs, or an owned Postgres schema and migrations.
Keep branding, copy, desired state, and deployment policy in the instance repo; keep real extension logic in its own extension repo.

Bundle-first local loop from the extension SDK

This is the recommended default path for a private custom extension repo.

$ mbr extensions lint . --json$ mbr auth login --url https://app.yourdomain.com$ mbr workspaces list$ mbr extensions verify . --workspace ws_preview --json$ mbr extensions skills list --id EXTENSION_ID

Repo and publication model

The repo and publication model should stay explicit.

The easiest way to keep extension discovery and trust legible is to keep official first-party extensions out of core, publish them from one first-party extensions repo, and split them into separate repos only when they truly need different ownership or release cadence.

Public core repo

Owns runtime contracts, docs, and CLI behavior for extension installation and operation.

First-party extensions repo

Owns the first-party extension sources, release workflow, and `catalog/public-bundles.json` for ATS, community feature requests, error tracking, sales pipeline, web analytics, and enterprise access.

Public OCI bundle refs

Own the actual install surface for the free public first-party bundle set.

Lifecycle and constraints

Bounded extensions move through a sequence a human or agent can reason about.

A good extension lifecycle makes production safety and evaluation clarity much better, especially when agents are involved.

Define the slice and the existing core primitives it should reuse.
Package the extension with explicit runtime surfaces and ownership.
Complete the threat model and review checklist before activation outside a preview workspace.
Deploy and validate in a preview workspace before touching production.
Promote deliberately into the self-hosted production environment after review.

Build extensions

Public overview of the extension authoring and promotion path.

/build-extensions

Extensions docs

Reference guide for the extension model and its shared boundaries.

/docs/extensions

References

Canonical next surfaces.

Each link goes to the next authoritative page, reference, or support surface.

Let agents inspect the CLI-first surface. Let humans decide trust, rollout, and boundaries.

Start from /agents, use /docs/cli as the official product tour, inspect /resources for source and proof, and review /security before making deployment or data-handling decisions.

Open /agents Open resources

Each extension replaces a standalone SaaS product. Install it or build your own with AI.

Section map.

The first public bundle set should feel like a real add-on catalog, not a hidden implementation detail.

ATS

Community feature requests

Web analytics

Error tracking

Sales pipeline

Enterprise access

Move Big Rocks is worth extending because the hard shared boundaries are already in place.

Shared identity and permissions

Shared work records

Shared knowledge and concepts

Shared operating surfaces

Shared audit and rollout model

An extension is a bounded capability slice on the shared product base.

Focused capability

Bounded state

Shared primitives

Explicit lifecycle

Bounded means powerful, but not sovereign.

No new app silo

Shared identity and permissions

Shared audit

Shared evaluation flow

The extension architecture is explicit about runtime class, storage, routes, and events.

Bundle versus service-backed

Owned PostgreSQL schema

Core-owned routing

Typed events and outbox

Shared runtime registry

Extensions fit when the workflow needs more than the shared core but still belongs on the same base.

ATS

Community feature requests

Web analytics

Error tracking

Sales pipeline

Private workflow extensions

Install the free public bundle set

The default extension setup path is intentionally simple.

Bundle-first local loop from the extension SDK

The repo and publication model should stay explicit.

Public core repo

First-party extensions repo

Public OCI bundle refs

Bounded extensions move through a sequence a human or agent can reason about.

Build extensions

Extensions docs

Canonical next surfaces.

Core

Extension developers

Use cases

Security

Resources

Let agents inspect the CLI-first surface. Let humans decide trust, rollout, and boundaries.