Free, Blueprint, and Strategy Pack
These are decision and planning products. They return scoring, strategy, documents, acceptance tests, and handoff guidance. They do not promise a live customer runtime.
Home / Pricing / Delivery boundaries
Accountability before purchase
What ships today, what needs credentials, and what does not ship by default.
This page is the plain-English contract between the website promise and the backend. Your Deputy can generate documents, build runtime records, create launch pages, prepare workflows, produce files, and issue receipts. External vendor operation depends on customer-owned credentials and the purchased tier.
Package truth table
Buy the package that matches the output you expect.
Foundation and Professional
Foundation and Professional share the same 11-slot server integration allowlist as Professional in api/provision.js. They can create runtime records, pages, lead capture, workflows, files, seed data, and receipts when required keys and vendor health allow.
Enterprise and Custom Volume
Enterprise extends the allowlist to 13 slots. Custom Volume can unlock a 19-slot allowlist for broader modules such as voice, SMS, CRM, directory, lead intel, and expanded media automation.
The credential boundary
Automatic does not mean pretending vendor accounts exist.
Customer-owned credentials are required for sustained operation. Launcher-held keys help generate deliverables and orchestrate setup. The delivered app is intended to run on the customer's vendor accounts, domains, Vercel project, Stripe account, CRM, email platform, analytics account, and other connected services.
If a credential is missing, the receipt must say what is blocked and what the customer must provide. It should not mark that vendor step complete.
The backend can create
- Tenant and launch records
- Public runtime pages and lead capture
- Workflow templates and event hooks
- Generated app code and deployment scaffolding
- Seed data, files, checks, manifests, and receipts
The customer must authorize
- Production API keys and vendor permissions
- Real domains, DNS, inboxes, and payment accounts
- Legal, tax, financial, compliance, and brand approvals
- Any regulated claims before publication
- Ongoing service subscriptions outside Your Deputy
Delivery proof
Every completed build should leave evidence.
Customer enters
Business details, buyer, pain, paid access token, and the credentials needed for the selected package.
Backend creates
Launch record, modules, runtime page, lead capture path, workflow templates, seed data, generated files, and package receipt.
Receipt shows
What shipped, what passed, what failed, which vendor actions are blocked, and the URL or file path the customer can use.
Quality gate checks
Route availability, placeholder leakage, required artifacts, tier boundaries, credential handling, and promise-to-output alignment before reporting ready.
Status legend
How to read the catalog and deliverables pages.
| Status | Meaning | Customer expectation |
|---|---|---|
| Live | Implemented in the product path and validated by smoke checks. | Can be provisioned when tier, key, and vendor conditions are satisfied. |
| Codegen | Generated as files, docs, tests, schemas, scaffolds, or app code. | Usable immediately as a handoff artifact; external deployment may still need credentials. |
| Partial | Works in a bounded path but has known provider, approval, or health dependencies. | The receipt must explain exactly which parts completed and which did not. |
| Planned | Specified but not included in the default package unless the tier allowlist includes it. | Requires Custom Volume or explicit activation before it is sold as delivered. |
Launch standard
A build is not ready until the evidence matches the promise.
Business completeness
Generated repos are checked for offer, pricing, checkout, onboarding, support, analytics, revenue operations, and operating documents before the build can claim readiness.
Technical completeness
Required schemas, workflows, MCP metadata, observability scaffolds, deployment protection, resumable checkpoints, and generated tests must be present.
Risk boundaries
OWASP, NIST AI RMF, ISO 42001 readiness, and policy artifacts are generated as readiness evidence. They are not a substitute for legal, compliance, or penetration-test approval.
Managed runtime
Ongoing managed operations are separate from the launch build.
Managed Automation Runtime is a future monthly operations layer for monitoring, retries, optimization, and vendor health. Today, launch packages create and hand off the build evidence; sustained operation depends on the customer's connected accounts.