Architecture Overview

The core principle

Business logic lives once. Every interface — admin UI, REST endpoint, MCP tool, CLI command, webhook — is a thin adapter over a single service layer. A rule is written once and behaves identically everywhere.

This is what separates ShipMore from a styled template: when an agent adds a Pricing block, it pulls live Stripe data and fires a real checkout — a live transactional feature, not a div that still needs backend work. When the ecosystem moves — new agent protocol, new tool, new platform — ShipMore extends an interface; logic isn’t re-implemented per surface.

The four pillars

ShipMore is a self-hosted operating system for data products. Operators import a dataset; the platform handles four pillars without per-archetype customization:

Three-level access model

Agents create content as drafts by default; humans review and publish via the Payload admin. Every agent action is auditable and reversible through Payload’s version history.

The agent boundary

ShipMore has no LLM. No model SDK, no API key, no inference calls inside the platform — so there’s no per-token cost baked into your deployment. The intelligence layer is your own harness — Claude Code, Claude Desktop, any MCP client — driven by the SKILL.md shipped with the box. ShipMore provides deterministic primitives; the agent provides judgment. See Agents & CLI.

Operational constraints

The single-box, multi-tenant model runs everything on one Node process. Search indexes and imports are memory-resident — size the box to your dataset. Import file size is capped by IMPORT_MAX_FILE_SIZE_MB (default 100 MB).

Recommended box sizes: