1. Connect & scan
Create the project and bind the client’s portal. A two-lane scan reads the portal — a public-API lane and a browser lane (via the Chrome extension) for asset types the API cannot see — and populates the Canvas.
Projects Overview
Projects is JetStack AI’s workspace for running a client’s HubSpot delivery end to end. You connect the client’s portal, and the workspace builds a live picture of everything in it; you talk to Jetty — the project’s AI agent — and upload documents, and the workspace compiles a source-backed brief; and when it is time to change the portal, the work happens in Releases: bounded, reviewable units of delivery that are planned, generated, authorized, applied, and verified one at a time.
A Workspace, Not a Wizard
Section titled “A Workspace, Not a Wizard”A project is not a one-shot pipeline you run once and finish. It is the durable home for one client engagement:
- The unit of state is the asset, not the project. Every property, workflow, dashboard, and pipeline the project touches has its own status, its own deploy outcome, and its own repair path. There is no project-wide phase machine and no single “deployment step” that succeeds or fails as a block.
- The portal is always visible. The Canvas shows a live inventory of the client’s whole portal — including everything the project has never touched — so you are designing against reality, not against a blank page.
- Work is delivered in Releases. Each Release has a confirmed outcome and acceptance criteria, a reviewed change plan, an explicit authorization step before anything touches the portal, and per-asset verification after it does.
- Nothing happens without you. Jetty can inspect the portal and propose changes, but it cannot authorize a portal mutation. Every change to HubSpot goes through a Release you have reviewed and authorized.
The Workspace at a Glance
Section titled “The Workspace at a Glance”A project’s navigation has six areas:
| Area | What it holds |
|---|---|
| Overview | The project’s home — status, the client brief, recent activity |
| Documents | The document library: everything uploaded or referenced, with its analysis state |
| Canvas | The live portal inventory — every asset domain, with per-lane scan freshness |
| Releases | The delivery units — planned, in-flight, and completed Releases |
| Deploy logs | The full record of every portal operation the project has run |
| Settings | Portal bindings, members, and project configuration |
How Work Flows
Section titled “How Work Flows”2. Build the brief
Chat with Jetty and upload discovery docs, transcripts, and process material. The workspace compiles Project Knowledge: a versioned, source-cited brief where every claim traces to evidence.
3. Review the Blueprint
The Solution Blueprint is a versioned solution-design document derived from the brief — object families, properties, lifecycles, automations, outcomes — with full version history. It is a document you review, not a gate you approve.
4. Deliver in Releases
Each Release confirms an outcome, plans the changes, generates the assets, and waits for your authorization before applying anything to the portal. After apply, every asset is verified against what was actually created in HubSpot.
Sandbox and Production Are a Lens, Not a Phase
Section titled “Sandbox and Production Are a Lens, Not a Phase”A project can bind up to two portals for the same client: their sandbox and their production portal. The mode switch changes which portal the Canvas, asset states, deploy logs, and delivery flows point at — it does not change anything about the project itself.
Production mode is deliberately visually distinct everywhere it appears, and destructive-adjacent actions carry stronger confirmations there. If only one portal is connected, only that mode is offered — the workspace never pretends a portal exists.
What Gets Generated
Section titled “What Gets Generated”A Release can produce assets across the full HubSpot spectrum. Jetty draws on patterns from a large corpus of real HubSpot configurations, so the assets it produces match real-world conventions rather than idealised samples.
| Category | Assets a Release can generate |
|---|---|
| Data model | Custom objects, properties, lifecycle stages, association labels |
| Sales | Deal pipelines, deal stages, sales workflows, lead scoring |
| Marketing | Forms, lists (static and dynamic), marketing emails, email sequences |
| Service | Ticket pipelines, support workflows, playbooks |
| Reporting | Dashboards, reports, CRM cards, preview views, goal templates |
| Productivity | Snippets, task templates |
Every generated asset is a reviewable spec before it deploys, and every deployed asset carries its verbatim HubSpot outcome afterwards.
Where Projects Lives
Section titled “Where Projects Lives”Projects has two surfaces:
- Web dashboard — the primary workspace: Canvas, Knowledge, Blueprint, Releases, deploy logs, and chat all live here.
- Chrome extension — the browser lane. It scans the asset types HubSpot’s public API cannot see, and deploys the ones that require an authenticated HubSpot session (dashboards, reports, snippets, and more).
Both surfaces share the same project state, so progress is live in either UI.
What’s Different from Implementations?
Section titled “What’s Different from Implementations?”| Projects | Implementations | |
|---|---|---|
| Starting point | A client engagement: their portal + your discovery material | An existing source portal |
| Driver | AI agent proposes; you authorize per Release | You select assets to import |
| Shape | Durable workspace, delivered in bounded Releases | Import → library → deploy pipeline |
| Portal reads | Live two-lane portal scan (Canvas) | Source-portal import |
| Best for | Client delivery, new builds, ongoing engagements | Replication, migration, cloning |
Implementations remains the right tool when you want to replicate a working portal’s configuration onto another portal — see Implementations.
Next Steps
Section titled “Next Steps”- Getting Access — Confirm your organisation can use Projects
- Quickstart — Your first project, from portal scan to a verified Release
- Project Knowledge — The source-backed client brief
- Solution Blueprint — The versioned solution-design document
- Releases — How work is planned, generated, and delivered
- Deployment & Verification — The two-path deploy, verification, and repair
- Troubleshooting & Gotchas — Known limits and recovery