ADR-002: MVP Launch Decisions

Context

The platform works locally (quote → deploy → verify → destroy, demo mode). We are preparing a live public MVP: hosted API, agent discoverability, self-serve onboarding, and real payments. The product owner resolved the open questions from docs/product/MVP_LAUNCH_PLAN.md as follows.

Decisions

1. Metered microtransaction billing (not one-time $50 fee)

Decision: Revenue comes from per-interaction microtransactions — agents pay tiny amounts (fractions of a cent to a few dollars) for each metered interaction with the platform, drawn from a prepaid credit balance. Modeled on popular AI agent platforms (pay-per-call, credits ledger).

Supersedes: the "$50 one-time platform fee + first-month AWS estimate" model in the PRD, BUSINESS_PLAN, and current CoreEngine quote pricing.

Rationale:

• Frictionless for autonomous agents — no large purchase decision, no human approval step per deployment.
• Scales with usage: 1,000s of agents × pennies per interaction.
• Matches the existing BillingService (prepaid credits) we already built.

Spec: docs/specs/metered-billing.spec.md

2. Dual payment rails: Stripe + XRP

Decision: Support both top-up rails:

• Stripe (card/checkout) — for humans funding an agent's account.
• XRP (wallet deposit monitor) — for crypto-native agents paying programmatically. We already built the wallet/monitor service (testnet).

Both rails credit the same ledger. Maximum flexibility removes payment friction for agents.

3. Platform never absorbs cloud provider fees

Decision: Cloud infrastructure costs are billed by the cloud provider directly to the customer's own account (via their API keys, per ADR-001). We charge platform interaction fees only. Quotes continue to display estimated provider monthly costs for transparency, but we never collect them.

4. Failed deployments are free

Decision: The deployment fee is captured only after verification passes. Failed deployments release the hold / auto-refund in full. Trust is table stakes for agent adoption.

5. Customer-set maximum cost cap

Decision: Customers (agents) may pass a maximum cost (e.g. maxMonthlyCostUsd) at suggestion/quote/deploy time. Options above the cap are filtered; deploys whose estimate exceeds the cap are rejected with an agent-readable error. This is the customer-controlled spend guardrail, complementing platform-side caps.

6. Deployments follow curated best-practice architectures

Decision: Real deployments are generated only from curated suggestion patterns (best-practice architectures per use case). We do not accept arbitrary Terraform from customers at MVP. Platform-side spend caps and rate limits also apply.

7. Hosting: dogfood AWS now, migrate later; domain in launch workflow

Decision:

• Host the platform on our own AWS account initially (we generate the Terraform — dogfooding), with a planned migration to a cheaper host later.
• The platform ships as a host-portable container with no AWS-coupled internals, so migration is a DNS flip.
• Domain acquisition is part of the launch workflow (we do not own one yet) — see docs/runbooks/domain-and-hosting.md.

8. MCP exposure: public remote endpoint, no code distribution (PROPOSED)

Question from owner: Should the MCP server be public (marketplace listing) or private IP behind the API? Does keeping it private hurt discoverability?

Analysis:

• The MCP server is a thin adapter over the Execution API (refactored 2026-07-18). The defensible IP — outcome classification, tier patterns, pricing engine, Terraform generation, verification — lives server-side behind the API. Publishing the tool interface exposes almost nothing.
• Remote MCP (Streamable HTTP) means we distribute no code at all — marketplace listings point at our hosted URL.
• Keeping the MCP private does hurt discoverability: agent developers browse MCP registries/marketplaces to find tools. No listing = invisible to the primary discovery channel for our exact target user.
• Auth-gating does not hurt discoverability. "Public endpoint, token required" is fully discoverable: agents read llms.txt / agent card / OpenAPI, self-serve a token (Decision: open signup), and connect.

Recommendation: Public remote MCP endpoint (auth-gated), listed in public registries/marketplaces; keep the implementation repository private. The moat is execution quality, pricing data, and verification — not the tool schema.

Status: Proposed — pending owner confirmation.

Consequences

• CoreEngine quote pricing changes from flat $50 + AWS estimate to metered interaction fees; the deploy gate becomes a credit hold/capture.
• BillingService becomes load-bearing and must be persisted.
• Every metered endpoint needs a price, an idempotent debit, and a 402 response path with agent-readable top-up instructions.
• Refund-on-failure must be wired into deployment completion handling.
• Registry listing work (Phase 10) unblocked if item 8 is confirmed.