use-case:agencies

Every client portal, documented and repeatable.

Setting up a client portal is a checklist and a person clicking through it, rebuilt for every client. Kalup turns each portal into files you can read, document and compare. Keep one repo per client.

Install KalupHow it works
the cast, and the sheet it came from
same mould, every clientKALUPFIG. 3 · THE FLEETSCALE 1:1 · SHEET 3 OF 4
flow:daily

From an existing portal to a documented one.

Start from what the client already has. Nothing here writes to a portal.

  1. 01

    Pull the client portal into files

    $ kalup pull
    Brings the objects, groups and properties of an existing portal into config. Nothing to write by hand.
  2. 02

    Write the data dictionary

    $ kalup docs
    A Markdown data dictionary generated from the files, so the documentation is never older than the portal.
  3. 03

    See what has not been promoted

    $ kalup compare sandbox production
    Shows what a colleague built in the sandbox and has not moved to production yet, edits included.
  4. 04

    Know what changed since last time

    $ kalup snapshot --target production
    Saves a full pull of the portal as a file. Compare against it later to see what changed in the portal since.
  5. 05

    Reuse a setup across clients

    Later
    Blueprints: a versioned setup you add to each client repo. An upgrade merges into each repo and touches no portal until someone plans and applies.
compare:sandbox/production

What your colleague built, and never moved.

Compare takes two sides, each a target, a snapshot file or your config, and lists the differences in the same shape as a plan.

acme-crm · zsh
$ kalup compare sandbox production
Reading sandbox (1111111) and production (2222222) ... done

2 differences

  + property:companies/renewal_date
    only in sandbox
  ~ property:companies/billing_status
    options[PAST DUE] only in sandbox

Nothing was written.
$
docs/data-dictionary.md
<!-- docs/data-dictionary.md, example output -->
## Companies

| Label          | Internal name  | Type        | Group   |
| -------------- | -------------- | ----------- | ------- |
| Billing status | billing_status | enumeration | Billing |
| Renewal date   | renewal_date   | date        | Billing |
One repo per client
acme-crm/             one repo per client
  kalup.config.ts     targets: sandbox 1111111, production 2222222
  kalup/objects/      companies.ts, deals.ts, subscription.ts
  .kalup/snapshots/   production/2026-09-01T09:00:00Z.json
scope:out

What Kalup does not do for you.

Knowing where it stops is part of trusting what it does.

  • It does not move records.

    Setting up a portal moves configuration only. Contacts, companies and deals stay where they are.

  • It is not a backup for record data.

    Snapshots capture configuration. A property created again from a snapshot comes back empty, without its values.

  • It does not click through the UI for you.

    Record page layouts, saved views and permission sets have no public API. The plan prints the steps and a person follows them.

use-cases

The other two ways in.

{{{}}}renewalDate: string | nullKALUPFIG. 4 · THE CASTSCALE 1:1 · SHEET 4 OF 4

Developers

Ship the property before the code that needs it.

/use-cases/developers →
>_>_>_agent editsyou approveKALUPFIG. 2 · THE PROMPTSCALE 1:1 · SHEET 2 OF 4

Agents

Ask for the change. Read the plan. Say yes.

/use-cases/agents →
kalup:init

Start with one portal.

kalup init pins a target, writes the files and runs the first pull. Nothing is written to the portal.

Install KalupRead the docs