Tu Empresa Digital OS — Product Decisions (resolving plan.html open questions)
:::note Contenido en inglés Esta página del wiki se sincroniza desde la base de conocimiento en inglés y todavía no está traducida. :::
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 whichappId@versionURLs 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=31536000since URLs are versioned).
2. Micro App Bundle Format + Sandboxing Model
- Recommendation:
- Format: Single ESM bundle (
bundle.js) +manifest.jsonper 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 noallow-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 typedpostMessageRPC calledshell-bridgeexposing a narrow surface:claude.complete(prompt, opts)— proxied through shell, counted against the client's quotagoogle.sheets.read(id),google.drive.list(), etc. — proxied; the shell holds the tokensstorage.get/set(key, value)— namespaced to the appId, backed bytauri-plugin-storeui.toast,ui.openModal,ui.navigatefs.read(path)/fs.write(path)— only insideworkspace/{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.
- Format: Single ESM bundle (
- 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
cspattribute. - Hot-reload during vibe coding needs to bypass signature verification in dev mode only. Document this clearly.
- Where does CSP get enforced? Recommend Tauri CSP header + iframe
3. Admin Dashboard Scope
- Recommendation:
- Separate Next.js app (
admin.tedos.tuempresa.digital) hosted on DO App Platform. Same auth provider, role-gated tostaff. 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):
- Clients table — search, status badge, plan, last seen, due date.
- Client detail — toggle status (active/grace/suspended/deactivated), edit plan, toggle individual apps, force logout.
- Apps table — list, version, upload new bundle (drag-drop
.js+manifest.json, runs signing in CI via a publish endpoint). - Releases — assign app version to a client (or "all on plan X").
- Audit log — every status change + bundle publish, append-only.
- 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.
- Separate Next.js app (
- 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
userstable withrole = staff|client. - Do we want the admin to also run vibe coding sessions remotely? Defer.
- Single sign-on with the shell? Recommend shared
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.
- Starter & Pro: José-billed shared Anthropic key. Quota enforced by an API proxy (
- 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
ProposedChangesUI: 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/.gitand commits a checkpoint before each apply. One-click rollback =git reset --hard HEAD@{1}. - Path jail. Rust-side, all
fs.writecalls validate the resolved path is insideworkspace/{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.
- Diff modal mandatory. Every Claude-proposed file write goes through a
- 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.
- Do we let clients commit their
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/reactSDK 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.digitalpage with the exact event list. Critical for Enterprise procurement.
- Errors: Self-host GlitchTip (Sentry-compatible API, free, fits in a $5 DO droplet) at
- 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-actionvia the officialazure-trusted-signingGH 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
- Pricing numbers ($29 / $89 / $299) — are these the right anchors for your client base in MX/LATAM vs US?
- Token caps per tier (500K / 3M input tokens) — comfortable with the ~17% Claude-cost-of-MRR ceiling? Higher = better UX, lower = better margin.
- Free trial — yes/no, and if yes, how long (recommend 14 days, no credit card).
- Annual discount — 15% or 20%?
- Vibe coding on Starter tier — confirm "preview-only, no apply" is the right upgrade gate, not just disabling it entirely.