@appss · artículos

← Volver a artículos

Marco estratégico

Fragmentación del grafo social

Investor / advisor · 2026-05-10

En 2026, el social graph está dividido entre los messengers y las consumer apps independientes no pueden reconstruirlo. Esta es la razón estructural por la que @appss opera con un enfoque cross-ecosystem-as-default en lugar de construir un nuevo graph desde cero, y por qué nuestros productos viven dentro del graph de otros, sin intentar reemplazarlo nunca.

Esto es una limitación, no un problema. La mayoría de las tesis de consumer apps en etapa temprana fallan de la misma manera: asumen que pueden construir un social graph desde cero. No pueden hacerlo en 2026, y el fracaso es estructural. Nuestra doctrina cross-ecosystem completa es lo que se hace una vez que se acepta esto.

La limitación

Tres fuerzas se combinan:

  1. Los users no instalan nuevas apps. El costo de instalar una nueva app versus abrir algo dentro de un messenger que ya usan es lo suficientemente alto como para que el LTV/CAC del lado del consumer casi nunca sostenga productos de discovery independientes. App Store / Play Store están saturadas con inventory de baja calidad, y el discovery en cualquiera de ellas está roto.
  2. Los users no completan los onboarding quizzes. En una era donde cada personal AI afirma conocerte ya (ChatGPT recuerda tus chats, etc.), los consumers no están dispuestos a enseñar a un producto completamente nuevo sobre sí mismos desde cero. Los cold-start data son el precio de entrada, y el precio sigue subiendo.
  3. Los users no publican content en un nuevo system pequeño. Las reviews, check-ins, posts permanecen donde está la audience, Instagram, Telegram, native messengers, no en un nuevo product que los invitó.

En conjunto: el social graph y la user-context layer están divididos entre messengers y superapps, sin un lugar neutral para consolidarlos. Una consumer app standalone que depende de las social-graph features está librando una batalla que nadie ganó en los últimos cinco años.

Evidencia

El primer project de Mark, Placenger (hace 10 años)

Abre placenger.com, toma tu location, convierte los places cercanos en chats al estilo messenger, cada photo / post sobre ese place se convierte en un «message» de un stranger. Fuerte wow en la primera apertura. Real engagement en la primera session.

Por qué murió: los users no publicaban regularmente en el system. Su social graph permaneció en platforms externas, no tenían razón para migrate la activity. Diez años después, el mismo shape de product sigue fallando por la misma razón.

Un thought experiment de 2026 de una llamada reciente con un advisor

Mark y un friend estaban sketching «un Glovo para places recomendados por friends», quiero follow el restaurant taste de Gleb, get notified cuando él chimes in:

  • Google Places tiene el inventory y las reviews. Pero no hay una social graph layer encima, y añadir friends por email es una friction que nadie overcomes.
  • En Praga, los migrants están en Telegram, los locals en WhatsApp, las regular reviews están en Instagram, no hay un neutral place que contenga el relevant social graph.
  • La standalone option requeriría building «el giant system al que todos se onboardean», ese es el graveyard.

Por eso las mini-app surfaces, Telegram, TikTok Minis (post-divestment), Discord Activities, LINE, son la rising shape. Parafrasean la constraint: don't make me install; I'm already here.

Implicaciones para @appss

Cross-ecosystem-as-default

No construimos «la app de @appss a la que vienen los users». Vamos donde el social graph ya está:

  • Telegram (home). Live, profundo.
  • TikTok Minis (post-divestment, 1.9B MAU), candidato Tier 2.
  • Discord Activities, Tier 2.
  • LINE Taiwan / Thailand, Tier 3, year-2.
  • World, WeChat, Douyin, long-bets.

En cada ecosystem, somos guests. El social graph no es nuestro, no pretendemos que pueda llegar a serlo. Nos superponemos.

Doctrina completa de multi-ecosystem en where to play next.

Apps Pro es creator-tool, no consumer-app

Esto es en parte por qué el two-product framing funciona: vendemos a creators (ya motivados para build, ya pagando por tools), ellos ship consumer apps que viven dentro de existing graphs (Telegram Mini App, Discord Activity, etc.). Nunca somos dueños del consumer acquisition moat. Creator + native viral mechanics de la host platform lo posee. CAC de un creator >>> LTV de un creator. El Model converge.

Cada consumer-touchpoint debe vivir dentro de un existing graph

  • @appss Mini App en Telegram ✓
  • Apps Pro Bot en Telegram ✓
  • ¿Una standalone iOS / Android app para creators? No, nunca. Los creators trabajan vía web + Telegram. Suficiente.

Patrón en nuestras AI features: parsear el existing graph, no construir uno nuevo

Dondequiera que el product necesite user context (Market Research AI personaliza, Designer Studio toma brand cues, Builder lee existing repo), el principle es derivar de lo que existe, no requerir nuevo input. El product se degrada a una generic alternative si no hay graph signal disponible, el product no se niega a funcionar, pero no pretende ser social-graph-as-data cuando no lo hay.

Apps Pro Bot es un live example

No es un separate place al que van los creators. En su existing TG. Reenviar una respuesta de Market-Research de un creator a otro lleva un footer (Research powered by Apps Pro), viral mechanic construido encima del graph ya existente entre esos dos TG users. No somos dueños del graph. Lo aprovechamos.

Tensiones

  • Parte de nuestro pitch es data moat (121 production tables en 2 años). Ese es nuestro internal analytics graph de creators y end-users, internal data ≠ external social graph. Línea tentadora de difuminar, importante mantenerla separada.
  • La expansión cross-ecosystem no es trivial por ecosystem. Engineering, partnerships, capital costs varían drásticamente. La doctrine es correcta; el entry-cost model tiene que ser honesto por caso (ver multi-ecosystem).
  • No somos Pavel Durov. No hay un monopoly distribution channel. Cualquier consumer-discovery feature en @appss solo funciona si parasita el native discovery en la host platform (Telegram What's New, Stars-trending, TikTok For You, etc.).

Preguntas abiertas

  • ¿Qué mechanics de «parse the existing graph» son legales y duraderas en cada target platform? Instagram cerró su API; Telegram está en gran parte abierto; Google Places tiene ToS constraints.
  • ¿Dónde está la línea entre «riding someone else's graph» y «building our own creator-graph»? Apps Pro Academy / leaderboards / community, ¿en qué punto son esos «nuestro graph»? ¿Qué tan durable sería sin external anchors?
  • ¿Qué cambia con la on-device personal AI (iOS 26 / Android equivalent)? Si cada user tiene un agent que ya conoce su graph de todas las sources, ¿nuestra parsing layer sigue importando?

Leer a continuación

  • Where to play next, la cross-ecosystem doctrine que se deriva de esta limitación.
  • Why now, Mini Apps como la respuesta estructural del market a la App Store fatigue.
  • Positioning, two-product framing en parte forzado por esta limitación.

Para una diligence más profunda sobre el entry-cost model específico de la platform, envía un email a mark@engagelabs.org.