Skip to content
JetStack AI Documentation

Projects Quickstart

This guide walks you through your first project — from creating the workspace to a Release that has been applied to the portal and verified. Unlike the classic import/deploy flow, a project is durable: you will keep coming back to the same workspace for the life of the client engagement.

Before You Start

Section titled “Before You Start”

You need:

  • An organisation with Projects access enabled
  • At least one connected HubSpot portal for the client — see Connecting a Portal
  • The JetStack AI Chrome extension installed and signed in — the portal scan has a browser lane that only the extension can run, and several asset types deploy through it
  • (Optional but recommended) Discovery material — call transcripts, process docs, a revenue model. The brief and the Blueprint are dramatically sharper with real sources.

Step 1 — Create the Project

Section titled “Step 1 — Create the Project”
  1. Open the dashboard and click Projects in the left sidebar. The portfolio shows every project in your organisation, filterable by All / Active / Completed / Archived.
  2. Click New Project.
  3. Name the project (e.g., “Acme Corp — RevOps Build”) and pick the client’s portal. If the client has both a sandbox and a production portal, you can bind both — each becomes a mode you switch between later.
  4. Click Create. There is no review step — the workspace opens immediately.

Creation kicks off portal setup: a scan of the connected portal that populates the Canvas. You do not have to wait for it — chat is available right away.

Step 2 — Let the Two-Lane Scan Run

Section titled “Step 2 — Let the Two-Lane Scan Run”

The scan reads the portal on two lanes:

  • API lane — everything HubSpot’s public API exposes: properties, pipelines, workflows, lists, forms, and more. Runs server-side with no action from you.
  • Browser lane — asset domains the public API cannot see (dashboards, reports, snippets, playbooks, and other in-portal-only types). This lane runs through the Chrome extension: open the extension on the client’s portal and follow the Finish scan in HubSpot prompt in its inbox.

The Canvas fills in as each lane completes, and every asset domain shows when it was last scanned, per lane. A domain that has not been scanned yet says so explicitly — the Canvas never shows a zero that just means “we haven’t looked.”

You can rescan at any time from the Canvas; a rescan re-runs both lanes, and the browser lane will again prompt you through the extension if it needs a session.

Step 3 — Build the Brief

Section titled “Step 3 — Build the Brief”

While (and after) the scan runs, tell the workspace about the client:

  • Talk to Jetty. Describe the business model, the current process, the outcomes the client cares about. Jetty asks follow-ups where it matters, and can inspect the scanned portal to ground the conversation in what actually exists.
  • Upload documents. Use the paperclip in chat to upload new files (PDF, DOCX, TXT, CSV, JSON, Markdown) or to reference a document already in the project’s Documents library. Uploaded documents are analyzed and their content becomes citable source material.

Everything the workspace learns is compiled into Project Knowledge — a versioned brief where every claim carries a citation back to its source. When sources disagree or something needs a human call, the claim lands in a review queue instead of being silently guessed.

Step 4 — Review the Solution Blueprint

Section titled “Step 4 — Review the Solution Blueprint”

Once there is enough knowledge to design from, the workspace derives a Solution Blueprint: the solution-design document covering object families, properties, lifecycles, automations, and the outcomes each serves.

The Blueprint is versioned and always visible — there is no approval gate. When the brief changes, the Blueprint shows Update available and you can bring it current. Review it, refine it through chat, and move on when it reflects the engagement.

Step 5 — Deliver a Release

Section titled “Step 5 — Deliver a Release”

All portal changes happen through Releases. For your first one:

  1. Open the Releases tab and create a Release. Give it a real outcome — “Stand up the sales pipeline and lead routing,” not “misc changes.”
  2. Confirm the outcome and acceptance criteria. This is the contract the Release will be verified against.
  3. Jetty plans the Release: the concrete changes — new assets, updates to existing ones — appear in the Changes tab, each traceable to a requirement. Requirements that cannot be executed automatically are kept visible with an explicit disposition rather than silently dropped.
  4. Generate. Jetty produces a reviewable spec for every asset in the plan. Open any asset to see its spec rendered in the format that fits its type — a pipeline as stages, a workflow as enrollment + actions, a report as its chart config.
  5. Authorize. Nothing has touched the portal yet. Review the plan in Delivery, check which mode (sandbox or production) you are applying to, and authorize the apply.
  6. Apply & verify. Assets deploy in dependency order — most via the API, session-bound types via the Chrome extension. Every asset row records its verbatim HubSpot outcome, and verification then reads the portal back to confirm each asset really is what the spec says.

If an asset fails or verifies wrong, you don’t restart anything — use Repair on that asset. See Deployment & Verification.

Step 6 — Keep Going

Section titled “Step 6 — Keep Going”

The project stays alive after the first Release:

  • The Canvas keeps its live picture of the portal — rescan whenever the client’s team has been busy.
  • Deploy logs hold the full history of every operation the project has run.
  • New scope becomes a new Release. Small fixes are repairs on existing assets.
  • Teammates can be added as project members (owner / editor / viewer), and each Release has an accountable owner.

Sandbox First, Production Second

Section titled “Sandbox First, Production Second”

If both portals are bound, the usual rhythm is: deliver a Release to sandbox mode, review it with the client, then run the same delivery against production mode. The mode switch changes which portal you are looking at and applying to — production mode is styled unmistakably and confirms harder, on purpose.

Next Steps

Section titled “Next Steps”