Files
dashcaddy/PRODUCT-SPEC.md
T
Hermes Agent 58f737a173
CI / Test & Lint (push) Has been cancelled
CI / Security audit (push) Has been cancelled
Add PRODUCT-SPEC.md draft — sellable subscription model
First draft of the product spec covering pricing tiers, billing,
auth model, distribution, support, hosting, and compliance posture.
10 questions with proposed defaults per phase 2 of the sellable
DashCaddy roadmap. Awaiting Sami's review.
2026-07-13 00:29:32 -07:00

124 lines
3.9 KiB
Markdown

# DashCaddy — Sellable Subscription Product Spec
> **Status:** DRAFT (awaiting Sami approval)
> **Created:** 2026-07-13
> **Owner:** Sami Ahmed
This spec covers what DashCaddy needs to become a sellable subscription
product. Decisions below are the proposed defaults — override anything
that doesn't match your business instincts.
---
## 1. Pricing & Business Model
### Q1. Pricing Model
**Proposed:** Tiered self-hosted + free.
| Tier | Price | Use case |
|---|---|---|
| **Free** | $0 | Single host, unlimited services, community support |
| **Pro** | $9/mo per host | Multi-host, priority support, cloud config backup |
| **Business** | $29/mo per host | SAML SSO, audit log export, custom branding |
License keys gate Pro/Business features. Keys validated against the
dashcaddy-license-server on DNS2.
### Q2. Free Tier Limits
**Proposed:** Unlimited features in self-hosted mode, just no cloud
features (backup, SSO, multi-host). Free users stay on the upgrade path
without feeling crippled.
---
## 2. Billing & Payments
### Q3. Payment Processor
**Proposed:** **Stripe** (best DX, supports per-seat metering, easiest
tax handling). Fallback: **Paddle** as Merchant-of-Record if VAT/sales
tax delegation is needed.
### Q4. Self-Serve or Sales-Led
**Proposed:** **Self-serve.** User signs up at dashcaddy.net → buys →
gets license key instantly → pastes into their instance.
---
## 3. Auth & Users
### Q5. Account Model
**Proposed:** **Central accounts at dashcaddy.net** (not per-instance
TOTP). OAuth via GitHub + Google. License keys issued to accounts,
instances validate keys against the license server.
### Q6. Multi-User
**Proposed:** **Yes, full RBAC.** Owners, Admins, Viewers per instance.
- Free = single user
- Pro = up to 5 users
- Business = unlimited users
---
## 4. Distribution & Support
### Q7. Distribution
**Proposed:** **Same installer script + GitHub releases + Docker Hub.**
- Free tier installs from public GitHub releases
- Pro/Business require license key to enable features post-install
### Q8. Support Channel
**Proposed:**
- **Free** → GitHub Discussions (best-effort SLA)
- **Pro** → Private Discord
- **Business** → Dedicated email + 24h response SLA
---
## 5. Hosting & Legal Posture
### Q9. Hosted Offering
**Proposed:** **Both.** Free + Pro are self-hosted. Add `cloud.dashcaddy.net`
later (managed Pro tier where you run the VPS).
- **Defer cloud for v1.0** — it's a separate ops burden.
### Q10. Compliance Minimums
**Proposed:** **GDPR-aware ToS + Privacy Policy** for v1.0.
- SOC2 deferred (expensive, blocks adoption)
- HIPAA deferred
- **Make this explicit on the pricing page** so business customers know
what's coming.
---
## Compliance with DashCaddy EULA
Per `/root/dashcaddy/LICENSE` (proprietary, copyright 2024-2026 Sami Ahmed):
- **License key model** is fully compatible with the EULA (per-instance
keys, 30-day evaluation without key for personal non-commercial use)
- **Hosted SaaS** requires a separate commercial agreement per EULA
section 1(e) — defer to v2
- Source availability (current state) is NOT open-source and doesn't
grant redistribution rights
---
## Open Questions / Decisions Deferred
- [ ] Pricing currency (USD only? multi-currency via Stripe?)
- [ ] Refund policy (Stripe standard 30-day? custom?)
- [ ] Annual vs monthly billing (Stripe subscriptions support both)
- [ ] Free trial length beyond the existing 30-day EULA evaluation
- [ ] Discount codes / launch pricing
- [ ] Domain for hosted offering (cloud.dashcaddy.net? dashcaddy.cloud?)
---
## What this spec unlocks (Phase 3 deliverables)
Once approved, I produce:
1. **Gap list** — what's currently built vs what this spec needs
2. **Prioritized build order** — what blocks public release first
3. **Architecture changes** — license server, account system, billing
integration, RBAC layer
4. **Documentation gaps** — install guide, admin guide, pricing page
5. **Compliance gaps** — ToS, Privacy Policy, support SLAs