diraOSS core free forever; individuals buy the apps once; teams subscribe; hosted never required
Three segments, sequenced — and they are different *customers*, not competing pricing models:
1. **Now — free OSS forever:** CLI, hooks, the Claude Code skill, and `dira ui`. 2. **v1 apps — one-off purchase:** iOS + desktop bundle. Data stays on-device or in the user's own GitHub. Privacy-as-product is a genuine strength here rather than a constraint, and it costs nothing to serve: no ops, no on-call, no security surface. Plan for pay-once-per-major-version, which is how sustainable indie apps square "one-off" against "updates forever." 3. **When teams pull for it, not before — per-seat subscription:** shared review queues, members without GitHub, SSO, org dashboard, notifications. Real ongoing cost, real ongoing value, subscription-shaped.
The honest caveats on the one-off lane, recorded so they are not rediscovered as surprises: one-off revenue is a decaying curve per release, and App Store discovery is brutal without the OSS funnel doing the marketing work.
The ordering is itself the strategy: the paid apps fund the OSS credibly ("buying the app supports kazi and dira") instead of the OSS reading as bait. cst-0004 holds throughout — no tier of this model is allowed to make the hosted service necessary.
Alternatives on record — 4
✗Individual subscription for the appsrefused A subscription needs a recurring cost or recurring delivered service behind it to feel legitimate, and hosted sync — the usual justification — was designed away: GitHub is the sync layer (dec-0005) and this audience already has it for free.
Charging monthly for an app whose data sits in the user's own git repos reads as rent, and developer audiences punish that hard.
revisit ifdira escapes the terminal audience to users who have no GitHub account, where a real sync service becomes a real deliverable
✗Hosted-first subscription for everyone, from launchrefused It inverts the trust story, imposes ops and on-call on a solo maintainer already carrying kazi, and makes the OSS core feel like a funnel to a paywall rather than the product.
It inverts the trust story, imposes ops and on-call on a solo maintainer already carrying kazi, and makes the OSS core feel like a funnel to a paywall rather than the product.
✗Charge for the CLI or gate features behind a license keyrefused The CLI and hooks are the adoption engine and the kazi-org flywheel.
Gating them removes the reason anyone would ever want the apps.
✗Pure OSS, no revenuerefused Does not fund the maintenance of two products, and leaves no answer to the open venture-level monetization question.
Does not fund the maintenance of two products, and leaves no answer to the open venture-level monetization question.