Prelaunch support

Support for members, pilot teams, and early adopters.

During prelaunch, support is structured, founder-led, and asynchronous. The goal is fast routing, clear expectations, and useful answers without pretending there is already a full support org behind the product.

Open support form Explore launch status

Key Facts

Model: Founder-led async support
Response window: Usually 1-2 business days
Best channel: Structured email with context
Priority: Pilot teams, members, launch blockers

Choose the right support path

Route the question to the narrowest path first. That keeps turnaround faster and makes it easier to give a concrete answer instead of a generic reply.

Account

Account access and billing

Use this for sign-in issues, account state questions, waitlist confusion, or early billing questions. Include the email tied to the account.

Open account support form

Technical

Technical issue or bug report

Use this when a page breaks, a flow blocks, or something behaves differently than expected. Include the URL, screenshot, and expected versus actual behavior.

Open bug report form

Self-serve

Product question

Use self-serve pages first when the question is about doctrine, examples, pricing, or launch sequencing rather than a broken workflow.

Open pricing

High-touch

Pilot or team support

Use this for live or near-launch teams that need a tighter review loop, launch-risk guidance, or a higher-touch support path.

Open pilot path

Before you contact us

The best support requests are short, specific, and reproducible. Most slow support comes from missing context, not from the issue itself.

Use the email tied to your account or waitlist entry

Include the exact page URL where the issue happened

Attach a screenshot or short screen recording when relevant

State what you expected to happen and what actually happened

For launch blockers, explain why the issue is high-stakes or time-sensitive

Self-serve resources first

A large share of support demand is really navigation demand. If the question is about what the platform does, what ships when, or how to use the public material, these pages should resolve it faster than waiting for a reply.

Doctrine

Principles

Start here when the question is about the doctrine, design standards, or how the platform frames trustworthy agentic behavior.

Open principles

Implementation

Examples

Use the example library when you need concrete implementation patterns, source references, or runnable flows instead of abstract guidance.

Open examples

Agents

For agents

Open this when the question is about MCP access, agent-ready assets, public tooling, or how agents consume the blueprint.

Open For agents

Commercial

Pricing and launch path

Use this for plan sequencing, what is public now, what becomes practitioner software at launch, and what remains later governance.

Open pricing

Support scope during prelaunch

Prelaunch support should set expectations honestly. The support layer is there to unblock serious usage, not to imitate a mature 24/7 operations team before one exists.

No live chat or always-on coverage yet

Best-effort troubleshooting for public and early member surfaces

Higher priority for active pilot teams, members, and production-adjacent blockers

Product questions are often routed back to public self-serve material when the answer is already documented

Launch timing, feature sequencing, and plan availability may still change

Contact

Direct contact

If the issue is account-related, launch-critical, or clearly not answered by the public material, use the support form first. It creates a cleaner intake path and keeps routing more reliable than exposing raw email as the primary path.

Reply window: usually 1-2 business days, faster for urgent pilot or launch-blocking issues.

Open support form

Support email

support@aidesignblueprint.com

Reply window: usually 1-2 business days, faster for urgent pilot or launch-blocking issues.

For team or launch-critical requests, use the form with the correct topic as the primary path.

FAQ

Do you offer live chat or phone support?

Not at this stage. Support is handled asynchronously so requests can be routed with the right context instead of handled as shallow interruptions.

What should I include in a technical support request?

Include the account email, the page URL, a screenshot, expected versus actual behavior, and the shortest reproduction steps you can provide.

Where should I go for launch-critical or team-level help?

Use the pilot or team support path when the issue affects a live or near-launch workflow and needs tighter review, escalation, or launch-risk guidance.

Should I contact support for general product questions?

Usually no. Start with the principles, examples, For agents, launch, and pricing pages first. Contact support when the answer is not documented or your case is account-specific.

If this is not really a support issue

Use the right path before opening a shallow support thread.

Launch

Use this to understand what is already live, what stays prelaunch, and how the next step is sequenced.

Examples

Use this for concrete patterns, source references, and runnable flows when the question is not actually support.

For agents

Use this for public MCP access, agent-ready assets, and guidance on how agents consume the blueprint.