First replacement targets

Start by replacing the SaaS tools that cost the most and expose the most.

Every SaaS tool you replace is money saved and attack surface removed. Move Big Rocks is strongest when it replaces fragmented tool stacks where the cost is high, the security exposure is real, and too much context is spread across disconnected systems. Good first deployments have visible ownership, repeated intake, meaningful follow-through, and a champion who is tired of paying five vendors for what should be one system.

Evaluate fit as an agent Read self-host path

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

Choose one replacement surface

Do not begin with a full-company migration. Begin with one fragmented surface.

Prefer repeated work

Choose a workflow with recurring intake, routing, approvals, or follow-up.

Keep the deployment small

The first deployment should prove the model with minimal production risk.

Let agents help evaluate

Agents are useful when the workflow suffers from fragmented context and weak durable state.

Used by the builder

The founder runs Move Big Rocks for the DemandOps portfolio across multiple products, brands, and countries. The first replacement targets were error tracking, web analytics, and customer support intake because they removed repeated SaaS accounts and licenses per brand while giving agents one shared operating surface.

Table of contents

Section map.

Jump directly to the part you need.

The right first target is small, visible, and operationally annoying today. How to choose a first deployment These workflows tend to benefit quickly from one shared system. Concrete first targets The first useful deployment should feel boring in the best way. Adoption path Agents are most useful when the workflow already has shared records and clear approvals. How agents help

How to choose a first deployment

The right first target is small, visible, and operationally annoying today.

A good first deployment is a workflow people already feel is messy. That creates fast proof without requiring the platform to replace everything at once.

Pick a workflow with obvious pain, repeated intake, and a clear owner.
Prefer a workflow already split across forms, docs, inboxes, spreadsheets, or lightweight tools.
Prefer something that maps to existing forms, queues, conversations, cases, and knowledge without a new ontology.
Prefer something that creates durable value even if no extension is built yet.

Concrete first targets

These workflows tend to benefit quickly from one shared system.

Some of these are strong out of the box, and some get deeper with extensions. Together they show the kinds of tool stacks Move Big Rocks is meant to replace.

Service desk replacement

Out of the box, the core can replace a surprising amount of Zendesk or ServiceNow-style intake, queueing, casework, and follow-up without custom code.

Forms and approvals

Structured forms, routing, and durable follow-through can replace Formstack-style intake plus the handoffs that usually spill into email and spreadsheets, and many approval or requisition flows stop there without needing extension code.

Hidden Markdown and prompt systems

Turn private Markdown, concept specs and instances, prompts, and templates into governed workspace surfaces other people and agents can use safely.

Recruiting operations

Unify role intake, candidate workflows, hiring knowledge, and interview follow-up on one shared base, then add deeper ATS capability through extensions when needed.

Error tracking with extensions

Add Sentry-style ingest, issue grouping, and remediation loops through bounded extensions without making error work a separate island.

Analytics with extensions

Add Plausible or Google Analytics-style ingestion and follow-up through extensions while keeping review and action on the same shared base.

Operational portals

Create internal portals and bounded request surfaces without standing up a separate app stack.

Agent-assisted queue work

Use agents to summarize, classify, or draft next steps while humans keep the approvals that matter.

Adoption path

The first useful deployment should feel boring in the best way.

Adoption usually works best when it moves through a steady sequence instead of a big-bang replacement.

Start on a small owned runtime so humans and agents can inspect the model honestly.
Choose one workflow and map it onto existing primitives.
Decide what knowledge, concept specs, forms, and queue structure the workflow needs.
Run the first slice with visible human review and measurable outcomes.
Only then decide whether an extension is needed for deeper capability.

How agents help

Agents are most useful when the workflow already has shared records and clear approvals.

Agent leverage goes up when the system has durable shared context and visible shared state. That is why Move Big Rocks is agent-ready without being anti-human.

Evaluation

Agents can inspect the site, docs, CLI, and resources and recommend whether the system fits the team.

Migration planning

Agents can propose a minimal first deployment and map existing tools, Markdown systems, and concept-driven workflows onto the shared primitives.

Operational assistance

Agents can summarize queue work, draft follow-ups, and connect knowledge to active work.

Extension scoping

Agents can help decide whether a missing capability belongs in core usage, a new workflow design, or a bounded extension.

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