Nivel 3 · Avanzado

Curso IA avanzado

Agentes, APIs y construcción de producto con IA

Si ya manejas IA con soltura, comparas modelos y has tocado automatización, este curso te lleva al territorio de agentes, APIs propias, programación con IA y construcción de servicios o productos monetizables.

Empezar el curso
Lo que aprenderás
GitHub Copilot Cursor Claude Code Git diff visual OpenAI Platform Anthropic Console OpenAI Python SDK OpenAI Node SDK OpenAI function calling docs OpenAI Prompt Caching n8n self-host docs Hetzner Cloud
Resultado final

Construir un producto IA real: agente, RAG o SaaS funcional con APIs de OpenAI y Anthropic.

Módulos y lecciones

01

Programar con IA · Cursor, Copilot y Claude Code

Por empezar

Los tres asistentes en el IDE en 2026.

4 lecciones 20 min 40 XP
0 / 4 completadas
1.1
GitHub Copilot · autocompletado y agentes El estándar de facto. Sus puntos fuertes y débiles.
5 min Completada

Copilot es la extensión más usada para autocompletado en IDE. En 2026 ha añadido modo agente y chat lateral. Su valor:

  • Autocompletado fluido mientras tecleas.
  • Integración nativa con GitHub (Issues, PRs).
  • Modo Workspace para refactor multi-archivo.
  • Soporte para casi todos los IDEs (VS Code, JetBrains, Vim, Neovim).
Ejemplo real

Escribes "function getUserPermissions(" y Copilot sugiere los argumentos típicos basándose en el resto de tu código. Aceptas con Tab. Velocidad de codificación 1.5-2x.

GitHub Copilot 10 USD/mes individual.
Comentario que dispara código
// Función que toma un array de usuarios, filtra por activos del último mes, devuelve top 5 por uso
Ejercicio

Si no lo usas, prueba Copilot 1 semana en tu proyecto actual. Mide líneas/hora.

Resultado esperado

Decidir si Copilot encaja o prefieres Cursor.

  • Aceptar sugerencias sin leer: bugs sutiles.
  • No usar el modo chat: ahí está mucho del valor reciente.
1.2
Cursor AI · refactor multi-archivo IDE basado en VS Code con indexación completa del repo.
5 min Completada

Cursor indexa todo tu repositorio. Esto le permite sugerencias contextuales muy superiores a Copilot en proyectos medios-grandes. Comandos clave:

  • Cmd+K: editar archivo actual con instrucciones.
  • Cmd+L: chat con contexto del proyecto.
  • Cmd+I: agente que tocaria varios archivos.
  • @codebase: referencia todo el repo en el chat.
Ejemplo real

Pides: «Renombra la función getUserData a fetchUserProfile en todo el repo y actualiza los imports». Cursor agente lista los 27 archivos afectados, propone diff, tú apruebas.

Cursor 20 USD/mes Pro. Free tier limitado.
Refactor seguro
Renombra {{X}} a {{Y}} en todo el repo. Actualiza tests. Lista los archivos afectados antes de aplicar.
Ejercicio

Si vienes de VS Code, importa configuración a Cursor. Prueba 1 semana. Mide refactors hechos.

Resultado esperado

Decidir si Cursor reemplaza tu IDE o Copilot.

  • No usar @codebase en el chat: pierdes mucho contexto.
  • Aceptar cambios sin revisar diff.
1.3
Claude Code · CLI y agentes con acceso a filesystem La opción más nueva. Distinta filosofía.
5 min Completada

Claude Code funciona desde terminal con acceso a tu sistema de archivos. No es un IDE: es un agente. Modo de trabajo:

  • Lo lanzas en una carpeta de proyecto.
  • Le pides una tarea en lenguaje natural.
  • Lee archivos, ejecuta comandos, propone cambios con diff.
  • Tú apruebas o rechazas cada acción.
Ejemplo real

Lanzas claude-code en tu repo. «Encuentra el bug por el que el endpoint /login falla con email vacío. Pruébalo. Arréglalo con test.» Claude lee, prueba, propone fix, ejecuta test, confirma.

Claude Code Incluido en Claude Pro.
Debug autónomo
Bug: {{descripción}}. Empieza por replicarlo. Después propón fix con test. NO modifiques nada antes de tener test reproductor.
Ejercicio

Instálalo. Aplícalo a un bug real tuyo. Mide tiempo vs hacerlo manual.

Resultado esperado

Saber si Claude Code encaja en tu flujo de trabajo.

  • Dejarlo correr sin supervisar: puede tocar archivos críticos.
  • No usar test antes de modificar: arreglos sin verificar.
1.4
Errores típicos: aceptar sin leer, secretos en chat, no revisar diff Los 3 fallos que cometemos todos.
5 min Completada

Lo que más rompe en producción:

  1. Aceptar autocompletado sin leer: el código compila pero tiene bugs sutiles.
  2. Pegar secretos en el chat: API keys, tokens, datos personales. NUNCA. Usa .env y referencia.
  3. No revisar diff multi-archivo: aceptas 30 cambios y rompes algo lejano.
  4. No tener test antes de refactorizar: el refactor te pasa por encima sin que lo notes.
Ejemplo real

Aceptas un cambio de Cursor en 8 archivos sin revisar el diff. Compila. Tests pasan. En producción: error sutil en archivo 6 porque la IA cambió un parámetro que también afecta a una API externa.

Git diff visual Vital para revisar cambios.
Revisión propia antes de aceptar
Antes de proponer el cambio, lista:
- Qué archivos modificas
- Qué efectos colaterales podrían haber
- Tests que se necesitan ejecutar
- Riesgos en producción
Ejercicio

Revisa tu workflow de coding con IA. Identifica dónde aceptas sin leer.

Resultado esperado

Disciplina: leer antes de aceptar.

  • Confiar ciegamente en la IA por velocidad.
02

APIs de OpenAI y Anthropic

Por empezar

Llamadas desde tu propio código.

4 lecciones 20 min 40 XP
0 / 4 completadas
2.1
Setup de cuenta, billing y rate limits Antes de pegar la primera llamada, configura bien.
5 min Completada

Lo mínimo viable antes de la primera línea de código:

  1. Cuenta en platform.openai.com (o console.anthropic.com).
  2. API key generada en Settings → API Keys. Nunca la pegues en código.
  3. Billing: añade método de pago, establece límite mensual.
  4. Revisa rate limits: requests/min y tokens/min por modelo.
  5. Guarda la key en variable de entorno (.env).
Ejemplo real

API key generada → guardada en .env como OPENAI_API_KEY → en código usas os.environ["OPENAI_API_KEY"] o process.env.OPENAI_API_KEY. NUNCA en el código fuente.

OpenAI Platform Dashboard de API.
Anthropic Console Equivalente para Claude.
Setup checklist
Voy a empezar con la API de {{OpenAI/Anthropic}}. Genera mi checklist de setup: cuenta, billing, key, rate limits, .env. Incluye comando exacto para crear .env.
Ejercicio

Completa el setup. Verifica que la primera llamada funciona desde un archivo de prueba.

Resultado esperado

Entorno listo y seguro.

  • Pegar key en código y subirlo a Git: filtración pública.
  • No poner límite de billing: facturas inesperadas.
2.2
Llamadas básicas en Python y Node El hello-world de las APIs LLM.
5 min Completada

Llamada mínima en Python:

from openai import OpenAI\nclient = OpenAI()\nresp = client.chat.completions.create(\n  model="gpt-4o",\n  messages=[{"role":"user","content":"Hola"}]\n)\nprint(resp.choices[0].message.content)

Llamada mínima en Node:

import OpenAI from "openai";\nconst client = new OpenAI();\nconst resp = await client.chat.completions.create({\n  model: "gpt-4o",\n  messages: [{role:"user", content:"Hola"}]\n});\nconsole.log(resp.choices[0].message.content);
Ejemplo real

En 5 líneas tienes una respuesta de GPT en tu app. A partir de aquí se construye todo.

OpenAI Python SDK pip install openai
OpenAI Node SDK npm install openai
Mi primer endpoint
Crea un endpoint Express/Flask que reciba {body: prompt} y devuelva la respuesta de GPT-4o. Incluye manejo de errores básico.
Ejercicio

Monta un script que llame a la API y devuelva la respuesta. Sin frameworks. Solo SDK + .env.

Resultado esperado

Primera llamada funcionando en menos de 30 minutos.

  • Hardcodear el modelo: parametrízalo desde el inicio.
  • No manejar errores: las APIs fallan, ratea, timeoutean.
2.3
Streaming, function calling y structured outputs Las 3 features que separan apps básicas de apps reales.
5 min Completada

Streaming: la respuesta llega token a token. Ideal para chats con feedback en tiempo real.

const stream = await client.chat.completions.create({\n  model:"gpt-4o", messages:[...], stream:true\n});\nfor await (const chunk of stream) {\n  process.stdout.write(chunk.choices[0]?.delta?.content || "");\n}

Function calling: el modelo devuelve estructurado el nombre de la función a invocar y sus argumentos. Permite que el LLM "decida" qué herramienta usar.

Structured outputs: fuerzas que el modelo devuelva JSON conforme a un schema. Cero ambigüedad.

Ejemplo real

App de soporte: el LLM con function calling decide si llamar a getTicketStatus(id) o createNewTicket(data). El usuario habla en natural. La app actúa por debajo.

Function schema
Define el JSON schema para una función {{nombre}} que recibe {{params}} y devuelve {{return}}. Usa formato OpenAI function calling estricto.
Ejercicio

Implementa una app simple con function calling: pregunta del usuario → LLM decide → llama función → devuelve respuesta.

Resultado esperado

Construir asistentes que actúan, no solo conversan.

  • No validar el JSON devuelto antes de ejecutar la función.
2.4
Caching de prompts y reducción de costes Cuando tu app escala, la factura puede dispararse.
5 min Completada

Estrategias para reducir coste de API:

  1. Prompt caching: OpenAI y Anthropic ofrecen caché para prompts largos repetidos (system prompts, RAG context).
  2. Modelo más pequeño: GPT-4o mini o Claude Haiku para tareas simples; reserva GPT-5/Opus para complejas.
  3. Truncar contexto: solo envía lo relevante, no toda la historia de conversación.
  4. Embeddings + RAG: en vez de meter todo el documento en el prompt, busca semánticamente solo lo relevante.
Ejemplo real

App de soporte con 1.000 consultas/día. Antes: 200€/mes con GPT-4o. Después de optimizar (mini + caching + RAG): 30€/mes. Misma calidad.

Análisis de coste
Mi app llama a {{modelo}} con {{N}}/día. Tamaño promedio prompt/respuesta: {{tokens}}. Sugiere optimizaciones para reducir coste sin perder calidad notable.
Ejercicio

Audita el coste actual de tu app. Aplica una optimización. Mide impacto.

Resultado esperado

Apps económicamente sostenibles.

  • Optimizar antes de medir: a veces el coste real es bajo.
03

n8n avanzado · agentes y producción

Por empezar

De Make básico a n8n self-hosted con agentes.

4 lecciones 20 min 40 XP
0 / 4 completadas
3.1
Self-host de n8n: Docker, persistencia, backups Producción real, no plan cloud gratis.
5 min Completada

Setup mínimo de n8n self-hosted:

  1. VPS pequeña (5-10€/mes en Hetzner o DigitalOcean).
  2. Docker compose con n8n + Postgres + Caddy/Traefik para HTTPS.
  3. Volúmenes persistentes para no perder workflows.
  4. Cron de backup diario de la DB.
  5. Dominio propio con SSL.
Ejemplo real

docker-compose.yml con 3 servicios. 1 hora de setup. Coste 6€/mes. Workflows ilimitados. Privacidad total.

Hetzner Cloud VPS baratos en Europa.
docker-compose para n8n
Genera docker-compose.yml para n8n + Postgres con persistencia, Caddy para HTTPS, dominio {{dominio}}, n8n basic auth con user {{user}}.
Ejercicio

Monta n8n self-hosted en una VPS. Importa un workflow existente.

Resultado esperado

n8n corriendo en tu dominio con HTTPS.

  • Olvidar volúmenes: pierdes workflows al reiniciar.
  • No hacer backup: un crash y empiezas de cero.
3.2
AI Agent node y conexión con LLMs El nodo que cambia n8n vs Make.
5 min Completada

n8n incluye un nodo "AI Agent" basado en LangChain. Diferencias clave con un nodo OpenAI tradicional:

  • Tools: puedes conectar herramientas (HTTP, DB, vector store) que el agente decide cuándo usar.
  • Memoria: agente recuerda conversaciones previas.
  • Razonamiento: planifica antes de actuar.
Ejemplo real

Agente de soporte: recibe consulta del cliente. Tools: buscar en KB (vector store), consultar estado de pedido (DB), escalar a humano (Slack). El agente decide qué tools usar según la pregunta.

System prompt de agente
Eres agente de {{rol}}. Herramientas disponibles:
- {{tool1}}: usar cuando {{cuándo}}
- {{tool2}}: usar cuando {{cuándo}}

Reglas: si no estás seguro, escala a humano. Si la respuesta excede {{X}} palabras, resúmela.
Ejercicio

Monta un agente simple con 2 tools en n8n. Pruébalo con 5 inputs distintos.

Resultado esperado

Agente funcional con razonamiento básico.

  • Dar al agente 10 tools: se confunde. Empieza con 2-3.
  • System prompt vago: malos resultados.
3.3
Memoria conversacional y vector stores Para agentes con contexto persistente.
5 min Completada

Dos tipos de memoria:

  • Memoria conversacional: agente recuerda turnos anteriores en la misma sesión.
  • Memoria a largo plazo: vector store con embeddings de conversaciones previas o documentos.

n8n soporta ambos. Vector stores soportados: Pinecone, Qdrant, Postgres+pgvector, Supabase.

Ejemplo real

Agente de coaching: cada conversación con un usuario se vectoriza y guarda. Cuando vuelve, el agente recupera contexto previo y responde con continuidad.

Postgres + pgvector Opción simple si ya usas Postgres.
Qdrant Cloud Free tier generoso.
Ejercicio

Añade memoria persistente a tu agente. Verifica que recupera contexto.

Resultado esperado

Agentes con personalidad consistente.

  • Recuperar demasiada memoria: contamina la respuesta.
3.4
Webhooks, error handling y observabilidad Producción real exige monitorización.
5 min Completada

En producción necesitas:

  1. Webhooks bien configurados: con autenticación, validación de payload.
  2. Error handling explícito: cada nodo crítico con rama de error que notifica (Slack/Telegram).
  3. Logs estructurados: registra cada ejecución crítica en una DB para auditoría.
  4. Métricas: éxito/error, latencia, coste por ejecución.
Ejemplo real

Workflow procesa pagos. Si falla un módulo: 1) reintento automático, 2) si sigue fallando, log en Postgres + notificación Telegram + email al equipo. Cero pagos perdidos sin enterarte.

Ejercicio

Añade error handling y notificación a un workflow crítico tuyo.

Resultado esperado

Producción robusta.

  • Sin observabilidad: los fallos te enteras cuando es tarde.
04

Agentes IA en producción

Por empezar

Construir agentes que funcionan más allá del demo.

4 lecciones 20 min 40 XP
0 / 4 completadas
4.1
Diseño: objetivo, herramientas acotadas, guardrails El 80% del éxito está en el diseño previo.
5 min Completada

Reglas para diseñar agente que funcione:

  1. Objetivo único y medible: «atender consultas de soporte nivel 1». NO «ser un asistente útil».
  2. 3-5 herramientas: más es peor. Si necesitas 10, parte el agente en sub-agentes.
  3. Guardrails explícitos: qué NO puede hacer (modificar DB, enviar emails, ejecutar código).
  4. Escalada a humano: condiciones claras para devolver el control.
Ejemplo real

Agente bien diseñado: «Responder FAQs y crear tickets nuevos. Tools: searchKB, createTicket, escalateToHuman. NO puede modificar tickets existentes ni acceder a datos de pago.»

Diseño de agente
Diseña agente para {{objetivo}}.
1) Objetivo único en 1 frase
2) Top 3-5 herramientas necesarias
3) Guardrails: qué NO debe hacer
4) Cuándo escalar a humano
5) Métrica de éxito
Ejercicio

Diseña un agente para un problema real. Defínelo en 1 página antes de tocar código.

Resultado esperado

Agente diseñado, no improvisado.

  • Objetivo demasiado amplio: agente impredecible.
4.2
Frameworks: LangChain, AutoGen, custom Qué elegir según tu caso.
5 min Completada
  • LangChain: el más usado. Mucha integración. A veces verboso.
  • AutoGen (Microsoft): bueno para multi-agente.
  • Custom (sin framework): para producción seria, muchos eligen escribir el agente desde cero con SDK oficial + estado en DB.
Ejemplo real

Para prototipo rápido: LangChain. Para SaaS en producción a 1.000 usuarios: custom con SDK + Postgres. La razón: control total sobre el comportamiento.

Ejercicio

Construye el mismo agente simple con 2 enfoques: LangChain vs SDK directo. Compara código y resultado.

Resultado esperado

Saber elegir según el proyecto.

  • Sobreingeniería: framework gigante para prototipo simple.
4.3
Evaluación automática y human-in-the-loop Sin evaluación, no sabes si tu agente funciona.
5 min Completada

Patrones de evaluación:

  • Conjunto de test: 20-50 casos con respuesta esperada. Ejecuta el agente en cada caso, compara.
  • LLM-as-judge: usa otro LLM (más fuerte) para evaluar la calidad de la respuesta del agente.
  • Human-in-the-loop: acciones críticas requieren aprobación humana antes de ejecutarse.
Ejemplo real

Agente que crea tickets de soporte. Antes de crear: pasa el ticket por una validación con GPT-5 que decide si es razonable. Si no, escala a humano. Reduce errores 80%.

LangSmith Plataforma de evaluación.
LLM-as-judge
Evalúa la respuesta del agente.
Pregunta original: {{q}}
Respuesta del agente: {{r}}
Respuesta ideal (referencia): {{ref}}

Puntúa 0-10 en: precisión, claridad, completitud. Justifica.
Ejercicio

Crea un test set de 10 casos para tu agente. Ejecuta. Mide tasa de éxito.

Resultado esperado

Métricas reales del rendimiento del agente.

  • Lanzar a producción sin evaluación: bombas de tiempo.
4.4
Casos viables hoy vs hype No todo lo que vende como agente funciona.
5 min Completada

Casos donde agentes funcionan bien en 2026:

  • Soporte nivel 1 con KB acotada.
  • Clasificación y enriquecimiento de datos.
  • Coordinación de flujos sencillos.
  • Asistencia a usuarios con tools muy específicas.

Donde aún fallan:

  • Decisiones autónomas con muchas variables.
  • Tareas que requieren contexto físico/visual real.
  • Trabajo creativo de calidad profesional sin supervisión.
  • Cualquier dominio donde error = consecuencia grave.
Ejemplo real

Funciona: agente que clasifica 10k tickets/mes con 95% precisión. No funciona: agente que toma decisiones de inversión sin supervisión.

Ejercicio

Lista 5 ideas de agentes que te interesan. Marca cuáles son viables y cuáles son hype.

Resultado esperado

Criterio para no perder tiempo en proyectos imposibles.

  • Creer demos virales sin verificar producción real.
05

Retrieval (RAG) y bases de conocimiento

Por empezar

Llevar tu propia información dentro del modelo sin entrenar nada.

4 lecciones 20 min 40 XP
0 / 4 completadas
5.1
Embeddings: qué son y cómo se usan La pieza fundamental de RAG.
5 min Completada

Un embedding es un vector numérico que representa el significado de un texto. Textos parecidos tienen embeddings cercanos. Sirve para búsqueda semántica: encuentras "textos parecidos" aunque no compartan palabras exactas.

Ejemplo real

Embedding de «¿cómo cancelo mi suscripción?» y embedding de «quiero darme de baja» están muy cerca aunque no compartan palabras. Búsqueda léxica falla; semántica acierta.

Ejercicio

Genera embeddings de 10 frases en 2 idiomas con OpenAI text-embedding-3-small. Compara distancias.

Resultado esperado

Intuición sobre cómo funcionan los embeddings.

  • Confundir embeddings con tokens: son cosas distintas.
5.2
Vector stores: Pinecone, Weaviate, Postgres+pgvector Dónde almacenas y consultas los embeddings.
5 min Completada

Opciones por orden de simplicidad:

  1. Postgres + pgvector: si ya usas Postgres, añadir pgvector es lo más simple.
  2. Supabase: Postgres gestionado con pgvector incluido. Free tier.
  3. Qdrant: open-source, fácil self-host o cloud.
  4. Pinecone: el más popular, gestionado. Más caro.
  5. Weaviate: open-source con features avanzadas.
Ejemplo real

Proyecto pequeño con 50k documentos: pgvector. Producción con millones: Pinecone o Qdrant. La decisión depende de volumen y presupuesto.

Ejercicio

Monta un vector store local. Indexa 100 documentos. Haz búsquedas semánticas.

Resultado esperado

Vector store funcionando.

  • Elegir Pinecone para 5.000 documentos: caro innecesariamente.
5.3
Chunking eficiente y metadata Cómo partes los documentos importa tanto como el modelo.
5 min Completada

Chunking = partir documentos largos en fragmentos para indexar. Reglas:

  • Chunks de 200-500 tokens.
  • Overlap de 10-15% entre chunks (mantiene contexto).
  • Respeta secciones lógicas (no partas en medio de una frase).
  • Metadata: source, page, section. Para citar después.
Ejemplo real

Libro de 300 páginas → 1.500 chunks de 400 tokens con overlap. Cada chunk con metadata {page, chapter}. Búsqueda devuelve chunks + metadata para citar.

Ejercicio

Indexa un documento real tuyo con diferentes estrategias de chunking. Compara calidad de respuestas.

Resultado esperado

Chunking adaptado a tu caso.

  • Chunks demasiado grandes: imprecisos.
  • Chunks demasiado pequeños: pierden contexto.
5.4
Cuándo RAG no es la respuesta Casos donde fine-tuning o prompt engineering son mejores.
5 min Completada

RAG no siempre es la solución:

  • Si el conocimiento cambia muy rápido (precios diarios) → mejor consulta directa a API.
  • Si la base de conocimiento es muy pequeña (10-20 documentos) → mete todo en system prompt.
  • Si necesitas que el modelo "actúe" como tu marca → fine-tuning con tono.
  • Si la respuesta requiere razonamiento profundo más que recuperación → mejor un LLM bueno sin RAG.
Ejemplo real

Para una FAQ de 30 preguntas: meter las 30 en system prompt funciona mejor que RAG. RAG empieza a tener sentido a partir de 500+ documentos.

Ejercicio

Para tu caso de uso: ¿RAG o no? Justifica.

Resultado esperado

Criterio antes de invertir tiempo.

  • Montar RAG por moda: a veces no aporta.
06

Productos SaaS con IA

Por empezar

De idea a microservicio monetizable.

4 lecciones 20 min 40 XP
0 / 4 completadas
6.1
Validación rápida en 2 semanas Cómo saber si tu idea tiene tracción antes de construir.
5 min Completada

Pasos:

  1. Define el problema en 1 frase. Define a quién resuelve.
  2. Landing page simple con form de espera (no SaaS funcional).
  3. Tráfico mínimo: posts en LinkedIn, comunidades nicho, anuncio pequeño.
  4. Si en 2 semanas tienes 50+ signups: hay interés. Construye.
  5. Si no: pivota o descarta.
Ejemplo real

Idea: "asistente de resumen de reuniones para abogados". Landing con form. 2 semanas de tráfico via LinkedIn. 12 signups. Interés bajo. Pivota a "redactor de propuestas comerciales para freelancers". Nuevo landing. 80 signups. Construye.

Carrd Landing rápida sin código.
Tally Form gratis.
Landing copy
Genera copy para landing de SaaS:
Producto: {{producto}}
Audiencia: {{quién}}
Problema que resuelve: {{problema}}

Devuelve: headline (≤10 palabras), subheadline, 3 features con benefit, CTA.
Ejercicio

Toma una idea SaaS tuya. Monta landing + form. Lanza tráfico. Mide en 2 semanas.

Resultado esperado

Validación o pivot temprano.

  • Construir 6 meses sin validar: malgastas tiempo.
6.2
Stack típico: API LLM + DB + frontend + billing Lo mínimo para SaaS con IA en 2026.
5 min Completada

Stack viable para 1 persona:

  • Frontend: Next.js (Vercel deploy).
  • Backend: serverless functions o Node.
  • DB: Postgres en Supabase (incluye pgvector).
  • LLM: OpenAI API o Anthropic.
  • Auth: Supabase Auth o Clerk.
  • Billing: Stripe.
  • Email transaccional: Resend o Postmark.

Coste mensual con 100 usuarios: 50-100€.

Ejemplo real

SaaS de "generador de scripts para podcasts". Stack arriba. 3 semanas de build. Deploy. Cobras 9€/mes. 50 usuarios = 450€/mes. Rentable.

Ejercicio

Diseña el stack para tu idea. Lista cada servicio con su coste estimado.

Resultado esperado

Stack claro antes de empezar.

  • Sobre-ingenieria: AWS desde el día 1 cuando Vercel sobra.
6.3
Diferenciación frente a ChatGPT directo Si tu SaaS hace lo mismo que ChatGPT, perderás.
5 min Completada

Por qué alguien paga 9€ a tu SaaS pudiendo usar ChatGPT directamente:

  1. UX vertical: tu SaaS hace UNA tarea muy bien.
  2. Integraciones: ChatGPT no se conecta a su Notion / CRM / etc.
  3. Modelo entrenado/configurado: prompts y datos optimizados.
  4. Workflow específico: no chat, sino producto.
  5. Comunidad/contenido: por qué te lee el target.
Ejemplo real

SaaS para freelances que generan propuestas. ChatGPT puede hacerlo pero requiere setup. Tu SaaS: conexión Stripe, plantillas legales, exportación PDF con tu marca, integración Calendly. Vale 19€/mes para target específico.

Diferenciación honesta
Mi SaaS: {{descripción}}
Usuarios podrían usar ChatGPT directo en su lugar.

Lista 5 razones reales por las que pagarían mi SaaS en vez. Si menos de 3 son sólidas, pivota.
Ejercicio

Aplica el prompt a tu idea. Si no hay 3 razones sólidas, replantea.

Resultado esperado

Diferenciación clara o pivot temprano.

  • Wrapper genérico de OpenAI: cero diferenciación, cero clientes.
6.4
Pricing y márgenes reales en 2026 No infres precios. Calcula con datos.
5 min Completada

Modelo de pricing común:

  • Free: 5-10 usos/mes (para conversión).
  • Starter: 9-19€/mes (uso individual).
  • Pro: 29-49€/mes (uso intensivo).
  • Team: 99-199€/mes (multi-usuario).

Para calcular margen: coste API por usuario × tu uso esperado vs precio. Margen sano: 70-80% al menos.

Ejemplo real

SaaS con plan 19€/mes. Cada usuario gasta 4€/mes de API. Margen 79%. Sostenible. Si gastara 12€/mes: margen 37%. Insostenible.

Cálculo pricing
Mi SaaS: {{features}}
Coste API por usuario activo: {{coste}}
Precio que estoy considerando: {{precio}}
Mercado de referencia: {{competencia}}

Analiza: margen, posicionamiento vs competencia, optimizaciones de coste posibles.
Ejercicio

Calcula coste y margen real de tu SaaS. Si margen <70%, optimiza.

Resultado esperado

Pricing sostenible.

  • Pricing por intuición: terminas perdiendo dinero.
07

Negocio con IA · servicios y agencia

Por empezar

Cómo facturar realmente con IA: servicios, freelance, agencia.

4 lecciones 20 min 40 XP
0 / 4 completadas
7.1
8 servicios viables hoy (precios reales) No teoría: lo que se está vendiendo en 2026.
5 min Completada

Resumen de los 8 servicios cubiertos en detalle en /trabajos-con-ia/:

  1. Automatización para empresas (1.500-4.000€/proyecto).
  2. Asistencia editorial con IA (50-150€/h).
  3. Análisis de datos para no-técnicos (300-1.200€/análisis).
  4. Construcción de agentes a medida (3.000-15.000€/agente).
  5. Training y consultoría para equipos (1.000-3.000€/sesión).
  6. Newsletter o medio especializado (2.000-10.000€/mes recurrentes).
  7. Microservicios SaaS con IA (5.000-20.000€/mes).
  8. Fractional Chief of Staff con IA (800-2.000€/mes/cliente).
Ejemplo real

Eres developer senior. Servicios viables: 1 (automatización), 4 (agentes), 7 (SaaS). Otros requieren skills distintas.

Mi servicio ideal
Mi perfil: {{skills}}
Tiempo disponible: {{horas/semana}}
Red actual: {{descripción}}

De los 8 servicios IA, ¿cuáles encajan mejor con mi perfil? Top 3 con justificación.
Ejercicio

Elige un servicio. Diseña tu oferta concreta (qué entregas, precio, plazo). Documenta en 1 página.

Resultado esperado

Oferta clara para vender.

  • Elegir el más rentable sin tener skills: no consigues clientes.
7.2
Captación: red, LinkedIn, casos públicos Sin clientes no hay negocio. Sin canal no hay clientes.
5 min Completada

Vías de captación que funcionan en 2026:

  1. Red profesional: tus contactos directos son tu primer cliente. Pregúntales.
  2. LinkedIn personal: contenido 2-3 veces/semana sobre tu servicio. Casos concretos, no autobombo.
  3. Casos públicos: implementa para 1-2 amigos gratis. Documenta. Publícalo. Es tu portfolio.
  4. Comunidades nicho: aporta valor en comunidades específicas. NO spam.
  5. SEO: si tienes blog (como Nodo IA), el contenido atrae clientes durante años.
Ejemplo real

Mes 1: 5 contactos directos → 2 reuniones → 1 cliente (1.500€). Mes 2: 1 caso público en LinkedIn → 3 leads → 1 cliente (2.500€). Mes 6: SEO empieza a aportar. Crecimiento orgánico.

LinkedIn Canal principal B2B.
Plan captación 90 días
Mi servicio: {{servicio}}
Mi situación: {{actual}}

Diseña plan de captación 90 días con:
- Mes 1: red propia
- Mes 2: contenido público + casos
- Mes 3: escalado del canal que mejor funcione

Métricas semanales realistas.
Ejercicio

Diseña tu plan 90 días. Ejecuta el primer mes.

Resultado esperado

Pipeline de clientes en construcción.

  • Esperar que los clientes vengan solos.
7.3
Contratos, propuestas y procesos La parte aburrida que decide si tu negocio dura.
5 min Completada

Mínimo viable de procesos:

  1. Plantilla de propuesta: problema + solución + plazo + precio + condiciones. 1-2 páginas.
  2. Contrato simple: alcance, entregables, pagos, cláusula de cancelación. Hay plantillas online.
  3. Pagos: 50% adelantado, 50% al entregar. O suscripción mensual desde el día 1.
  4. CRM mínimo: un Notion con pipeline (Lead → Reunido → Propuesta → Cliente activo → Inactivo).
Ejemplo real

Cliente firma propuesta (1 página) por email. Paga 50% por transferencia. Empiezas. Entregas. Cobras el 50% restante. Sin papeleo innecesario.

Notion CRM ligero.
Plantilla propuesta
Genera plantilla de propuesta comercial para mi servicio {{servicio}}.
Estructura: portada, problema, solución, entregables, plazos, inversión, siguiente paso.
Máx 2 páginas. Tono profesional pero directo.
Ejercicio

Crea tu plantilla. Adáptala al primer cliente real.

Resultado esperado

Procesos básicos funcionando.

  • Sin contrato: te pueden no pagar.
7.4
Cuándo escalar a equipo y cuándo no No todos los negocios deben crecer en personas.
5 min Completada

Escalar a equipo tiene sentido cuando:

  • Tienes pipeline de clientes que no puedes atender solo.
  • El servicio es replicable (puedes documentarlo).
  • Tienes margen suficiente para pagar personal.

NO escalar cuando:

  • El servicio depende tanto de ti que no es replicable.
  • Margen estrecho.
  • Prefieres calidad de vida solo que ingresos altos con estrés.
Ejemplo real

Freelance facturando 7.000€/mes solo: vida estable. Escalar a 2 personas: facturas 15.000€ pero gestionas, contratas, pagas. ¿Qué prefieres? Decisión personal.

Ejercicio

Define tu objetivo personal: ingresos x calidad de vida. Decide si escalar tiene sentido para ti.

Resultado esperado

Decisión consciente, no por inercia.

  • Escalar porque "todos lo hacen".
08

Proyecto final · construye y publica

Por empezar

Implementa de extremo a extremo.

4 lecciones 20 min 40 XP
0 / 4 completadas
8.1
Elige caso real: agente / micro-SaaS / agencia Decide qué construyes basado en tu situación.
5 min Completada

Tres caminos:

  1. Agente para cliente: caso real de un cliente o conocido. Cobras o no, pero entregas.
  2. Micro-SaaS: producto propio en una vertical. 3-6 meses de trabajo.
  3. Agencia / servicios: empiezas a vender servicios IA a empresas.
Ejemplo real

Si tienes red comercial: agencia. Si eres developer sin red: micro-SaaS. Si tienes un cliente que paga: agente para él.

Decisión de camino
Mi situación: {{red, skills, tiempo, dinero ahorrado}}
Mis objetivos a 6 meses: {{ingresos, autonomía, otros}}

¿Cuál de los 3 caminos (agente, SaaS, agencia) encaja mejor? Justifica con criterios concretos.
Ejercicio

Elige tu camino. Comprométete a 3-6 meses.

Resultado esperado

Decisión tomada.

  • Empezar los 3 a la vez: ninguno funciona.
8.2
Stack mínimo decidido y justificado Una página con tus decisiones técnicas.
5 min Completada

Documenta tu stack en 1 página:

  • Frontend: cuál y por qué.
  • Backend: cuál.
  • DB: cuál.
  • LLM: cuáles y por qué.
  • Hosting: dónde.
  • Coste mensual estimado.
  • Riesgo principal del stack.
Ejemplo real

Stack documentado de Nodo IA: WordPress + theme custom + GoDaddy hosting + funciones PHP custom. Decisiones explicadas. Riesgos identificados.

Ejercicio

Documenta tu stack en 1 página. Compártelo con 1-2 senior para feedback.

Resultado esperado

Stack pensado, no improvisado.

  • Cambiar stack constantemente: nada se termina.
8.3
Implementación y deployment De código local a algo publicado.
5 min Completada

Pasos para sacar de local a producción:

  1. Repo en GitHub con README.
  2. Variables de entorno fuera del código (.env + .env.example).
  3. CI/CD básico: push → deploy automático.
  4. Dominio propio con HTTPS.
  5. Monitorización mínima: Sentry o Logtail.
  6. Backup de DB.
Ejemplo real

Next.js en Vercel + Supabase + dominio en Cloudflare. Push a main → deploy automático. 30 minutos de setup. Producción decente.

Ejercicio

Despliega lo que tengas. Por feo que esté. Es la única forma de medir respuestas reales.

Resultado esperado

Producto publicado, no en local.

  • No publicar hasta que esté "perfecto": nunca está perfecto.
8.4
Métricas y siguiente iteración Sin métricas, no hay mejora.
5 min Completada

Métricas mínimas según camino:

  • Agente: tasa de éxito, tiempo ahorrado al cliente, tasa de escalada a humano.
  • SaaS: signups, conversión free→paid, churn mensual, MRR.
  • Agencia: leads/mes, propuestas/mes, conversión a cliente, valor medio cliente.

Revisa semanalmente. Itera lo que mejor responda.

Ejemplo real

SaaS lanzado. Métrica clave: conversión free→paid. Si es <2%, problema con onboarding. Si es 8%, problema con tráfico. Métrica te dice dónde mejorar.

Plausible Analytics sin cookies.
Análisis de métricas
Mis métricas tras {{tiempo}}:
{{datos}}

Devuelve:
1) Qué funciona
2) Qué no
3) 3 hipótesis sobre el problema principal
4) Qué experimento haría primero
Ejercicio

Configura métricas mínimas. Revísalas semanalmente. Itera basándote en datos.

Resultado esperado

Negocio que mejora basado en datos, no en intuición.

  • Pasar 6 meses sin medir nada.
Proyecto final del curso

Proyecto final · Producto IA en producción

Construye un agente, un sistema RAG o un mini-SaaS funcional usando APIs reales. Hosting, dominio, autenticación básica y al menos un usuario beta.

  1. 1 Elige stack y API (OpenAI / Anthropic / open-source)
  2. 2 Implementa el core (agente, RAG o SaaS)
  3. 3 Despliega, mide y comparte el resultado

FAQ del curso

¿Para quién NO es este curso?

Para quien no sepa programar nada y nunca haya tocado una API. Tampoco para quien busque resultados sin invertir tiempo: este nivel requiere construir cosas y publicarlas.

¿Qué APIs se usan en el curso?

Principalmente OpenAI y Anthropic, con menciones a Google AI. Los ejemplos están en Python y JavaScript. El stack es válido en 2026 y se actualiza con cambios de versión relevantes.

¿Hace falta hosting o servidor?

Para los ejercicios básicos no. Para n8n self-hosted y proyectos finales conviene una VPS pequeña (5-10 €/mes) o servicio gestionado.

¿Voy a poder vivir de la IA al terminar?

El curso te da los conocimientos y muestra modelos viables, pero la captación de clientes y la disciplina de ejecución siguen siendo tuyas. Es un acelerador, no un atajo.

Has terminado el último nivel.

Ahora toca construir. Si quieres compartir lo que estás creando con la comunidad, escríbenos.

Contactar