DEV Community: Felipe

Lanzaste tu MVP: El Plan Post-Lanzamiento que el 90% No Tiene

Felipe — Wed, 05 Aug 2026 21:34:27 +0000

El mayor error de los founders no es dejar de lanzar. Es lanzar sin saber qué viene después.

Después de fallar múltiples veces, este es el mapa que nadie te da

El Error Más Común

Lanzaste tu MVP. Felicidades. Tienes 47 usuarios. ¿Y ahora qué?

El error más común es pensar que "lanzar" es el final. Es el comienzo.

El 90% de los founders lanzan y inmediatamente piensan: "Ahora a conseguir más usuarios."

La realidad es diferente: tus primeros 100 usuarios están abandonando por problemas que ni sabes que tienes.

Las 3 Fases Post-MVP

Después del MVP vienen 3 fases. Cada una tiene sus propios desafíos y métricas. Si saltas fases, pagas el precio.

Fase 1: Validation (Semanas 1-8)

Tu trabajo: Saber si la gente REALMENTE usa tu producto o solo lo "probó una vez".

Métricas que importan:

DAU vs Total Users — ¿Cuántos vuelven daily?
Retention curve (día 1, 7, 30) — ¿Vuelven o se van?
Feature adoption rate — ¿Qué features usan realmente?
NPS temprano — ¿Lo recomendarían?

Regla de oro: Si retention día 7 < 20%, no pasas de fase. Trabaja en el producto antes de pensar en crecimiento.

Fase 2: Reliability (Meses 2-4)

Tu trabajo: Que no se caiga cuando llegue tráfico real.

"Funciona para mis papás" NO es suficiente.

Métricas que importan:

Uptime > 99.9% — Downtime = pérdida de confianza
Response time < 200ms — La gente no espera
Error rate < 0.1% — Cada error es un usuario que se va
Database performance — El cuello de botella silencioso

Fase 3: Scale (Meses 4-12)

Tu trabajo: Preparar la infraestructura para 10x usuarios sin reescribir todo.

Métricas que importan:

Cost per user — ¿Cuánto te cuesta cada usuario?
Scalability metrics — ¿Soporta 10x tráfico?
Team velocity — ¿El equipo puede iterar rápido?

El Checklist Técnico de Escalabilidad

7 cosas que necesitas tener listas ANTES de que te alcancen:

1. Database Strategy

Índices en queries frecuentes
Connection pooling
Read replicas si lees más de lo que escribes
Cache layer (Redis)

2. API Rate Limiting

No vas a creer cuánto te cuesta un usuario que hace 10,000 requests/min.

3. Background Jobs

Todo lo que no necesita ser sync: a una cola.

Email
Reportes
Procesamiento de archivos

4. Observability

Logs centralizados
Métricas de negocio (no solo técnicas)
Alerts que importen

5. Security Baseline

Auth robusto (no inventar — usa JWT, OAuth)
HTTPS everywhere
Input validation
Dependency updates automatizados

6. CI/CD que No Dé Miedo

Deploys diarios sin stress
Rollback en 1 click
Feature flags para testing en prod

7. Cost Tracking

Saber cuánto te cuesta cada usuario
Alertas de overspend
Optimización de recursos

Qué Contratar Primero

Con MVP validado y $50k en el bank, esta es la prioridad:

Prioridad 1: Dev Full-Stack Capaz de Todo

Full-stack capable
Sabe deployar
Puede resolver incidentes
Contrata: 1 senior o 2 mid

Prioridad 2: Alguien en Producto

Define qué construir
Escucha usuarios
No es diseñador — es "product sense"

Prioridad 3: First Sales Hire

Si tienes product-market fit, alguien necesita llevar agua

Lo que NO necesitas aún:

CTO famoso
Equipo de 5 devs
QA dedicado
Project manager

Cuándo Saber Que Es Hora de Escalar

Señales de que tu MVP está listo para escalar:

Retention > 40% semana 1
NPS > 30
Tienes waitlist
Users te piden features específicas (no genéricas)
Estás dejando dinero sobre la mesa por límites técnicos

Señales de que NO estás listo:

Usuarios no vuelven después del día 1
No sabes por qué los usuarios se van
Cada deploy rompe algo
No tienes métricas de negocio

El Consejo Final

Antes de pensar en "cómo adquiero más usuarios", asegúrate de que los que tienes NO se estén yendo.

Lanzar es fácil. Mantener, escalar y no perder tu sanity en el proceso — eso es el verdadero desafío.

Cuál es tu fase actual? ¿Validation, Reliability o Scale?**

Construye conmigo en YouTube | LinkedIn

MCP Servers: Por Qué Tu SaaS Necesita Uno (Y Cómo Implementarlo en Python)

Felipe — Tue, 04 Aug 2026 22:51:47 +0000

Hace 6 meses: ¿Qué es MCP?

Hoy: ¿Tu SaaS ya tiene un MCP server?

Si tu respuesta es "no", este artículo es para ti.

¿Qué es MCP?

MCP = Model Context Protocol. Es el estándar que permite que cualquier modelo de AI se conecte a tus herramientas, datos y APIs de forma segura y estandarizada.

Piénsalo como "el USB para AI". Así como el USB te permite conectar cualquier dispositivo a cualquier computadora sin adaptadores especiales, MCP te permite conectar cualquier modelo de AI (Claude, GPT, Gemini) a cualquier fuente de datos o herramienta sin integraciones custom para cada uno.

[Tu SaaS] ←→ [MCP Client] ←→ [MCP Server] ←→ [Herramientas/Datos]
              ↕️                        ↕️
         [Modelo AI]              [APIs, DB, Files]

¿Por Qué Ahora?

Cada SaaS está agregando features de AI. Los modelos necesitan acceder a datos reales. Sin un estándar, cada integración es un proyecto nuevo.

La diferencia:

Sin MCP	Con MCP
Integración custom para cada modelo	Un server funciona con todos
Datos estáticos de entrenamiento	Datos en tiempo real
Cada proyecto es único	Estandarizado y portable
Mantenimiento costoso

Anthropic, OpenAI y Google ya soportan MCP. Los primeros en adoptar van a ganar.

Qué Puedes Hacer con un MCP Server

Consultar tu base de datos en tiempo real — El modelo accede a datos actuales, no información vieja de entrenamiento
Ejecutar acciones en otras apps — Slack, Notion, GitHub, lo que necesites
Leer y escribir archivos — Documentos, imágenes, configuración
Llamadas a APIs externas — Weather, pagos, cualquier API REST
Un solo server para TODOS los modelos — No necesitas reimplementar para cada proveedor

¿Cuándo Usar MCP?

USA MCP cuando:

✅ Tu AI necesita datos en tiempo real
✅ Necesitas que el modelo tome acciones en otras apps
✅ Quieres un estándar portable entre modelos
✅ Tu SaaS va a ofrecer "AI features" a usuarios

Probablemente NO necesitas MCP cuando:

❌ Es solo un chatbot de FAQ estático
❌ No necesitas persistencia ni acciones
❌ Solo usas el modelo para generar texto sin contexto

El Caso de Uso Más Común

"Un usuario pregunta por un producto. El modelo consulta tu DB, filtra por disponibilidad, y responde con datos reales — no con información vieja de entrenamiento."

Ejemplo real:

Usuario: "¿Tienes laptops en stock?"

Sin MCP: "Sí, tenemos laptops disponibles" (el modelo no sabe realmente)

Con MCP: "Sí, tenemos 15 unidades de la Laptop Pro a $1,299" (dato real)

Siguiente Paso

En los próximos 12 meses, cualquier SaaS que no tenga MCP va a estar en desventaja. Empieza hoy con algo simple:

Identifica un caso de uso donde tu AI necesita datos reales
Implementa un MCP server básico
Conecta tu modelo favorito
Itera y expande

El estándar está madurando rápido. Ser early adopter tiene ventajas competitivas significativas.

¿Ya tienes un MCP server en tu SaaS? ¿Estás pensando implementarlo? Comparte tu experiencia en los comentarios.

Tokens por Segundo: Cómo medir y optimizar la velocidad en modelos de IA

Felipe — Mon, 03 Aug 2026 15:31:41 +0000

Cuando llevamos modelos de lenguaje o IA a producción, la latencia es nuestro principal enemigo. Evaluar un modelo únicamente por su precisión ignora un factor crítico: el rendimiento computacional.

En este post analizamos por qué la velocidad (medida en tokens por segundo) se ha convertido en una métrica clave de arquitectura y cómo puedes empezar a medirla.

¿Por qué importa la velocidad?
Reducción de Latencia: Aplicaciones críticas (finanzas, salud, automatizaciones) no pueden esperar segundos por una respuesta.

Eficiencia de Recursos: Optimizar el rendimiento disminuye el uso prolongado de GPUs, reduciendo directamente la factura cloud.

Técnicas Clave: El uso de arquitecturas ligeras, cuantización y batch processing permite mantener la precisión mientras se incrementa el rendimiento.

Ejemplo Práctico: Midiendo el rendimiento en Python
Un enfoque inicial para medir la tasa de procesamiento de datos/tokens en tus pruebas de rendimiento:

import time

def medir_velocidad(modelo, datos):
    inicio = time.time()
    # Procesamiento del conjunto de datos o tokens
    respuesta = modelo.procesar(datos)
    fin = time.time()

    tiempo_total = fin - inicio
    tokens_procesados = len(datos)  # O conteo exacto de tokens generados/procesados

    velocidad = tokens_procesados / tiempo_total
    print(f"Tiempo total: {tiempo_total:.2f}s")
    print(f"Rendimiento: {velocidad:.2f} tokens/segundo")

    return velocidad

Tip de Arquitectura: Un objetivo de ~100 tokens/seg es una excelente referencia para sistemas que requieren interacción humana en tiempo real.

Pasos sugeridos para optimizar:
Benchmark inicial: Establece tu baseline de tokens/seg.

Batch Processing: Agrupa solicitudes para maximizar el paralelismo.

Modelos Destilados/Cuantizados: Evalúa si un modelo más pequeño satisface el caso de uso con una fracción de la latencia.

💬 Comunidad Pivelcode: ¿Qué herramientas o librerías utilizas para hacer profiling y benchmarking de tus modelos de IA? ¡Déjalo en los comentarios!

📌 Suscríbete al canal de YouTube de Pivelcode para ver demostraciones en código y síguenos en Medium y Dev.to para más contenido sobre desarrollo y tecnología.

El ratio que nadie te dice: Construir un SaaS es 30% código y 70% todo lo demás

Felipe — Wed, 29 Jul 2026 18:09:31 +0000

Cuando empecé Semsei, pensé que el desafío era técnico.

El stack. La arquitectura. Los agentes. El deployment.

Nueve años de experiencia resolviendo problemas técnicos. Esto iba a ser pan comido.

Nadie me dijo que construir un SaaS solo es 30% código y 70% todo lo demás.

Lo que realmente ocupa tu tiempo

Ventas (sin track récord)

Conseguir los primeros clientes cuando no tienes referencias es brutal.

# que es vender:
user.purchase(product)

# Lo que realmente es vender:
def primera_venta():
    conversaciones = outreach_frio(100)  # semanas de emails
    demos = filter(conversaciones, interested=True)
    propuestas = generar_para(demos)
    negociacion = loop(propuestas, revisions=3)
    return negociacion.cierre()  # semanas más

La primera venta tomó semanas de conversaciones, propuestas, y una demo que repetí hasta que sonaba natural.

Marketing (desde cero)

Hacer que sepan que existes cuando no tienes presupuesto para ads:

# Stack de marketing cuando no hay presupuesto:
marketing_channels = [
    "linkedin_posts",      # 2-3 horas por post
    "community_building",  # engagement diario
    "outreach_frio",      # 50 mensajes por día
    "collaborations",      # networking que no escala
]

# Tiempo disponible: none (estás construyendo el producto)

Son horas que no aparecen en ningún backlog técnico.

Soporte (porque eres el único equipo)

# Tu sistema de soporte ideal:
ticket_system = sophisticated_zendesk()

# Tu realidad actual:
def soporte():
    while True:
        mensaje = user.slack_message()
        if message.hour > 20 or message.hour < 7:
            respuesta = responder()  # a las 11pm
        if message.urgent:
            resolver_inmediatamente()

El primer cliente que pierdo no fue por mal producto. Fue por mala respuesta.

Admin (lo que nadie warned)

# Lo técnico:
product = build_good_code()

# Lo que realmente necesitas:
checklist = [
    "facturas_clientes",      # no es automático
    "impuestos_trimestrales", # sorpresa!
    "contratos",             # necesitas abogado
    "GDPR_compliance",       # porque EU
    "terminos_servicio",     # Copywriting + Legal
    "politica_privacidad",    # todavía Legal
]

Y las promesas que le haces a los usuarios sin tener infraestructura para cumplirlas.

Mental (lo más difícil)

Mantener la motivación cuando:

Nadie te está viendo
Los números no crecen
Te preguntas si vale la pena
El código fácil ya está hecho, y lo que queda es lo duro

Por qué el código es la parte fácil

Suena contraintuitivo. Pero después de años de resolver problemas técnicos complejos:

# Lo que sé hacer bien:
developer_skills = {
    "learn_anything": True,        # siempre puedo aprender
    "pattern_recognition": True,    # resuelvo problemas nuevos con problemas viejos
    "estimate_timelines": True,    # sé cuánto tarda algo
    "pick_technology": True,        # sé qué usar y cuándo
}

# El problema: el mercado no sigue estas estimaciones

El código tiene soluciones conocidas. La venta no.

Y cuando ambos fracasan:

# Código: feedback inmediato
result = run_code()
if result.error:
    fix(result.error)  # segundos/minutos

# Mercado: feedback tardado
product = launch(product)
wait(months=3)
if metrics.bad:
    pivot()  # semanas de trabajo

Lo que he aprendido

El ratio no es 80/20. Es más como 30/70.

# Día típico de founder técnico:
day = {
    "coding": "3 horas",      # 30%
    "sales": "2 horas",       # encontrar leads, follow-ups
    "marketing": "2 horas",   # posts, engagement
    "support": "1.5 horas",   # Slack, emails, llamadas
    "admin": "1 hora",       # facturas, bureaucracy
    "strategy": "1 hora",     # qué construir ahora
    "meetings": "1.5 horas", # calls que podrían ser async
    "context_switching": "2 horas",  # el impuesto oculto
}
# Total: 14 horas. No 8.

Y ese 70% te hace mejor builder.

Porque cuando entiendes el negocio completo, no solo una pieza:

Diseñas código que resuelve problemas reales, no problemas imaginarios
Priorizas features que generan revenue, no features que son técnicamente interesantes
Hablas el idioma del cliente cuando discutes scope

# El mejor desarrollador que conozco:
def best_developer():
    skills = [
        "escribe_bien_codigo",
        "entiende_el_negocio",  # <-- esta es la diferencia
        "sabe_cuando_parar",     # <-- esta también
    ]
    return skills

El mejor desarrollador no es el que escribe el código más elegante.

Es el que sabe cuándo el código no es el problema.

Mi día actual

Hoy tengo:

Semsei funcionando con clientes reales que pagan
Norvik con entregas activas para otras empresas
pivelcode construyéndose como marca personal

Y sigo aprendiendo que el código es la parte fácil.

Lo difícil es todo lo demás.

Pero también es lo que me hace mejor en lo que hago.

Si estás construyendo algo propio, sabes de lo que hablo. Si estás pensando en empezar, esto es lo que te espera.

No es para desanimarte. Es para que cuando llegue lo difícil, sepas que es normal.

SaaS #Startup #BuildInPublic #IndieDev #ConstruyeConmigo #FounderJourney #TechFounder

Agentes de AI: Por Qué No Es Solo Un Chatbot fancy

Felipe — Tue, 28 Jul 2026 17:06:04 +0000

Un Chatbot responde preguntas.
Un Agente de AI ejecuta tareas.

Parece simple, pero la diferencia cambia todo en cómo diseñas, construyes y despliegas sistemas con LLMs.

Después de meses experimentando con Houston + Composio, esto es lo que aprendí:

La Diferencia Conceptual

Un chatbot vive en una conversación:

Recibe un input
Genera texto
Te devuelve texto
Fin.

Un agente es un sistema con memoria y herramientas:

Recibe un input (o lo busca automáticamente)
Decide qué herramientas necesita usar
Ejecuta acciones outside del LLM
Mantiene estado entre interacciones
Aprende del resultado

La Diferencia Práctica

Chatbot: "Escríbeme un email a Juan"
→ Te devuelve texto → Tú lo copias → Tú lo pegas → Tú lo envías

Agente: "Contacta a todos los leads que no respondieron"
→ Lee la lista → Genera mensajes personalizados → Envía → Registra respuestas → Agenda follow-up
→ Sin ti.

Los 4 Componentes de Un Agente

1. Percepción

Recibe información de múltiples fuentes:

APIs externas
Bases de datos
Archivos subidos
webhooks
Conversaciones previas

2. Razonamiento

El LLM orquesta las decisiones, pero no es el único cerebro. Decide:

Qué información necesita
Qué herramientas usar
Cuándo actuar
Cuándo pausar (human-in-the-loop)

3. Acción

Ejecuta cosas en el mundo real:

# Esto es tool calling
agent.call_tool("send_email", {
    "to": lead["email"],
    "subject": "Seguimiento",
    "body": personalized_message
})

4. Memoria y Estado

Mantiene contexto entre ejecuciones:

Qué hizo la última vez
Qué funcionó vs qué no
Preferencias del usuario
Progreso del workflow

El Error Más Común

"Construí un agente de AI."

Nope. Construiste un chatbot con mejor prompt.

Un agente real tiene tool calling, estado persistente y ejecución outside del LLM. Si solo está generando texto, es un chatbot sofisticado, no un agente.

Un Ejemplo Concreto

El chatbot de soporte:

"Cuéntame qué problema tienes"
"Te ayudo con eso"
Fin.

El agente de soporte:

Recibe el mensaje
Consulta tu base de conocimiento
Revisa el historial del cliente
Genera una respuesta personalizada
Si no sabe, crea un ticket en tu sistema
Notifica al humano pertinente
Registra la interacción para mejorar

Cómo Empezar

La forma más simple de convertir un chatbot en un agente:

# Antes (chatbot)
response = llm.chat("envía un email")

# Después (agente)
if should_send_email(analysis):
    result = agent.call_tool("send_email", {
        "to": email,
        "subject": subject,
        "body": llm.generate(body_context)
    })
    agent.update_memory("email_sent", result)

La diferencia: ahora tu código decide y actúa. El LLM solo ayuda a generar el contenido.

Conclusión

Si tu "agente" solo responde preguntas, tienes un chatbot. Si puede:

Tomar acciones outside del chat
Mantener estado
Llamar herramientas reales
Iterar basándose en resultados

...entonces sí tienes un agente.

Estoy documentando mi aprendizaje en IA. Si estás explorando agentes de AI, happy to chat.

#AIAgents #LLMs #ToolCalling #SoftwareEngineering