Ni WordPress, ni Wix, ni note. Solo haciendo cp de un archivo a S3, la IA escribe y publica un artículo cada lunes por la mañana.

Así funciona este blog personal que monté y que sigo operando. El costo mensual de infraestructura ronda entre unos cientos y unos miles de yenes. Sin publicidad de ningún tipo. Aquí quiero dejar por escrito la filosofía de diseño y lo que he aprendido usándolo en el día a día.

Los detalles técnicos los tengo en otro artículo; aquí me centro primero en por qué lo construí y qué sacrifiqué y qué me quedé.

El punto de partida fue simplemente «quiero un blog sin anuncios y barato»

Para alguien que quiere difundir información desde un negocio propio, las opciones para tener un blog son sorprendentemente limitadas.

  • WordPress — Mucha libertad, pero el costo del servidor, la gestión de plugins y los parches de seguridad te persiguen para siempre
  • Wix / Squarespace — El panel de control es cómodo, pero cuesta varios miles de yenes al mes y el plan gratuito mete publicidad
  • note / Hatena — Ideal para escribir sin más, pero tanto el dominio como la experiencia son prestados
  • Generadores de sitios estáticos (Hugo / Astro) — Rápidos y baratos, pero cada vez hay que compilar en local y hacer push

En sectores como educación, asesoría legal o medicina, donde «mostrar publicidad daña directamente la credibilidad», los anuncios del plan gratuito son letales. Pero tampoco tengo tiempo para operar WordPress por mi cuenta.

Ahí fue cuando se me ocurrió: ¿y si simplemente «pongo el archivo en S3 y la IA lo convierte en artículo y lo publica sola»?

El núcleo del diseño fue decidir qué eliminar

Al construir este sistema, lo que más tiempo me llevó no fue decidir qué implementar, sino qué no implementar.

Lo que eliminé

  • Panel de administración — No hace falta. Con aws s3 cp es suficiente
  • Base de datos — No hace falta. Con un manifest.json en S3 sobra
  • Servidor en tiempo de ejecución — No hace falta. CloudFront devuelve HTML estático y punto
  • Sistema de login — No hace falta. El único que escribe soy yo
  • Comentarios — No hace falta. Quien quiera contactarme, que mande un correo
  • Integración con redes sociales, generación automática de OGP, AMP, PWA — No hace falta. Si los quiero después, los añado ← algunos ya los añadí
  • Enlaces prev / next — No hace falta (aunque todavía lo tengo en mente) ← al final los implementé

Lo que conservé

  • Layout sin publicidad
  • Tags de medición de GA4 y Microsoft Clarity (quiero ver cómo se lee con mapas de calor)
  • Categorías (5 fijas: tech / study / thought / life / creative)
  • Generación de artículos con IA (dejo una nota y la IA la pule)
  • Publicación automática los lunes por la mañana (la regularidad en las actualizaciones ayuda tanto al SEO como al estado de ánimo)

Supongo que la mayoría diseña sumando cosas, pero yo empecé restando. Pensar en qué puedes hacer solo con lo que queda hace que el sistema sea más sostenible a largo plazo.

Flujo de trabajo: el artículo sale solo el lunes por la mañana

En la práctica funciona así.

1. Cuando se me ocurre algo, lo mando a S3

aws s3 cp ~/Obsidian/notes/claude-code-jissen.md \
  s3://da-leca-blog/source/

Acepta de todo: notas de Obsidian, logs de conversaciones con ChatGPT, archivos docx, pdf… lo que sea. Solo hay que dejarlo en el prefijo source/ y listo.

Si quiero combinar varios archivos en un solo artículo, meto la carpeta entera.

aws s3 sync ./my-article-folder/ \
  s3://da-leca-blog/source/my-article-folder/

2. A las 9:20 del día siguiente, la IA prepara el borrador

Cada día a las 9:20 JST se ejecuta una Lambda, revisa source/ y, si el calendario de publicaciones está vacío, prepara el borrador para el próximo lunes.

Ahí entra Claude de Bedrock y se encarga de:

  • Dar forma al cuerpo del artículo (Sonnet lo reestructura como «editor de blog»)
  • Generar el slug de la URL (Haiku propone el kebab-case en inglés)
  • Determinar la categoría (Haiku elige entre las 5 categorías)

Todo automático.

3. El lunes a las 6:00, se publica solo

Se activa publish_lambda, copia el staging a producción, regenera el sitemap.xml e invalida CloudFront. Cuando termina, llega un correo de confirmación.

Lo único que hago yo es «hacer cp del material». El resto ocurre mientras duermo.

Lidié con esa debilidad humana de «querer controlar el orden»

Cuando lo automaticé por completo, me sentí un poco desplazado al ver que mis intenciones no se reflejaban. Concretamente, a veces quiero que «los artículos de una serie salgan en orden» o que «este artículo salga antes que los demás».

Así que añadí un mecanismo por el que poner un número al principio del nombre de archivo le da prioridad.

source/
├── 1_intro.md          ← sale primero
├── 2_setup.md          ← sale después
├── 10_advanced.md      ← luego este
└── random-thought.md   ← sin número, orden aleatorio

Con esto solo conviven una «cola ordenada» y un «pool aleatorio según el humor del momento». Cuando termina la serie, vuelvo al modo libre sin números.

Ese equilibrio «semiautomático» entre la automatización total y el control total me parece el más adecuado para una operación personal.

Costos: preveo que se mantendrá entre 150 y 2200 yenes al mes

La estimación de diseño es la siguiente.

Concepto Coste mensual aprox.
Bedrock (generación de 4 artículos) $0.06
Lambda Dentro del nivel gratuito
Almacenamiento S3 $0.025
CloudFront $1〜10 (según el tráfico)
SES (correos de notificación) Dentro del nivel gratuito
Total $1〜15 / mes

Operar WordPress a escala media cuesta como mínimo entre 1.500 y 3.000 yenes al mes (servidor compartido + dominio + copias de seguridad), así que mientras el tráfico sea bajo, la diferencia es aplastante.

Y aunque el tráfico crezca, el coste solo sube de forma lineal con la tarificación por uso de CloudFront. No hay saltos bruscos por cambios de plan ni ampliaciones de servidor. Eso, aunque parezca un detalle menor, hace mucho bien a la salud mental.

El miedo al vendor lock-in es menor de lo que esperaba

Me preguntan mucho: «¿No te preocupa quedar atrapado en AWS?». Es cierto que dependo de S3, CloudFront y Bedrock. Pero todo el contenido está guardado en S3 como Markdown o HTML, así que migrar es tan simple como copiar los archivos a otro hosting con aws s3 sync.

  • Moverlo a Cloudflare Pages → copiar archivos + cambiar DNS, y listo
  • Moverlo a Netlify → igual
  • Cambiar la IA a OpenAI → reemplazar el código de Lambda en un solo sitio

Lo importante es mantener el estado de «la infraestructura es AWS, pero los activos están en mis manos». Si metes los artículos en una base de datos, eso deja de ser posible.

Lo que aprendí usándolo

Lo bueno

  • La barrera para escribir bajó — Como le delego a la IA el «convertirlo en artículo de verdad», me basta con lanzar una nota
  • Las actualizaciones no se detienen — Si meto unos cuantos artículos en la cola, siguen saliendo solos aunque me olvide un tiempo
  • La limpieza de no tener publicidad — Sin anuncios en mi propio sitio, me resulta mucho más fácil recomendárselo a alguien

Lo mejorable

  • La falta de enlaces prev / next era más molesta de lo que parecía — Tenía pendiente añadirlos ← al final los implementé
  • La salida de la IA conserva ciertos tics — Lo estoy corrigiendo ajustando el system prompt

En el próximo artículo, explico toda la arquitectura técnica

Hasta aquí llegó la parte de «filosofía y operación».

En el siguiente artículo explicaré cómo lo monté en la práctica:

  • Por qué elegí la arquitectura S3 + CloudFront + Lambda
  • Por qué opté por Bedrock (en lugar de llamar directamente a la API)
  • Por qué me bastó con manifest.json + S3 ListObjects en vez de DynamoDB
  • Cómo aseguré el perímetro de seguridad mediante «enumeración de Behaviors en CloudFront»
  • Cómo hice que la recuperación ante fallos fuera idempotente

Espero que le llegue a alguien que esté dudando sobre qué tecnología elegir.

Este mismo blog funciona con este sistema. El fuente de este artículo también fue introducido en el sistema con un cp.