Terms

Customers are responsible for who they invite, what work they put into buildr-plannr, and how they supervise humans and agents in each workspace.

• Use accurate signup, billing, workspace, and support information.
• Keep passwords, MFA factors, API keys, browser sessions, and identity provider access secure.
• Invite only authorized users and agents, remove access promptly, and keep workspace roles aligned to real responsibilities.
• Do not upload secrets, passwords, payment card data, health data, government identifiers, or other regulated data unless a signed enterprise agreement explicitly covers it.

buildr-plannr is for planning, supervising, and verifying software delivery work. It must not be used to harm systems, people, or customer data.

• Do not use the service for malware, credential theft, abusive automation, unauthorized access, spam, scraping, harassment, or illegal activity.
• Do not attempt to bypass rate limits, plan limits, authentication, billing controls, audit logging, or agent approval gates.
• Do not misrepresent generated output, verification evidence, security posture, or customer approvals.
• Do not submit private third-party source material, issue data, or credentials unless you have the rights and authority to process them.

The product is an agent-first planning and governance workspace, not a substitute for human ownership of delegated work.

• Agent-generated actions, recommendations, task contracts, issue updates, evidence, and code-adjacent instructions require human review before they are treated as accepted outcomes.
• Customers remain responsible for scopes, non-goals, context packs, approval rules, tool access, environment credentials, and production release decisions.
• High-impact actions such as code, infrastructure, billing, data exports, account access, or customer communications should use approval gates and evidence requirements.
• buildr-plannr may block, limit, or flag agent work when readiness checks, risk scores, quota controls, or policy rules indicate unsafe execution.

Self-serve plans are billed through Stripe after workspace creation, and plan limits define the capacity and governance features available to each workspace.

• Free workspaces do not require Stripe checkout; Beginner, Hobbyist, and Pro self-serve subscriptions use Stripe checkout, portal, invoices, and webhook events.
• Plan limits cover workspaces, projects, issues, seats, agent runs, context packs, imports, exports, integrations, storage, retention, API access, and audit logs.
• If a workspace exceeds plan limits, existing data stays readable where possible while unsafe new usage can be blocked until the workspace reduces usage or upgrades.
• Billing support handles checkout, invoices, refunds, downgrades, cancellations, and portal recovery through the documented support path.

Enterprise customers can use a sales-assisted path for custom limits, procurement terms, SSO planning, security review, support commitments, and legal documents.

• Custom enterprise terms must be captured in a signed order form, DPA, security addendum, or mutually approved written agreement.
• Enterprise commitments may override self-serve defaults for limits, retention, support targets, subprocessors notice, procurement, and billing process.
• Security questionnaires, SSO review, subprocessors, privacy, DPA, and audit evidence requests route through the enterprise review contact path.
• No public marketing or in-app copy should claim SOC 2 certification, custom legal terms, or custom support commitments before they are contractually approved.

Access can be suspended or terminated to protect customers, the platform, billing integrity, or legal obligations.

• buildr-plannr may suspend access for security risk, abusive use, payment failure, plan-limit abuse, illegal activity, or attempts to bypass controls.
• Customers may cancel self-serve subscriptions through the billing portal or support path, subject to the active plan, refund, and retention terms.
• After termination, exports and deletion follow the documented retention, backup, billing, legal hold, and enterprise contract process.
• Some records may be retained for tax, accounting, security, fraud prevention, dispute, incident, or compliance obligations.

Questions about terms, billing, privacy, DPA, enterprise contracts, support, or account ownership should use a documented support or contact route.

• Use /support?intent=legal for legal, DPA, privacy, subprocessors, data rights, account ownership, or terms questions.
• Use /support?intent=billing for billing, checkout, refunds, cancellation, invoices, portal recovery, or downgrade questions.
• Use /contact?intent=security-review for enterprise procurement, security review, or custom contracting.
• Terms may be updated before public launch or when product, billing, legal, security, or subprocessor behavior materially changes.