How-To Do This

How to build LaunchPilot

Build a campaign cockpit for audiences, governed AI assets, approvals, channel activation, experiments, and optimization.

LaunchPilot is a ai marketing operations pattern. This guide turns the product concept into a buildable first release using BuildWithHQ records, pages, workflows, permissions, integrations, AI, and exact-version packaging.

Define the outcome before the screens

Move a campaign from a structured brief through approved content and audience selection to a measurable channel run, while preserving consent, claims, budget, and approval evidence.

1. Create the smallest useful data model

In the Developer Console, create or select the SaaS app and model these as application record types and relationships. The page editor composes React components and validated data bindings, which call the platform APIs for these records.

Relationship rule: Freeze the audience, approved asset versions, budget, and experiment allocation used by each channel run so results remain explainable.

2. Build the working screens

Start with task-oriented pages instead of a page for every table. The first navigation should contain:

• Campaign portfolio and launch calendar.
• Campaign workspace with brief, audience, assets, and approvals.
• Audience builder and consent summary.
• Asset review with claim/brand evidence.
• Experiment and performance dashboard.

Use Puck for the normal visual experience. Keep stable block identity when using Monaco advanced JSON mode so future template upgrades can merge safely.

3. Set access before adding automation

• Separate content authors, approvers, audience/data operators, and channel activators.
• Restrict customer fields and consent data at record/field scope.
• Require approval for unsupported claims, regulated content, budget changes, and channel activation.

User Type menus establish eligible page routes for each audience. They do not grant the records or actions on those pages. The server derives the account, SaaS app, user, DataRole, and location scope from the verified identity on every data request.

4. Add the core workflows

• Brief approved → audience and asset work created.
• Asset version → policy/brand checks → human approval.
• Audience snapshot + approved assets + budget → scheduled channel run.
• Provider webhook → normalized delivery/performance events.
• Experiment threshold → bounded recommendation, not silent budget movement.

Make each mutation a narrow, reviewed action with explicit inputs, allowed states, correlation evidence, and an idempotent retry policy where retries are possible. Pages, integrations, and agents all reach the same application service and stored-procedure contract through supported APIs.

5. Connect channels and outside systems

• Connect email, advertising, CRM, CMS, analytics, and consent systems.
• Use provider webhooks to reconcile accepted, delivered, failed, and conversion states.
• Keep provider credentials and raw audience exports out of pages and logs.

Use managed connections, OAuth connectors, inbound endpoints, and webhooks. Put specialized SDKs or private processing behind a declared appliance endpoint; never expose provider credentials to a page.

6. Add AI as a governed layer

Ground generation in approved brand and product knowledge. Keep deterministic validation for required disclosures, consent, budgets, channel rules, and release state.

• Generate variants against a versioned brief and audience purpose.
• Attach the source brand/policy evidence used during review.
• Treat activation and budget changes as governed actions.
• Evaluate asset quality separately from campaign outcome.

AI and retrieval must apply CanAiReadRecords, tenant, DataRole, field, and location security before context is assembled. Planning and research remain read-only. Customer-facing or material changes use an action suggestion and the configured policy or human approval before execution.

7. Ship one complete vertical slice

Recommended first release: Create one campaign and consented audience, generate two asset variants, approve one, send it through a sandbox channel, and ingest delivery results.

1. Create the minimum record types and seed representative, non-production data.
2. Build the primary list/queue and one complete detail page.
3. Implement one state-changing workflow and its denial/error states.
4. Add the narrowest useful integration or inbound channel.
5. Add one permission-aware AI read or suggestion only if it improves that workflow.
6. Test as an owner, a normal operator, a restricted user, and an unauthorized user.

8. Validate, package, and operate

• Prove unconsented contacts cannot enter the audience snapshot.
• Prove unapproved asset versions cannot launch.
• Deduplicate provider callbacks and reconcile failures.
• Freeze experiment inputs before comparing outcomes.

Publish a reviewed exact version as a template when the pattern is reusable. If you sell it, complete the marketplace preparation checks. Template installs are version snapshots; upstream edits must never silently mutate a tenant copy.

Built-in data path: React components and data bindings call authenticated APIs; typed application services execute reviewed stored procedures and return bounded results with audit and correlation evidence.