Roadmap

The order is the promise. The calendar is not.

Kalup 0.1.0 is on npm: pull, plan and apply for properties and property groups, held drift, takeover and blueprints. Its workflow passed live runs on a HubSpot developer test account. Pipelines, custom object schema writes and association labels come next, then a hosted service for agencies. No dates.

0.2
Released in 0.2, on npm.
Recipe
Documented in the guides. Not yet run in a real CI.
Next
Next on the roadmap, in order. Not built yet.
Later
Planned after the next work. Not built yet.
Not planned
Out of scope, not postponed.
release:sequence

What gets built, in order.

What shipped, then the next three, each with live evidence and recovery tests before its writes ship. All of it runs on your machine or in your CI against HubSpot's public APIs, except the hosted service at the end.

  1. 0.1 and 0.2

    The local CLI

    0.2

    Keep properties and property groups in TypeScript files, review every change as a plan, and apply it to any portal you name. Edits made in the HubSpot UI are held, not reverted.

    • The packages kalup (the CLI) and @kalup/core, on npm.
    • init, offline, then pull, validate, ir, fmt and status. The tool parses config and never executes it.
    • The object files in a folder you choose, hubspot/ by default, and monorepos.
    • Reads and writes of properties and property groups, on standard and custom objects, with every writable definition field. Custom object schemas are read and compared.
    • plan with the values it writes, held drift with both ways out, and apply that plans and asks in one step: a person at a terminal, --yes, or --approve on a saved plan from a reviewed CI job.
    • State per portal, on your machine or committed with state: 'repo', pull recording what the files and the portal agree on, and recovery by a new plan.
    • Takeover mode, exclude, adopt and yesLimit. A delete needs a tombstone, allowDestroy and a person at a terminal.
    • compare, snapshot and docs, with coverage recorded for every read.
    • Blueprints with add and blueprint upgrade, and per-target definition overrides.
    • Codecs and InferProperties with zero runtime dependencies, literal property names, clear, and lenient enums with Unlisted and .strict().
    • --json on every command as one envelope/1, with stable issue codes and exit codes.
    • A CI recipe: one writer per portal, state on a branch, --approve with a reviewed digest. Documented, not yet run in a real CI. Recipe
  2. Next

    Pipelines and stages

    Next

    Deal and ticket pipelines and their stages in the same files, planned and applied the same way.

    • Reads, plans and writes of pipelines and stages, each with live evidence and recovery tests.
    • A plan that names what the API cannot copy, such as required properties per stage and stage automation.
  3. Next

    Custom object schema writes

    Next

    Create and change custom object schemas from config, where today they are read and compared.

    • Creates and updates of custom object schemas: labels, display properties and property lists.
  4. Next

    Association labels

    Next

    Association labels between objects in config, bound per portal to the IDs HubSpot assigns.

    • Reads and writes of association labels, with the IDs HubSpot assigns held in state.
  5. Later

    Cloud for agencies

    Later

    A hosted service for agencies running the same open engine: shared state, scheduled snapshots, approvals and history across client portals.

    • Workspace and portal permissions, and OAuth connections.
    • Shared state and coordination, running the same open engine.
    • Scheduled observations with coverage, approvals bound to saved plans, history, and export for handover.
release:later

Later, in no fixed order.

None of these has a place in the order yet. Each builds on the same two JSON contracts, the IR and the plan, so none of them changes how what ships above works.

  • The typed record client

    Later

    @kalup/client: typed record reads and writes, batches, search and associations over the same codecs. The types and codecs in @kalup/core work without it.

  • Lists, forms, workflows

    Later

    In that order, each with reads before writes. Workflows sit behind a per-resource flag because the API is beta.

  • Runbooks and attest

    Later

    Steps in the words of the HubSpot UI for settings with no API, and attest to record that a person did them.

  • generate <language>

    Later

    Native types and codecs from the IR, with no Node at run time. Research points at Python, then PHP.

  • Keychain credentials

    Later

    Keys read from the operating system keychain instead of environment variables.

  • Blueprint sources and a registry

    Later

    More ways to fetch a blueprint, and a registry, once reuse needs distribution.

  • MCP server and Claude Code plugin

    Later

    Read-mostly, with apply off by default and never for protected targets.

  • Hosted service

    Later

    Beyond the agency cloud, a hosted service for any team. It gets its own pages.

scope:out

Not planned.

Saying what Kalup will not do is part of the roadmap. These are out, not postponed.

  • Record data migration

    Copying values between properties, bulk record edits, seed data. The rename recipe names the steps and stops there.

  • Rebuilding the HubSpot CLI

    Projects, apps, CMS themes, serverless functions, test account creation. Use hs for the app and Kalup for the portal.

  • Claims beyond a runbook

    For assets with no public write API, the most Kalup will do is print the manual steps and record that a person did them.

  • rollback, resume and promote

    Recovery is running plan again.

  • Promises about undocumented behaviour

    An unverified HubSpot behaviour stays labelled until a live test settles it.