VibeProSoft
VibeProSoft · Flagship

The admin platform
for SaaS builders
who ship.

VibeProSoft Hub is a configurable entitlement and admin engine for the apps you build. Plans, licenses, SSO, and an MCP server for agentic ops — wired the way your business actually works.

Augmented · By · Design

Intelligence, with Intention · One Hub · Every Tool · Augmented · By · Design

What we're building

Shipping in the open.

Each section below is one Hub capability. We mark each one Live the day it ships — every In progress and Coming tile is the roadmap, not a promise.

01

Plan Builder

Shipped

Define what every tier includes — in the UI, not in SQL.

Author pricing tiers with names, taglines, prices, billing intervals, and visibility. Each plan grants per-key values for any entitlement defined in the engine — caps that combine with grants and credits using max-wins-for-caps and sum-for-metered semantics.

Archive plans without breaking existing subscriptions. Every change writes an audit row so you always know who set what, and when.

  • Plan CRUD with slug, price, interval, visibility, display order
  • Per-plan entitlement value editor (numeric, boolean, string types)
  • Hard-limit and reset-period overrides per plan
  • Audit log on every create / update / archive / entitlement change
  • Lives at /admin/billing/plans inside any Hub instance
/admin/billing/plans ● live
Plan Price Ents
Free
free
$0 4
Standard
standard
$12 / mo 6
Pro
pro
$29 / mo 9
Stylized preview — drop a real screenshot here when convenient.
02

Entitlement engine

Shipped

Two licensing models, one engine — quota or per-key.

Define the license keys the engine knows about right in the admin UI — no SQL. Boolean keys gate per-app exclusivity ("only Pro unlocks Sidekick" → app.sidekick.access). Numeric keys model quotas that combine across plans, segments, and grants with max-wins-for-caps semantics. Metered keys (monthly_credits, api_calls) sum across credit blocks and consume soonest-first.

Plans grant values for any key. The launch gateway already enforces these for app deployments. Plan Builder + Entitlement keys together cover both the quota model and per-key exclusivity in one engine.

  • Entitlement-definition CRUD with boolean / numeric / string types
  • Cap (max-wins) vs metered (sum-of-credits) numeric modes
  • Reset period per key — drives the reactivation cron
  • "Used by" indicators per key (plans · segments · grants · credits)
  • Safe-delete guard — refuses if any plan / grant references it
  • Lives at /admin/billing/entitlements
03

Admin Grant UI

Shipped

Issue trials and overrides without a database client.

Open any user and see exactly where they stand — effective entitlements (engine-resolved across default → segment → plan → grants → credits), active subscription with trial countdown, and the full history of what's been granted to them. Start a trial on any plan with a click. Issue a one-off entitlement grant (boolean, numeric cap, or metered credit block) with optional TTL. Revoke any active grant immediately.

Hub is now the source of truth for admin-issued trials and manual grants. Stripe and Polar remain the sources for paid-conversion trials — that lands in the billing-bridge slice next.

  • Per-user effective-entitlements explorer (every key, every source)
  • Start trial on any plan, N days — auto-cancels the prior subscription
  • Issue grants: boolean / numeric cap / metered credit block, optional TTL
  • Revoke any active grant or credit block in one click
  • Change segment + promote / demote admin role
  • Every action audits with the granting admin's user id
  • Lives at /admin/users/:id
04

End-user claim flow

Shipped

"Pick any N apps" — without admin intervention.

Users see a quota meter on their dashboard and the catalog, plus an Activate button on every app's detail page. Activating fills a slot; deactivating frees one. The launch gateway enforces the contract: if a user has quota headroom, it auto-activates on first launch so the click-and-launch UX is preserved; if they're at their cap, it denies with a clear "deactivate one first or upgrade" page.

Pro and unlimited plans (max_apps ≥ 9999) bypass the gate transparently. Tenants who don't use the quota model just don't grant max_apps — and the activation flow disappears for their users.

  • user_app_activations table — soft-deactivate for clean audit
  • Quota meter on /dashboard and /apps
  • Activate / Deactivate on every /apps/:slug page
  • Gateway auto-activates with headroom, denies on full
  • Admin can see + deactivate any user's slot from /admin/users/:id
  • Unlimited plans (max_apps ≥ 9999) skip the gate transparently
05

App onboarding automation

Shipped

Hub wires the little things so you don't have to.

Registering an app shouldn't mean a side-quest through the Cloudflare dashboard. The Hub now runs a setup-status panel on every app's admin page — it checks the Worker exists in your CF account, that the launch URL resolves, that the brand hostname is attached as a Custom Domain, and that probes are returning healthy. Each ❌ becomes an actionable next step.

When a custom domain is missing, the Hub offers to wire it for you via the CF API. One click, ~30 seconds for cert provisioning, done. If your token doesn't have the right scopes, the same button gracefully falls back to a deep-link into the CF dashboard so you can finish it there.

  • Server-side readiness panel: Worker exists / DNS / TLS / hostname wired / probe healthy
  • One-click "Wire it for me" — calls CF API to attach the Custom Domain
  • Graceful fallback to CF dashboard deep-link when token scopes are read-only
  • Immediate health probe on app create / launch_url change — no more 5-min wait
  • Audit trail: app.probe_manual, app.domain_wired, app.domain_wire_failed
  • Lives at /admin/apps/:id
06

Clerk + legacy migration

Coming

Move every legacy user to Clerk without a big-bang migration.

The Hub already runs dual-stack auth — Clerk preferred, PBKDF2 fallback when legacy_login_enabled is true. The remaining work is the silent migration step: on a successful legacy login, provision the user a Clerk identity, link clerk_user_id on their existing row, and surface a one-screen prompt to set a Clerk password (or sign in with Google). From that login forward they're on Clerk; the legacy row stays for audit but password_hash gets cleared. Flip legacy_login_enabled off once everyone has migrated.

  • Find-or-create Clerk user on legacy login
  • Link users.clerk_user_id and clear password_hash
  • One-screen interstitial: "Set up your Clerk identity"
  • Zero downtime, no admin-driven cutover
07

Billing bridge

Coming

Stripe and Polar — read state, never lose ground truth.

External provider webhooks already land in the Hub (Polar today; Stripe and Flexprice are interface-compliant stubs). The bridge work surfaces the provider state in the admin grant UI, reconciles drift with a nightly job, and exposes the "who owns this trial" answer plainly: Hub owns admin-issued, provider owns paid-conversion.

  • Polar webhook ingestion (live today)
  • Stripe and Flexprice provider stubs (live today)
  • Drift-reconciliation job (coming)
  • Provider-state badge on every user (coming)
08

Tenant provisioning API

Coming

Hub provisions Hub — the one piece the operator instance needs.

Until the first paying customer arrives we run as a single-tenant operator Hub. When that customer signs up, a small provisioning slice spins up a fresh tenant — its own D1 bindings, its own admin bootstrap, its own subdomain on vibeprosoft.app. The operator Hub keeps managing the relationship: trials, billing, support overrides.

  • Tenants table + tenant_id seam across every domain table
  • Provisioning endpoint with idempotency
  • Subdomain wiring on vibeprosoft.app
  • Operator-level entitlements: "how many seats does this tenant get"

We're our own first customer.

Every capability above is built into the operator Hub we run to manage our own apps — Sidekick, Inbox, Pulse, and everything else we ship. When you sign up, you get the same engine on your own subdomain.