Tu Empresa Digital OS — Product Decisions (resolving plan.html open questions)

historical · pm · updated 2026-06-26 · source

HISTORICAL (2026-06-26). Desktop/B2C + DigitalOcean + per-seat-USD era — superseded. Current product direction: tedos-business-model.md (B2B, MXN) + comprender-mvp-e1.md; hosting is Vercel + Fly (see decisions/log.md). Kept for context only — do not treat as current.

Owner: José Miguel Gutiérrez Delgado. Solo operator. B2B distribution via custom micro apps. Backend: DigitalOcean (App Platform + Spaces + Managed Postgres) — DevOps producing infra plan in parallel. Goal: cheap to operate, fast to MVP, defensible licensing story.

---

TL;DR Decision Table

#	Question	Recommendation	Confidence	Blocks build?
1	Update manifests & bundle distribution	DO Spaces (S3-compatible) + CDN. Per-client signed manifest fetched from API; bundles are content-addressed and shared across clients	H	No
2	Micro app bundle format + sandboxing	ESM bundle + import-map loaded inside a sandboxed <iframe> (same origin disabled). Host exposes a typed postMessage RPC (shell-bridge). Bundles signed with Ed25519	H	No
3	Admin dashboard scope	Separate Next.js web app on DO App Platform, same auth tenant. MVP = clients CRUD, plan toggle, app entitlements, suspension, release publishing	H	No
4	Per-tier pricing	Starter $29, Pro $89, Enterprise $299+ per seat/month. Annual -15%. Claude usage metered separately above a fair-use cap	M	Needs José sign-off
5	Claude API key model	Hybrid, default to José-billed shared key with per-tier monthly token cap; BYO key optional for Enterprise	M	Needs José sign-off
6	Vibe coding FS safety	Diff modal + dry-run sandbox + git snapshot before write. Restricted to a workspace/ sandbox dir. Available to all paid tiers, gated by vibeCoding: true license flag, off by default for Starter	H	No
7	Telemetry / error reporting	Self-hosted GlitchTip on DO (Sentry-compatible) + minimal product analytics via PostHog Cloud free tier. Errors opt-out, usage analytics opt-in for Starter, opt-out for Pro+ with DPA	H	No
8	Windows code-signing cert	Azure Trusted Signing ($10/mo, no HSM, no shipping). EV via SSL.com only if a client hard-requires SmartScreen reputation day-one	H	No

---

1. Update Manifests & Bundle Distribution

• Recommendation:
  • Store everything in DigitalOcean Spaces (S3-compatible) fronted by Spaces CDN (free, included).
  • Shell binaries: per-client path /<env>/shells/{clientId}/{platform}/{version}/... — fully isolated, allows custom branding per client without rebuilding the world.
  • Micro app bundles: content-addressed /<env>/apps/{appId}/{version}/bundle.{hash}.js — shared across all clients. One upload, N consumers.
  • Per-client entitlement manifest is dynamic, served by the API (GET /client/me/apps), signed with the same JWT used for auth. Manifest tells the shell which appId@version URLs to fetch from CDN.
  • The shell never reads a static manifest from the CDN. Discovery = API call. Delivery = CDN.
• Why:
  • Per-client static manifests on CDN would force a cache-invalidate roundtrip on every entitlement change. The plan already says "suspension takes effect within one polling cycle" — that contract only holds if entitlements come from the live API.
  • Content-addressed shared bundles = O(1) storage growth in apps, not apps × clients. Critical for "cheap to operate."
  • DO Spaces + CDN is ~$5/mo + bandwidth and S3-compatible, so we can swap to Cloudflare R2 later with zero code changes if egress bites.
• Alternatives considered:
  • Cloudflare R2 + Pages: cheaper egress but adds a second provider. Defer unless DO bandwidth bills exceed ~$50/mo.
  • Per-client static manifest JSON on CDN: kills the real-time suspension story.
  • GitHub Releases as CDN: free but rate-limited and unprofessional for B2B.
• Open sub-questions:
  • DevOps: confirm Spaces CDN supports signed URLs (yes, via presigned S3 URLs). We'll need them for Enterprise tier private bundles.
  • Decide cache TTL on bundle URLs (recommend immutable, max-age=31536000 since URLs are versioned).

---

2. Micro App Bundle Format + Sandboxing Model

• Recommendation:
  • Format: Single ESM bundle (bundle.js) + manifest.json per app, both signed with an Ed25519 key pair. The Tauri shell ships the public key; the API never sees the private key. Signing happens in CI from a key stored in 1Password / GH Actions secrets.
  • Sandbox: Render each micro app inside a Tauri isolated webview window or a same-process <iframe sandbox="allow-scripts"> with no allow-same-origin. MVP = iframe (simpler, fast). Phase 2 = isolated webview for Enterprise apps that need their own process.
  • APIs: Micro apps cannot touch window.__TAURI__ directly. They talk to the shell over a typed postMessage RPC called shell-bridge exposing a narrow surface:
    • claude.complete(prompt, opts) — proxied through shell, counted against the client's quota
    • google.sheets.read(id), google.drive.list(), etc. — proxied; the shell holds the tokens
    • storage.get/set(key, value) — namespaced to the appId, backed by tauri-plugin-store
    • ui.toast, ui.openModal, ui.navigate
    • fs.read(path) / fs.write(path) — only inside workspace/{appId}/ (enforced in Rust)
  • Permissions declared in manifest.json (requires: ["claude", "google.sheets", "fs.workspace"]) and shown to the user on install, mac App Store style. The shell refuses to mount an app whose runtime calls exceed declared permissions.
• Why:
  • Iframe + postMessage is the industry standard sandbox (Notion, Figma plugins, VS Code webviews). It works today with zero Rust changes.
  • Ed25519 signing means a leaked bundle URL can't be tampered with — clients verify before executing. Mandatory once we have third-party micro apps; cheap to add now.
  • Capability-declared permissions are the only credible privacy story to give Enterprise buyers.
• Alternatives considered:
  • Full Tauri webview per app: heaviest but most isolated. Overkill for MVP; revisit when apps need their own session cookies.
  • Native dynamic Rust plugins: dangerous, hard to sign, slow iteration. No.
  • Unsandboxed JSX modules imported into the shell bundle: zero isolation, can't ship to third parties later. Hard no.
• Open sub-questions:
  • Where does CSP get enforced? Recommend Tauri CSP header + iframe csp attribute.
  • Hot-reload during vibe coding needs to bypass signature verification in dev mode only. Document this clearly.

---

3. Admin Dashboard Scope

• Recommendation:
  • Separate Next.js app (admin.tedos.tuempresa.digital) hosted on DO App Platform. Same auth provider, role-gated to staff. Not embedded in the shell.
  • Reasons it's not in the shell:
    • José already runs the shell on his daily machine; an in-shell admin is fine for prototyping but conflates "user" and "operator" mental models.
    • A web admin works from any browser, including mobile when a client emails at 2am.
    • Separating lets us share the admin login with future support staff without giving them a desktop install.
  • MVP feature list (build order):
    1. Clients table — search, status badge, plan, last seen, due date.
    2. Client detail — toggle status (active/grace/suspended/deactivated), edit plan, toggle individual apps, force logout.
    3. Apps table — list, version, upload new bundle (drag-drop .js + manifest.json, runs signing in CI via a publish endpoint).
    4. Releases — assign app version to a client (or "all on plan X").
    5. Audit log — every status change + bundle publish, append-only.
    6. Billing snapshot (read-only from Stripe) — plan, MRR per client, next invoice.
  • Out of MVP: support tickets, analytics dashboards, fancy charts. Use PostHog / Stripe dashboards directly for those.
• Why:
  • Each item above maps 1:1 to an admin action already promised by the plan ("set status," "toggle apps," "trigger forced logout").
  • Next.js + DO App Platform is the cheapest sane choice (~$5/mo) and the same stack José already uses for tuempresa.digital.
• Alternatives considered:
  • In-shell admin view: faster to build but doesn't scale beyond José.
  • Retool / Refine: faster for v0 but locks us in and looks unprofessional in front of buyers.
  • Supabase Studio: not applicable since backend is DO.
• Open sub-questions:
  • Single sign-on with the shell? Recommend shared users table with role = staff|client.
  • Do we want the admin to also run vibe coding sessions remotely? Defer.

---

4. Per-Tier Pricing

Pricing is a business call — these numbers are recommendations only. Sign-off required.

• Recommendation (per seat / month, USD, monthly billing):

Tier	Price	Seats included	Micro apps	Claude tokens / mo	Vibe coding	Support SLA	Branding
Starter	$29	1	Up to 3 from catalog	500K input / 100K output (≈ $5 cost ceiling)	Read-only preview, no FS writes	Email, 3-day	Shared "Tu Empresa Digital OS" build
Pro	$89	up to 5 (additional $19/seat)	Up to 10 from catalog	3M input / 500K output (≈ $30 ceiling)	Yes, sandboxed to workspace/	Email, next-business-day	Client logo + accent color
Enterprise	from $299	Unlimited (volume)	All apps + 1 custom built by José	Negotiated, or BYO key	Yes, configurable scope	Slack/WhatsApp, 4h business hours	Full custom build, custom domain update channel
Annual	-15%
Overage	$0.02 / 1K extra input tokens, $0.10 / 1K extra output tokens (≈2x cost)

• Why:
  • Anchors are Linear ($8 starter, $14 pro) and Raycast Pro ($10) — but those don't carry inference cost. AI-bundled tools (Cursor $20, ChatGPT Team $25) set the floor; per-seat AI tools above $20 are normal.
  • $29/$89/$299 hits a clean 3x ladder, easy to upsell.
  • Token caps chosen so Claude API cost stays ≤ ~17% of MRR per client at Sonnet pricing — leaves margin for DO, support, and José's time.
  • Per-seat is the right unit because micro apps are productivity tools, not B2C.
• Alternatives considered:
  • Flat per-company pricing (e.g. $99/mo all-in): simpler but caps revenue at ~$1k/company. Bad for a solo operator.
  • Usage-based only: scary for B2B buyers, hard to forecast for José.
  • Free tier: rejected. Each install has nonzero hosting + token cost. A 14-day trial is enough.
• Open sub-questions (need José):
  • Free 14-day trial yes/no.
  • Annual discount: 15% or 20%?
  • Does Enterprise include white-label (no "Powered by Tu Empresa Digital OS")?

---

5. Claude API Key Model

• Recommendation: Hybrid, defaulting to shared key + quota.
  • Starter & Pro: José-billed shared Anthropic key. Quota enforced by an API proxy (/v1/claude/complete) that adds the key server-side, logs tokens to Postgres, and rejects on over-quota with a "upgrade or wait until next month" response. Clients cannot see or extract the key.
  • Enterprise: offer BYO key as an option. Stored encrypted in stronghold + mirrored hash on the API for accounting. When set, proxy passes through and skips the quota check.
• Why:
  • Shared key is the only way to make AI usage feel native to non-technical clients. Asking a small business to create an Anthropic account is a 30% conversion killer.
  • Proxy is mandatory for cost control: if we pass keys to the client and they leak, José is liable. If we let clients call Anthropic direct with their own key, we lose visibility for billing.
  • BYO at Enterprise lets us land deals where compliance/legal mandate "your data, your key, your contract with Anthropic."
• Implications:
  • Cost: Predictable per-tier ceiling. Worst case = quota hit → user blocked, not surprise bills.
  • Abuse: Mitigate with token bucket (rate limit) + daily cap + 95th-percentile alerting in Sentry/GlitchTip. The proxy is the throat to grab if a client goes rogue.
  • Lock-in: Shared key = soft lock-in (clients depend on José's infra). BYO at Enterprise = explicit unlock for those who pay extra.
  • Latency: Adds one hop. Mitigate by colocating proxy in the DO region closest to most clients (NYC3 for LATAM/US).
• Alternatives considered:
  • BYO only: blocks 80% of buyers.
  • Shared only: blocks Enterprise compliance deals.
  • Per-message microbilling à la OpenRouter: too complex for v1, makes pricing legibility bad.
• Open sub-questions (need José):
  • At what point do we expose a token-usage dashboard inside the shell for clients to see their consumption? Recommend Phase 4.

---

6. Vibe Coding FS Safety

• Recommendation:
  • Diff modal mandatory. Every Claude-proposed file write goes through a ProposedChanges UI: file tree on the left, unified diff on the right, "Apply / Discard / Re-prompt" buttons. No streaming writes to disk.
  • Git snapshot before apply. The shell auto-initializes a hidden git repo at workspace/.git and commits a checkpoint before each apply. One-click rollback = git reset --hard HEAD@{1}.
  • Path jail. Rust-side, all fs.write calls validate the resolved path is inside workspace/{appId}/. Anything else returns an error. No escape via ...
  • Dry-run preview. For micro app component edits, render the proposed code in a second iframe (the "preview" pane) without overwriting the running version. Apply only on confirmation.
  • Tier gating:
    • Starter: vibe coding preview only — Claude can show diffs but apply is disabled. Drives upgrade.
    • Pro+: full apply, scoped to workspace/.
    • Enterprise: configurable allow-list of directories.
  • Auto-rollback triggers if the shell crashes within 60s of a vibe-coding apply (likely a syntax error) → revert last checkpoint and surface the diff with the error message.
• Why:
  • This is the single biggest "scary" feature for B2B buyers ("AI writes code on my machine?!"). The whole flow needs a "user always in the loop + always reversible" story.
  • Git is the cheapest, most-trusted rollback system in existence. We don't need a custom undo stack.
  • Tier-gating apply is the cleanest upgrade hook because the value is obvious from the first interaction.
• Alternatives considered:
  • Auto-apply + post-hoc undo: faster but breaks trust. Hard no.
  • Full VM sandbox (Firecracker, etc.): overkill for desktop apps; defer.
  • Allow vibe coding only for José: kills the platform pitch.
• Open sub-questions:
  • Do we let clients commit their workspace/ to their own git remote? Recommend yes, Phase 5 — "export to GitHub" button.

---

7. Telemetry / Error Reporting

• Recommendation:
  • Errors: Self-host GlitchTip (Sentry-compatible API, free, fits in a $5 DO droplet) at errors.tedos.tuempresa.digital. Use the official @sentry/react SDK pointed at our DSN.
  • Usage analytics: PostHog Cloud free tier (1M events/mo). Easier than self-hosting; we can migrate to self-hosted PostHog if volume justifies.
  • What gets reported:
    • Always: unhandled exceptions, Rust panics, Tauri command errors, Claude API errors, auth failures, version + platform.
    • Usage (consented): app opens, micro app launches, feature names invoked, vibe coding apply count, session duration. No message content, no file contents, no Claude prompts.
  • Consent model:
    • Crash/error reporting: opt-out, disclosed in onboarding. Industry standard.
    • Usage analytics: opt-in for Starter, opt-out for Pro+ (covered by DPA), disabled by default for Enterprise (with a switch in admin).
  • Privacy doc: publish a short privacy.tedos.tuempresa.digital page with the exact event list. Critical for Enterprise procurement.
• Why:
  • Solo dev → must know when prod breaks. Sentry SaaS is $26/mo minimum, GlitchTip is free + same SDK.
  • B2B buyers will ask "what do you collect." Having a published list is a closing tool, not a chore.
• Alternatives considered:
  • Sentry SaaS: works fine, but $26/mo × growing volume hurts margin. Same SDK so we can flip later.
  • No telemetry: blind to crashes, untenable.
  • Mixpanel / Amplitude: enterprise sales motion, expensive, more than we need.
• Open sub-questions:
  • Does DevOps want errors in the same observability stack as backend logs (Loki/Grafana)? If yes, GlitchTip stays for client-side, backend uses its own. Recommend keep separate.

---

8. Windows Code-Signing Cert

• Recommendation: Azure Trusted Signing.
  • $9.99/mo for the "Basic" plan (3,000 signatures/mo, well above need).
  • Cloud-based — no HSM, no USB token to courier, signs in CI directly via Azure SDK.
  • Microsoft-issued cert → instant SmartScreen reputation for new publishers (this is the killer feature; OV certs take weeks of downloads to build reputation, EV certs cost 4–6x more).
  • Works with tauri-action via the official azure-trusted-signing GH Action.
• Why:
  • José needs a Windows-shipping path that doesn't require shipping a YubiKey to him in Mexico City or paying $400+/yr for an EV cert.
  • As of 2024, Microsoft rolled out Trusted Signing specifically to kill the EV-cert tax for small ISVs. It is the modern default.
• Cost comparison:

Option	Cost (year 1)	SmartScreen reputation	Friction
Azure Trusted Signing	~$120	Instant (MS-issued)	Low (CI native)
EV cert via SSL.com	~$350–500 + HSM/USB token	Instant	High (physical token)
OV cert via Sectigo/DigiCert	~$200	Weeks of downloads to build	Medium
Self-signed / unsigned	$0	None (SmartScreen blocks)	Catastrophic

• Alternatives considered:
  • EV cert from SSL.com: only if a specific Enterprise client mandates EV (some banks do). Buy it then, expense to that contract.
  • Sectigo Code Signing on a cloud HSM: more expensive than Azure for the same outcome.
  • DigiCert: same, worse UX.
• Open sub-questions:
  • Does José already have an Azure tenant? If not, account creation is the only setup friction.

---

Cross-cutting Implications

• DevOps scope grows by 3 services: API + worker (Postgres), admin (Next.js on App Platform), errors (GlitchTip droplet). Plus Spaces bucket + CDN. All on DigitalOcean, all <$50/mo at launch.
• Security perimeter is now the Claude proxy. Any abuse, leak, or runaway client cost will manifest there. Build it with strict rate-limiting, daily quota, and per-client circuit breakers from day one — retrofitting is painful.
• Pricing × Claude quota are coupled. Token caps in section 4 are derived from sustainable cost margins; they cannot be changed without re-running the math. Document the formula somewhere durable.
• Time to MVP: Sections 1, 2, 3, 7, 8 are all "pick a vendor and wire it up" decisions — net new code, maybe 2 weeks for a solo dev. Sections 4, 5, 6 carry business risk and need José's input before any UI work locks in copy.
• Defensible moat: the per-client micro app catalog + signed bundles + tier-gated vibe coding is what justifies the price. None of the individual pieces are novel; the bundle is.

---

Decisions Needing José's Sign-Off

1. Pricing numbers ($29 / $89 / $299) — are these the right anchors for your client base in MX/LATAM vs US?
2. Token caps per tier (500K / 3M input tokens) — comfortable with the ~17% Claude-cost-of-MRR ceiling? Higher = better UX, lower = better margin.
3. Free trial — yes/no, and if yes, how long (recommend 14 days, no credit card).
4. Annual discount — 15% or 20%?
5. Vibe coding on Starter tier — confirm "preview-only, no apply" is the right upgrade gate, not just disabling it entirely.