ShapeKit
← Back to Blog

The Crafter/Shaper Model: Why We Split the Dashboard Role in Two

Most dashboard products try to serve the developer and the end user with a single interface. ShapeKit splits them deliberately — and that split is why constrained shaping works.

By ShapeKit Team

When you build a SaaS dashboard, you're actually serving two different people with two entirely different relationships to that dashboard.

The first person built it. They know the data model, decided what metrics matter, and made deliberate choices about what to show and what to hide. They want control over the structure.

The second person uses it every day. They don't care about the data model. They care about whether their dashboard fits their workflow — whether the columns they use are visible, whether the defaults make sense for how they work.

These two people have been using the same product in ways that create constant friction. The builder keeps getting tickets from the user. The user keeps waiting for a developer to implement their changes.

We call them the Crafter and the Shaper. Splitting them out explicitly is the design decision that makes ShapeKit work.

The Crafter

The Crafter is the developer. They build the dashboard and own the shape space — the definition of what's fixed and what's flexible.

The Crafter's job in ShapeKit is to write a shapeable skill: a typed configuration that declares the rules.

const revenueSkill = ShapeKit.define({
  name: 'Revenue Dashboard',
  columns: {
    account_name: { fixed: true },
    total_revenue: { fixed: true },
    region: { shapeable: true, default: true },
    channel: { shapeable: true, default: false },
    account_manager: { shapeable: true, default: false },
    contract_value: { shapeable: true, default: false },
  },
  maxVisibleColumns: 8,
  sortable: ['total_revenue', 'region', 'channel'],
  filters: {
    region: { shapeable: true },
    date_range: { fixed: true },
  },
})

This is the complete definition of what Shapers can do. Account name and total revenue are always visible. Region is visible by default but optional. Channel, account manager, and contract value are available but off by default. Nobody can show more than 8 columns. Sorting is allowed on three fields. Region filter can be adjusted; date range is locked.

The Crafter writes this once. They don't touch it again unless the product changes.

The Shaper

The Shaper is the end user. They open the dashboard and see a reshape panel that reflects the Crafter's definition — nothing more, nothing less.

The Shaper can:

  • Show or hide optional columns
  • Reorder visible columns (within the defined bounds)
  • Set their preferred sort
  • Save filter preferences

The Shaper cannot:

  • See columns the Crafter didn't mark as shapeable
  • Add more columns than the Crafter's max
  • Sort on a column that wasn't declared sortable

From the Shaper's perspective, this feels like a fully customizable dashboard. From the Crafter's perspective, it's a fully controlled one. Both are true simultaneously.

Why this split matters

The core insight: the Crafter and the Shaper have different expertise and different responsibilities.

The Crafter understands the data model. They know which columns can be safely exposed, which queries are performant, which fields might contain sensitive data. They should own those decisions.

The Shaper understands their own workflow. They know which columns they actually use, which defaults don't match how they work, which view would save them 30 seconds every morning. They should own those decisions.

When everything goes through the Crafter — when every Shaper preference requires a Crafter implementation — you get the customization backlog. Tickets pile up. Developers get pulled off real work. Users wait.

When the Shaper gets unconstrained control — when they can configure anything — you get configuration chaos. Broken UIs. Expensive queries. Support tickets that require debugging someone else's configuration.

The Crafter/Shaper split puts each decision in the hands of the right person, and uses code to enforce the boundary.

The model in multi-tenant products

Multi-tenant products add a third actor: the tenant admin. In a B2B SaaS product, there's the developer (Crafter), the company admin, and the end user (Shaper).

ShapeKit handles this with a layered preference model:

  1. Crafter defines the shape space (what's possible)
  2. Tenant admin sets company defaults (what Shapers see when they first open the dashboard)
  3. Shaper adjusts within the company defaults (their personal view)

Each layer can only operate within the bounds of the layer above it. Shapers can't override admin-locked settings. Admins can't expose columns the Crafter didn't make shapeable.

The Crafter writes one definition. Every tenant and every user gets a view that fits their context.

ShapeKit launches April 15 — full product, no waitlist. Sign up for early access.