Productized open-source
Package a self-hosted tool as a commercial product with plans, lifecycle state, and a buyer-readable boundary.
Mooring paths
Mooring paths for isolated product instances.
BayStore gives product and platform teams a static public buying surface, a commercial instance record, and lifecycle language that stays honest about sandbox checkout and bounded launch evidence.
Choose by berth motion
Start with the operating model, then choose the product.
BayStore is strongest when buyers need a named private instance, not a shared tenant or a raw infrastructure handoff.
Managed instances
Give each customer a dedicated instance record with access metadata, support context, and plan-scoped capacity.
Recoverable operations
Replace opaque tickets with visible lifecycle states, explicit operator action records, and API-requested runtime work.
Path comparison
Read across before you trace a path.
Each mooring path produces the same kind of buyer-visible instance record, but the signal that points you to it differs. Match the buyer signal in the left column to the path.
| Mooring path | Buyer signal | What the record carries | Held back until launch |
|---|---|---|---|
| Productized open-source | You ship a self-hosted tool and want a commercial wrapper, not a billing rebuild. | Product family, plan depth, lifecycle state, and a buyer-readable boundary. | Production payment capture and provider billing configuration. |
| Managed instances | Every customer expects a private, named deployment rather than a seat. | Dedicated instance record, access metadata, support context, and plan-scoped capacity. | Production identity, session issuance, and runtime provisioning. |
| Recoverable operations | Support context keeps scattering across tickets instead of the instance. | Visible lifecycle states and explicit operator action records. | Worker-backed runtime mutation and production cluster execution. |
- You sell named product instances rather than shared workspace seats.
- Buyers need clear plan, status, access, and recovery language.
- Operators need commercial state separated from production runtime changes.
- You need a general application hosting platform.
- You need live payment processing without a separate provider launch task.
- You need production cluster mutation claimed by the public static site.
Launch boundary: Checkout remains
sandbox_placeholder; this public site does not charge cards or configure production provider billing. The bounded non-payment launch packet covers the M100 evidence path, while live payments, hosted checkout, and managed-provider claims remain separate gates.