Mi stack actual como solo fundador (mayo 2026)

Esto no es un "Top 10 herramientas para founders" ni una recopilación de Product Hunt. Son las herramientas que pago todos los meses, que abro casi a diario y que ya han pasado el filtro de seis meses de uso. Hay productos buenísimos que descarté y los menciono también, porque saber qué NO usar es casi tan útil como saber qué usar.

Para cada herramienta sigo siempre la misma estructura: por qué la elegí, qué descarté, y cuándo NO usarla. Eso último es lo que casi nadie escribe, y suele ser lo más útil.

Hosting y deploy: Vercel*

Lo que aloja este blog y el SaaS que estoy construyendo. Lo elegí por la combinación de tres cosas que muy pocas otras plataformas igualan en 2026:

1. Previews por PR que funcionan a la primera. Cada vez que abro una rama, Vercel me da una URL con la versión completa de la app — frontend + funciones serverless + variables de entorno correctas para preview. Probar features sin pisar producción es trivial.
2. Edge Network global. La latencia desde Madrid, Buenos Aires o Ciudad de México es similar sin que yo tenga que pelearme con CDNs. Para un SaaS con usuarios dispersos, importa.
3. Integración con Next.js. Es la stack que mejor optimiza Vercel, y lo notas: funciones serverless con cold start aceptable, ISR, edge functions cuando las necesitas.

Qué descarté

• Railway: muy buena DX y precios honestos. Lo descarté porque la red de edge es más limitada y porque Vercel resuelve mejor el caso "frontend + APIs Next.js" out of the box.
• Netlify: técnicamente decente, pero sentí que el ecosistema se ha estancado vs Vercel. Hace cinco años eran intercambiables; hoy ya no.
• Self-host en Hetzner + Docker: sería más barato a partir de cierto volumen, pero como solo fundador el coste de mantener infra propia es altísimo. Hetzner entrará en juego cuando los costes de Vercel crucen un umbral que ahora mismo está lejos.

Cuándo NO usar Vercel

Si tu producto es un backend pesado tipo "CPU al máximo durante minutos" (procesado de vídeo, batch jobs largos, ML inference), Vercel no es tu sitio. Vete a Fly.io, Railway, o directamente a una VM. Tampoco si vas a tener tráfico altísimo desde un único país sin requerir global edge — un VPS en Hetzner te costará una décima parte.

Email y newsletter: Kit*

La newsletter que estás leyendo (si llegas desde el email) sale de Kit, que es como se llama ahora ConvertKit tras el rebranding. Probé Beehiiv y MailerLite antes de quedarme aquí.

Por qué Kit

• Automatizaciones potentes desde el plan gratis. Tags, secuencias y triggers basados en comportamiento. Para un blog/SaaS donde quieres segmentar por interés de cada lector, es diferencial. Los demás te lo cobran o te lo capan.
• Modelo basado en suscriptores únicos. No te penalizan por tener al mismo lector en varias listas: pagas por persona, no por copia. Cuando empiezas a tener formularios para varios productos, esto se nota mucho.
• Form builder y landing pages decentes. El embed se integra bien, hay templates, y soportan custom CSS — que es lo que uso para mantener la coherencia con el dark mode del blog.
• Ecosistema maduro. Kit lleva años haciendo solo email. La estabilidad y los integradores (Zapier, n8n, APIs) son los que te esperarías de una herramienta veterana.

	Kit (ex-ConvertKit)	Beehiiv	MailerLite
Plan gratis	Hasta 10k suscriptores con automatizaciones básicas	Hasta 2.500 suscriptores con casi todas las features	1.000 suscriptores y 12k emails/mes
Automatizaciones	Visual builder potente, tags y triggers desde el inicio	Simples — bien para empezar, cortas en serio	Decentes para newsletters; no para funnels complejos
Web view / SEO	Sí, con custom domain y archivo público	Sí, indexable y bonito por defecto	Sí, básico
Curva de aprendizaje	Media — más opciones que ofrecer	Baja	Baja

Cuándo NO usar Kit

Si lo que quieres es la versión más simple posible de mandar un email semanal a una lista pequeña sin segmentar nada, Beehiiv te va a doler menos: tiene menos botones y menos decisiones que tomar. Y si ya tienes una infra de email transaccional con AWS SES o Postmark, montar la newsletter encima con un poco de código sale mucho más barato a partir de cierto volumen.

Productividad: Notion*

Mis notas, el roadmap del SaaS, los borradores de los posts y el wiki interno (que solo veo yo, porque trabajo solo) están en Notion. Hay alternativas mejores en cada área aislada — Obsidian para notas locales, Linear para tickets, Coda para databases — pero la combinación gana.

Por qué Notion

• Una sola fuente para casi todo. No tener que saltar entre tres apps para "buscar dónde apunté la idea X" me ahorra una hora al día como mínimo.
• Templates útiles. Tengo plantillas para reseñas, para roadmap del SaaS, para ideas de post. Cuando arranco algo nuevo, salgo con velocidad.
• AI integrado decente. Para resumir reuniones (las pocas que hago) o reformular un párrafo, funciona bien sin sacarme del flujo.

Lo que NO me convence

• Lentitud. Notion es lento. No es noticia y no es bloqueante, pero es real.
• Sin offline real. Si me voy al AVE sin cobertura, sigue siendo un problema.

Cuándo NO usar Notion

Si necesitas escribir mucho a mano y rápido — un escritor o periodista — Obsidian o Bear son órdenes de magnitud mejores. Si necesitas tickets de equipo serios, Linear lo aplasta.

AI: Claude* + Cursor*

Mi flujo de código es básicamente Cursor abierto con Claude Sonnet como modelo principal. Hace dos años decía "no usaría AI para arquitectura crítica"; hoy es donde más valor le saco.

Cómo lo uso

• Diseño de features con Claude antes de codear. Le paso un párrafo del problema, le pido tres enfoques con tradeoffs y el más sensato. Luego cuestiono el más sensato hasta que se cae o sobrevive. Cuando sobrevive, codeo.
• Cursor para el bucle de iteración rápido. Tab completion, refactor multi-archivo, generación de tests. La velocidad ha crecido x5 fácil para tareas mecánicas.
• Claude para código no trivial. Cuando lo que voy a hacer requiere pensar, abro chat con Claude y trabajo a cuatro manos: yo describo intención, él propone, yo refino, repito.

Cuándo NO usar AI

Para lo que necesite garantías de seguridad o regulatorias serias (procesar datos sanitarios, financieros sensibles), todavía hay que pasar por procesos humanos. Y para problemas mal definidos — "diseña la arquitectura general del producto" — el AI por sí solo da resultados genéricos. La parte de pensar sigue siendo tuya.

Pagos: Stripe*

No hay sorpresa aquí. Stripe es la elección por defecto en Europa para SaaS y por mucho tiempo va a seguir siéndolo.

Por qué Stripe

• Stripe Tax: maneja IVA europeo, sales tax US y reverse charge B2B sin que yo tenga que saberme la normativa. Para un solo fundador, es no negociable.
• Checkout hospedado: una URL y listo, sin escribir un formulario. La parte de PSD2 y SCA está resuelta.
• API y webhooks claros. Trabajar con Stripe es de lo más placentero en infra de pagos.

Lo que descarté

• Lemon Squeezy (Merchant of Record): atractivo si quieres delegar IVA por completo y vender en los 50 países sin pensarlo. Lo descarté porque la comisión es notablemente más alta que Stripe + Stripe Tax, y el ecosistema sigue siendo más pequeño.
• Paddle: similar a Lemon Squeezy. Un punto a favor: trato del soporte. Punto en contra: comisiones más altas y menos integraciones.

Cuándo NO usar Stripe

Si vendes un infoproducto único a una audiencia global y no quieres tocar IVA jamás, MoR como Lemon Squeezy o Paddle es razonable. Y si tu mercado principal es España y vendes B2B con facturación clásica, Holded o Quaderno encima de Stripe te ahorrará pelearte con AEAT.

Analítica: Plausible*

Tracking del blog y del SaaS. Sin cookies, sin GDPR popups, hosteado en la UE. La salud mental de no tener que mantener un consent banner vale el precio sola.

Por qué Plausible

• Setup en un script de menos de 1KB. Dashboards limpios. Comparte URLs públicas si quieres hacer transparencia.
• Sin cookies → sin consent → sin overhead legal.
• Hosteado en Europa, lo que reduce dolores de cabeza con la transferencia internacional de datos.

Cuándo NO usar Plausible

Si necesitas seguimiento de eventos complejos (funnel multi-step, atribución avanzada, retention cohorts), te quedas corto. Para eso uso PostHog en el SaaS. Plausible es para "quiero saber qué páginas funcionan", no para "qué hace cada usuario en mi producto".

Resumen del stack

Si lo tuviera que poner en una línea: Vercel + Next.js + Postgres + Stripe + Kit, todo orquestado con Notion + Linear + Cursor/Claude. Suena mainstream — porque lo es. La razón de elegir mainstream es muy simple: cuando algo se rompe a las once de la noche y soy yo el único que lo va a arreglar, prefiero un stack con miles de hilos en Stack Overflow y documentación impecable que algo "vanguardista" donde el bug que me bloquea soy el quinto en encontrarlo.

Iré actualizando esta lista cuando algo entre o salga del stack. Y cada herramienta de las mencionadas merece un post propio cuando llegue su momento — me apunto los temas para los próximos meses.