PATAPIM ▸ Strategy Memo
Vol. 01 · No. 01 Abril · MMXXVI Confidencial
Análisis a fondo

¿Open source
o producto
cerrado?

Ni lo uno ni lo otro. La pregunta correcta no es abrir o cerrar — es qué abrir y qué cobrar.

I Lo que tenés en la mano

PATAPIM no es un IDE más.

Es un wrapper de Claude Code con piezas muy específicas — y, sobre todo, con piezas que no son código: son servicios corriendo en infraestructura tuya, con costo recurrente.

El producto, mirado de cerca, son cinco capas distintas:

1 · Capa de UX/IDE

Electron + renderer. Replicable, sí — pero es donde está el polish. Es el envase, no el contenido.

2 · Integraciones zero-setup

Telegram, WhatsApp, email vía relay alojado en patapim.ai. Esto es servicio, no código. Requiere infraestructura corriendo, dominio, certificados, monitoreo.

3 · Browser embebido + MCP tools

Diferenciador técnico fuerte. El usuario corre acciones autenticadas (Cloudflare, Gmail, GitHub) sin moverse del IDE.

4 · Remote mobile

patapim.ai/remote. Otra vez: infraestructura alojada, no binario.

5 · Code signing pago

Azure Trusted Signing, identidad Eggscape Entertainment. Inversión inequívoca de producto comercial.

Gran parte del valor único ya vive en servicios que cuestan plata — no en el binario.
II El camino que no

Open source puro: por qué no.

El modelo OSS puro en este mercado no monetiza — salvo que tengas VC para quemar.

⚠ Contras decisivos

Cinco razones para descartarlo de entrada.

  • Cursor lleva +$300M ARR siendo cerrado. Zed es OSS y vive de prometer un futuro plan paid. Continue.dev es básicamente regalado.
  • El nicho OSS ya está tomado por OpenClaw (247K stars). Abrir PATAPIM hoy es entrar como #2 a una pelea ya decidida. Ver caso de estudio §VI.
  • Anthropic puede comerte el almuerzo. Si sos OSS, cualquier feature buena la copian gratis. Si sos cerrado, al menos construís marca y lock-in de UX.
  • El moat está en el relay. Liberás el código, alguien forkea, apunta a su propio backend, y te quedaste sin negocio.
  • Code signing + dominio + R2 + Azure: ya estás gastando como producto. OSS sin monetización clara es subsidiar usuarios indefinidamente.
III El otro extremo

Cerrado puro: tampoco.

⚠ Tres bloqueadores

Te corta acceso al segmento que más te conviene.

  • Trust issue. Corre con la API key del usuario y un browser embebido con sesiones reales. Devs paranoicos no instalan binarios cerrados que tocan eso — y son tus mejores early adopters.
  • Distribución brutal. Sin GitHub stars, sin "Show HN", sin comunidad: arrancás desde cero contra Cursor (paid ads, marca) y Claude Code oficial (gratis, oficial).
  • Velocidad. Las contribuciones externas en un nicho como "wrapper de Claude Code" suman features que vos no harías nunca.
§ § §
IV La recomendación

El modelo es open core.

Sentry, GitLab, PostHog, Supabase. Para PATAPIM mapea casi sin fricción.

▸ Distribución de licencias por capa
Capa Licencia Razón
Electron shell, renderer, MCP tools, browser panel MIT / Apache Genera trust, stars, contribuciones, instalación manual.
Binarios firmados, main.jsc compilado Cerrado · Pago El que quiera instalar y andar paga. El code signing tiene costo real.
Relay de notificaciones (patapim.ai/notify) SaaS · Free + Paid Telegram / WhatsApp / email vía servicio tuyo = recurring revenue.
Remote mobile access SaaS · Paid Hay infraestructura corriendo. Justifica suscripción.
Auto-update + soporte Paid tier Modelo Sentry / GitLab clásico.

Por qué funciona acá específicamente

Cuatro razones que se sostienen entre sí:

El moat queda donde está la plata (relay + remote), no en el código del IDE. Quien quiera autohostear, que se haga el laburo — los devs paranoicos lo agradecen, los demás pagan.

Anthropic no puede copiarte los relays sin volverse una empresa de comms. Está fuera de su scope. Es la única defensa real contra el riesgo "Anthropic ships your feature next month".

Devs paranoicos pueden auditar y self-hostear. Ganás a los early adopters técnicos sin perder revenue del mainstream.

GitHub stars = marketing gratis. El repo OSS empuja al funnel paid. No tenés que pagar ads para que la gente sepa que existís.

Open core no es medio abrir. Es ser quirúrgico sobre dónde está el negocio.
V Lo que hay que mitigar

Cuatro riesgos del open core.

Fragmentación de forks

Mitigación: publicar binarios oficiales tan convenientes que el fork sea siempre la peor opción. El code signing ya habilita esto.

El "AGPL trap"

Si vas OSS, MIT o Apache, no AGPL. AGPL espanta a empresas que podrían pagarte por una licencia comercial. La libertad atrae más que la viralidad legal.

Definir qué queda cerrado

El relay y el flow del mcp-token son no negociables. Documentarlo desde el día uno, no después.

Comunicación honesta

El README tiene que decir "OSS app, paid hosted services" sin ambigüedad. PostHog lo hace bien — modelo a copiar.

Caso de estudio · 2025–26

El caso OpenClaw
(ex-Clawdbot).

Un solo dev austriaco hizo casi exactamente lo que vos estás haciendo — asistente AI local controlado por Telegram, WhatsApp, Discord — pero open source. En cuatro meses: 247.000 stars, dos cambios de nombre forzados, y el creador en OpenAI.

Qué pasó, en orden

Steinberger ganó fama y un trabajo en OpenAI.
El producto, como negocio propio, no existe.

¿Es esto exactamente PATAPIM?

Es incómodamente parecido. Misma idea base: agente AI local + control desde apps de mensajería + skills + integraciones. Hasta los nombres riman: PATAPIM, OpenClaw — palabras inventadas, juguetonas, en torno a Claude.

Las diferencias importan, pero no son grandes:

i
Vector de UX distinto

OpenClaw es chat-first: vivís dentro de Telegram/WhatsApp. PATAPIM es desktop-IDE-first: vivís dentro de un IDE Electron y las notificaciones son canal secundario.

ii
El nicho OSS ya está tomado

Si abrís PATAPIM mañana, sos el #2 contra un proyecto con 247K stars. La pelea por mindshare OSS ya se jugó — y la perdiste sin haber jugado.

iii
Salida de Steinberger ≠ negocio

OpenClaw no monetizó. Su autor ganó fama y un puesto en OpenAI. Eso es una salida — la del developer que quiere atención, no plata. ¿Es esa la que querés?

iv
Anthropic puede tocarte la marca

"Clawd" forzó renombre porque era muy cerca de "Claude". PATAPIM está limpio — palabra inventada, sin parecido fonético. Lección: no usés nombres que toquen marcas registradas de los labs.

Lo que esto cambia en el análisis

La conclusión original — open core — no se rompe, pero el posicionamiento tiene que ser más quirúrgico:

1 · No competir contra OpenClaw en su terreno. No abrir PATAPIM como "otro asistente AI local". Ese terreno está cerrado. Si vas OSS, abrís otra cosa: el shell de IDE de escritorio, que OpenClaw no tiene.

2 · El paid layer importa más que antes. OpenClaw demostró que con OSS solo, sin negocio, el camino es fundación + acquihire. Si no querés ese camino, tenés que tener servicios pagos reales — relays, mobile, code signing, soporte.

3 · Posicionamiento honesto en el mercado. "OpenClaw es el agente OSS chat-first; PATAPIM es el IDE de escritorio comercial con polish profesional." Públicos distintos, no copia barata.

4 · La marca está OK — los handles, no garantizado. El nombre PATAPIM no tiene riesgo de trademark con Anthropic. Pero los handles (npm, github org, dominio en otras TLDs) hay que asegurarlos antes de OpenClaw o cualquier otro le ponga el ojo.

▸ La respuesta directa

¿Puede pasarte lo mismo? Una parte sí, otra no.

El renombre forzado por Anthropic, no — PATAPIM es lingüísticamente seguro. El "OSS viral sin negocio que termina en acquihire", sí — y es el riesgo real si abrís sin paid layer estable. Lo que cambia es la pregunta de fondo: ya no es "¿abro o cierro?", es "¿quiero terminar como Steinberger en OpenAI, o quiero un negocio propio?" Esas son dos partidas distintas, con jugadas distintas.

VII Anatomía del paid layer

¿Qué significa "cerrar el paid layer"?

Cinco engranajes que tienen que girar al mismo tiempo. Si falta uno, no hay negocio — hay un side project con cobro pegado con cinta.

Estos son los pilares y el estado actual de cada uno:

  1. Binarios firmados

    Windows: Azure Trusted Signing con identidad Eggscape Entertainment Inc. verificada. Mac: Apple Developer ID + notarización. Sin firma, el SmartScreen / Gatekeeper espantan al 80% de los usuarios antes de instalar.

    En curso
  2. Licencias y cobro

    Stripe + Cloudflare KV (LICENSES) + flujo de activación dentro de la app. El usuario paga, recibe license key, la app valida en el main process y desbloquea features. Hoy hay infra base; falta wirearlo end-to-end.

    Parcial
  3. Relays gestionados

    Notificaciones que simplemente funcionan sin que el usuario configure tokens. Telegram ya está en modo "official" con instance pairing. WhatsApp y email todavía dependen de paneles embebidos con sesión del usuario — no son servicios, son automatización local.

    1 de 3
  4. Remote mobile

    patapim.ai/remote existe en producción. Falta endurecer la conexión phone → instancia local (TURN si hace falta para NAT traversal), gating por licencia, y onboarding claro.

    Existe, no gated
  5. Auto-update verificado

    R2 (patapim-releases) + endpoints en patapim.ai/api/download + Gist con patapim-version.json. Funciona para dev installs; falta verificación de firma una vez que los binarios estén firmados.

    Operativo
Tener "el paid layer cerrado" es poder mandarle el link de descarga
a un desconocido y que pague sin que vos hagas nada.

Estrategia en cuatro fases

El orden no es arbitrario: cada fase desbloquea la siguiente. Saltarse una rompe la cadena.

  1. Fase 1 · Cerrar lo que ya casi está (3–4 semanas)

    Finalizar el Certificate Profile en Azure linkeado a Eggscape. Configurar Apple Developer ID + notarización para Mac. Validar el flujo Stripe end-to-end con un usuario real. Wirear el license gating en el main process: qué features piden licencia válida, cómo se valida offline (signed JWT), cómo se invalida.

  2. Fase 2 · Construir los relays que faltan (3–4 semanas)

    WhatsApp managed: WhatsApp Cloud API o un proveedor (Twilio, MessageBird) detrás de patapim.ai/notify/wa. Email managed: Resend o Postmark detrás de patapim.ai/notify/mail. Mantener el modo "BYO" (panel embebido) para Free tier; el modo gestionado va detrás de licencia.

  3. Fase 3 · Remote en producción real (2 semanas)

    Endurecer patapim.ai/remote: TURN si hace falta, autenticación por token de licencia, rate-limiting, logs. Onboarding desde el celu: QR pairing con la instancia local. Gating por licencia.

  4. Fase 4 · Distribución y onboarding (2 semanas)

    Polish a download.astro: detección de OS, instructivo claro, mostrar el certificado de firma. Trial de 14 días al primer instalar (sin pedir tarjeta). Flujo de "te queda 1 día" → upgrade. Página de pricing pública.

Total razonable: 10 a 12 semanas de trabajo real, con foco. Si te dispersás, son 6 meses.

Pricing propuesto

Tres tiers que mapean al schema que ya está declarado en el sitio ($0 / $6.99 / $29.99) — no inventar nuevos precios:

Free
$0
Para devs que quieren autohostear y traen su propia infra.
  • Source build (MIT)
  • Bring your own API key
  • Telegram con bot propio
  • WhatsApp / email vía panel embebido
  • Binario firmado
  • Auto-update verificado
  • Remote mobile
  • Soporte
Studio
$29.99 /mes
Equipos chicos y power users.
  • Todo lo de Pro
  • Múltiples seats / dispositivos
  • Workspaces compartidos
  • Priority support
  • Acceso anticipado a features

— Precios coherentes con el schema.org ya declarado en BaseLayout.astro —

VIII Plan concreto

El orden importa.

Open core funciona solo si el paid layer está estable antes de abrir. Abrirlo antes es regalar el producto.

  1. Ahora · Cerrar el paid layer (ver §VII)

    Las cuatro fases descritas en la sección anterior: code signing, licencias, relays gestionados, remote, distribución. 10–12 semanas con foco. Sin esto, cualquier movimiento OSS es prematuro.

  2. Después · Blindar la marca y el posicionamiento (lección OpenClaw)

    Asegurar handles (npm, GitHub org, X, Discord), redactar gobernanza en el README, preparar CLA. Y definir el posicionamiento contra OpenClaw: desktop IDE comercial, no otro asistente OSS chat-first. Antes de abrir, no después.

  3. Recién entonces · Abrir el código del IDE

    Sacar src/renderer/, src/main/ y src/mcp/ a un repo público bajo MIT. README claro: app OSS + servicios alojados pagos en patapim.ai.

  4. Pricing tentativo

    Free · self-hosted, traés tu API key, sin relays. Pro $X/mes · binario firmado + relays + remote + auto-update.

Verdict

Abrir el código antes de tener
el paid layer estable es regalar el producto.
Abrirlo después es marketing gratis
con monetización intacta.

— Memo · Abril 2026 —