Internal · Let's build!

Producto probado · en miniatura · ahora mismo

MyPublicGPT
minimum viable NOW!

Podemos montar el flow completo de MyPublicGPT — desde el prompt a Gemini hasta el libro descargable — con lo que ya tenemos. Basado en estudio práctico, con artefactos reales y código funcionando.

Contenido

1
¿Por qué Gemini 2.5 Flash?
Tier 1 · Los tokens no crecen en los árboles · Presupuesto cerrado con Spend Caps
2
El prompt y el Worker
API key encriptada en Cloudflare Workers · JSON estructurado
3
El JSON de vuelta
Schema · peso · coste · orientado a conversión
4
Sacando chispas: el Playbook
Fragmentación · libro descargable client-side
5
Delivery: JSON en KV, libros on demand
Por qué no zero-server · Cloudflare KV · coste real

Decisión de modelo

¿Por qué Gemini
y no ChatGPT?

Este fue el criterio: se trataba de encontrar un modelo asequible que genere JSON estructurado con calidad suficiente para orientar el resultado a ventas, con grounding en búsqueda real y con una capa de hosting que proteja la API key. Gemini 2.5 Flash gana por coste y por integración nativa con Google Search.

A
Google AI Studio · Tier 1
Tier gratuito: error
Cloudflare Workers es infraestructura compartida. En tier gratuito, las IPs de Cloudflare colisionan en rate limit y devuelven 503 de forma sistemática — sin workaround posible. En Tier 1, Google evalúa solo la API Key. El error desaparece.
B
Sistema de prepago
Prepago 10€
Se deposita una cantidad inicial desde la que se descuenta el consumo real. Sin suscripción ni facturación inesperada al final de mes.
C
Spend Cap · control de gasto
Spend Caps: si se acaba, no hay más
Al alcanzar el presupuesto mensual, la API devuelve 429 — manejado en el Worker como aviso de mantenimiento. Decisión ejecutiva: aprobar fondos o esperar fin de mes. Sin facturas inesperadas.
429 recibidoalerta ejecutiva
   ├── Aprobar fondos → feature activa
   └── Esperar fin de mes → aviso de mantenimiento
D
Escalabilidad
El presupuesto sigue al producto
El Spend Cap se ajusta en cualquier momento. El coste crece con el uso real — ideal para una startup que necesita control sin fricción operativa.

Capa de seguridad + prompt

El Worker de
Cloudflare

El frontend nunca toca la API key de Google. El Worker actúa de proxy: valida CORS, inyecta la key desde los secrets encriptados de CF, y reenvía el prompt a Gemini. También sanitiza la respuesta — a veces Gemini devuelve JSON envuelto en markdown fences; el Worker lo limpia antes de enviarlo al cliente.

1

Frontend · CF Pages

POST con {nombre}

El simulador recoge el nombre del perfil y hace un fetch() al Worker. Sin API key en el cliente. Sin CORS problem porque el origen está en whitelist.

mpi-simulator.html
2

Cloudflare Worker · Edge · Tier 1

Proxy + inyección de key

GEMINI_API_KEY vive encriptada en CF Secrets. El Worker construye el payload: prompt de sistema, nombre del perfil, y response_mime_type: "application/json" para forzar JSON limpio. Desplegado en Tier 1 para SLA del 100% e IP aislada por API Key.

3

Gemini 2.5 Flash · Google AI

Grounding real en Google Search

Gemini ejecuta búsquedas en tiempo real antes de generar la respuesta. El perfil se analiza con datos actuales, no con entrenamiento estático. Grounding disponible en Tier 1 — en tier gratuito producía timeouts por IPs compartidas.

Response · sanitizado

JSON estructurado entregado

El Worker hace strip de posibles fences de markdown (```json ... ```), parsea el JSON y lo devuelve al frontend como application/json limpio.

Schema · output de Gemini

El JSON
de vuelta

Un informe pesa ~2 KB. El schema tiene cinco bloques de contenido más una conclusión y un epíteto de 2–4 palabras que condensa la identidad digital del perfil. Cada bloque está orientado a mostrar el valor del servicio y a abrir la conversación de venta.

response.json · schema v2

{
  "titular": {
    "nombre":  "Cayetana Guillén Cuervo",
    "epiteto": "Presencia sólida · culturalmente arraigada",  // 2-4 palabras
    "titulares": [ "...", "...", "..." ]    // 5 frases
  },
  "narrativa": {
    "frases": [ "...", "..." ],              // narrativa pública
    "identidad": "Presencia coherente en..."         // resumen de identidad
  },
  "senales": [                                      // riesgos detectados
    { "n": 1, "texto": "Entrevistas antiguas..." }
  ],
  "identidad": {
    "plataformas": [ "Instagram", "X", "RTVE" ],
    "coherencia": "Alta"
  },
  "oportunidades": [                               // gancho de venta
    { "n": 1, "texto": "Unificar biografías..." }
  ],
  "conclusion": "Huella sólida y coherente..."
}
Peso
~2 KB
Por informe · 100× más ligero que el HTML renderizado
Bloques
5 + 2
5 bloques de contenido + conclusion + epiteto

Del texto al libro

Sacando chispas:
el Playbook

El JSON contiene texto estructurado. Con un fragmentador JS que mapea cada campo a un slot de layout, podemos renderizar ese mismo texto como un documento editorial con tipografía, jerarquía y color — y entregarlo como PDF descargable. Dos artefactos de wireframe documentan cómo se llegó a esto.

Válido para cualquier perfil

El prompt está diseñado para funcionar igual con una figura pública conocida que con una persona anónima. En ambos casos, el modelo identifica lo que hay en Internet sobre ese nombre y lo estructura hacia lo que importa en cada situación — sea visibilidad mediática o presencia fragmentada — orientando siempre el resultado a conversión hacia los servicios a medida de MyPublicInbox.
Playfair Display Lato · Nunito base64 @font-face --acento variable 5 colores corporativos standalone · sin deps

Arquitectura de almacenaje

Delivery: JSON en KV,
libros on demand

No queremos hostear las creaciones de los usuarios — demasiado peso, demasiada gestión. Pero el usuario tiene que percibir que "sus libros están ahí". La solución: almacenar solo el JSON (~2 KB por informe) y renderizar el libro client-side on demand cuando el usuario hace click.

"Para el usuario, los libros existen. Para nosotros, solo guardamos un JSON."

Zero-server (localStorage)

Datos ligados al navegador y dispositivo
Borrar caché = perder todos los libros
Sin acceso desde móvil si generaste en desktop
IndexedDB tampoco: misma limitación

Cloudflare Workers KV

JSON accesible desde cualquier dispositivo
Inmune a limpiezas de caché del navegador
~2 KB por entrada · prácticamente gratis
Escala a R2 si algún día queremos binarios

Por qué esta arquitectura escala

Stateless by design
El Worker no guarda estado. Cada llamada es independiente: recibe un nombre, devuelve un JSON. Sin sesiones, sin memoria, sin superficie de ataque.
JSON como unidad mínima
Cada informe es un objeto de ~2 KB. Fácil de leer, fácil de versionar, fácil de migrar. KV almacena miles sin sudar. Si el schema evoluciona, los JSON antiguos siguen siendo válidos.
Render client-side
El libro nunca se almacena. Se genera en el navegador del usuario en el momento del click, con el mismo HTML que ya tenemos. El servidor solo entrega datos; el cliente hace el trabajo de presentación.

UX flow · desde el punto de vista del usuario alpha

// El usuario ve su "biblioteca"
[
  { "fecha": "2026-06-02", "icono": "📄", "epiteto": "Presencia sólida..." },
  { "fecha": "2026-05-26", "icono": "📄", "epiteto": "Narrativa en construcción" }
]
// Al hacer click → fetch del JSON desde KV → render client-side → window.open() → PDF
// Sin thumbnail · sin almacenar el HTML · el libro se genera cada vez en décimas de segundo

Todo lo que se necesita para lanzar MyPublicGPT como feature existe y funciona. Lo he probado en miniatura, paso a paso, con artefactos que se pueden ver, probar y enlazar.

Siguiente paso: conectar las piezas en producción. Worker Tier 1 con KV. Sidebar de biblioteca en el perfil del usuario. Render on demand al click. Feature limitada a alpha/alpha-pro. Un JSON de 2 KB por semana por usuario. Coste: desde 1€/mes para 50 usuarios. Sin sorpresas, con Spend Caps de Google AI Studio.

CF Pages ✓ CF Workers Tier 1 ✓ Gemini 2.5 Flash ✓ JSON schema v2 ✓ Playbook CSS print ✓ CF Workers KV → pendiente Biblioteca de usuario → pendiente