Mi Stack favorito para proyectos personales en 2026

Hoy en día todo el mundo habla de crear aplicaciones gigantes que escalan, con millones de usuarios, de montar tu SaaS y demás. Pero yo también disfruto crear mis propias herramientas: en lugar de pagar Obsidian, apps móviles de finanzas o aplicaciones de tareas, he ido implementando todo esto yo mismo (con ayuda de IA, obviamente) sobre un sistema propio.

En este artículo te comparto mi stack personal favorito para crear aplicaciones propias: proyectos que no están enfocados en clientes, sino en herramientas que uso a diario para seguir mis finanzas, mis tareas, mis proyectos y tener mi información personal organizada. Y no se trata solo de una web con backend y frontend: también verás cómo integro un agente de IA con un CLI propio y varios proyectos open source que vale la pena conocer.

⚠️ Importante: este stack no está pensado para clientes. Si se lo vas a aplicar a un cliente, ten en cuenta que debes saber muy bien lo que haces, porque puedes generarte más trabajo a futuro. Lo recomiendo para quienes quieren crear sus propios programas internos, manejar sus tareas o llevar un negocio de una sola persona.

La arquitectura: frontend, backend y base de datos

Todo proyecto web se divide, de cierta forma, en tres partes: frontend, backend y base de datos. Vamos pieza por pieza.

Backend: Go

Para el backend, que es el centro que une todo, me gusta usar Go. Las razones:

• Compila muy rápido. No parece tan importante, pero Go es uno de los lenguajes que más rápido compila. Cada cambio que hagas en tu backend es prácticamente instantáneo, casi como trabajar con un lenguaje interpretado.
• Es veloz en ejecución. No es tan rápido como Rust, C o C++, pero sí mucho más rápido que lenguajes interpretados como Python o JavaScript.
• Genera un binario único. No necesita instaladores ni runtimes, y las peticiones a tu servidor consumen muy pocos recursos.

¿Por qué no Rust si es más rápido? Justamente por la compilación: Rust es lento para compilar, no por mal diseño, sino por sus garantías de seguridad de memoria, que añaden pasos extra de procesamiento. Para un programa personal que no necesita recursos tan intensivos, Go te da lo mejor de los dos mundos: desarrollo ágil y un backend muy veloz.

Base de datos: SQLite

Aquí te recomiendo ir por una base de datos SQL. Casi todas las aplicaciones relacionan datos entre sí: usuarios con ventas, ventas con transacciones, notas con proyectos, etc. Si vas a crear una base de datos, mejor que esté preparada para eso.

Opciones SQL hay muchísimas: PostgreSQL, MySQL, Oracle, Microsoft SQL Server… Pero para proyectos personales mi elección es SQLite:

• Es una base de datos SQL que vive en un solo archivo. No necesitas instalar un servidor pesado ni ningún servicio adicional.
• Es probablemente la biblioteca de base de datos más desplegada del mundo: el "PostgreSQL del autoalojado".
• Al ser un archivo local, es extremadamente rápida y hacer backups es tan simple como copiar el archivo.

¿Que no escala como una base gigante? Correcto, no es para eso. Si lo tuyo es escalar, existe Turso, un proyecto basado en SQLite (y escrito en Rust) que te permite alojar tu base en la nube y añadir más instancias. Pero si ya manejas SQL, para herramientas propias SQLite es más que suficiente.

💡 Si quisieras exprimir aún más el rendimiento, la combinación se acelera reemplazando Go por Rust y SQLite por Turso. Pero para el 99% de los casos personales, Go + SQLite vuela.

Frontend: React + Vite (SPA)

En el frontend hay de todo: Next.js, Astro, Angular, Svelte… Los frameworks siguen siendo útiles e importantes (quizás a futuro la IA cambie esto con código agnóstico en JavaScript vanilla, pero de momento no).

Mi sugerencia: React con Vite, siempre como SPA. Es decir, todo el código vive en el frontend, sin renderizado del lado del servidor ni frameworks grandes con enrutado complejo. Es lo más rápido que vas a encontrar y suficiente para crear dashboards, paneles de control y formularios que se comunican con tu backend.

Además, Vite está incorporando Rolldown, su nuevo bundler escrito en Rust, con lo que el compilado se vuelve aún más veloz.

¿Necesitas renderizado del servidor por algún motivo? Entonces mira TanStack Start. Es un muy buen framework y ofrece lo mismo que Next, aunque personalmente lo siento un poco más lento que usar React puro.

Autoalojado: el Raspberry Pi como tu propio servidor

Lo genial de un stack para herramientas propias es que puedes autoalojarlo. Sí, existe la nube: puedes pagar un VPS o un Platform as a Service como Vercel o Railway y desplegar fácilmente. Pero si quieres lo más veloz, práctico y controlado completamente por ti, ve por el self-hosting.

Mi dispositivo favorito para esto es un Raspberry Pi: un computador del tamaño de una tarjeta de crédito que consume muy pocos recursos. Lo dejas enchufado, le conectas un cable Ethernet y listo: tienes un servidor en casa, sin pantalla ni teclado. Es como tener un VPS comprado de por vida.

(Si prefieres no comprar hardware, puedes reemplazarlo por un VPS de DigitalOcean, AWS o cualquier proveedor; los hay desde 4–5 dólares al mes.)

Ojo con la arquitectura ARM

Un detalle importante: el Raspberry Pi no tiene la misma arquitectura que un VPS típico (x86). Usa ARM, la misma arquitectura que está llegando a laptops y tablets modernas. Esto significa que al generar tus contenedores Docker debes compilarlos para ARM64. Si usas un Mac con Apple Silicon ya te sonará familiar; si no, aquí aprenderás algo nuevo sobre despliegue multi-arquitectura.

Mi truco para simplificar: como el frontend genera archivos estáticos, lo embebo dentro del binario de Go. Así solo despliegas un proyecto: Go sirve tu frontend y se comunica con la base de datos (que es un archivo). Un solo contenedor y listo.

CI/CD: GitHub Actions + GHCR + Watchtower

Puedes conectarte por SSH al Raspberry y desplegar manualmente, pero lo ideal es que con un simple git push todo se compile y despliegue solo. Eso es CI/CD.

Hay opciones como Jenkins (open source, autoalojable) o CircleCI, pero Jenkins es pesado y el Raspberry no tiene tantos recursos. Mi flujo es este:

1. Monorepo: todo el proyecto (backend, frontend, CLI) vive en un solo repositorio. Para una aplicación personal no quieres tres repos distribuidos.
2. GitHub Actions: en cada push, GitHub compila en la nube tu contenedor (¡incluso para ARM64, sin importar si desarrollas en Windows, Linux o Mac!).
3. GHCR (GitHub Container Registry): donde se alojan las imágenes Docker generadas. Es la alternativa de GitHub a Docker Hub.
4. Watchtower: corriendo en el Raspberry Pi, consulta constantemente GHCR y, cuando detecta una imagen nueva, actualiza el contenedor automáticamente. (El proyecto fue archivado a finales de 2025, pero sigue funcionando perfectamente para este caso.)

💡 Tip: GitHub Actions te regala una cantidad limitada de horas de compilación al mes. Trabaja en una rama dev y haz merge a master solo cuando estés seguro de desplegar, para no quemar minutos compilando en cada push.

Por darte una idea, mi sistema principal es un proyecto personal que llamo Track Home: maneja mis tareas, notas y cuentas. Lleva Go en la API, TypeScript en el frontend, y en GHCR se publican los contenedores del frontend y de la API.

Integrando un agente de IA: OpenClaw + CLI propio

Hace años este stack era complicado de montar, no por difícil, sino por el tiempo que tomaba. Hoy puedes crear todo esto con cualquier agente de IA: Claude Code, Codex, OpenCode con el modelo abierto que prefieras… vas a llegar a lo mismo. Este proyecto completo me tomó un par de días y fue muy divertido; en un fin de semana podrías tenerlo hecho.

Y claro, una vez tienes tu sistema, vas a querer una IA que lea tus datos. Aquí entra lo nuevo de estos últimos años: MCPs, CLIs, skills…

El agente en el Raspberry Pi

En el mismo Raspberry puedes instalar OpenClaw, un proyecto que convierte tu dispositivo en host de un asistente de IA personal al que puedes escribirle desde Telegram, WhatsApp o aplicaciones de mensajería similares. No es el único: Hermes es otro proyecto popular, pero estos dos son los que más se mencionan hoy.

Un CLI como puente entre la IA y tu API

¿Y cómo hace el agente para interactuar con tu aplicación? Lo primero que pensarías es un MCP (la forma estándar de conectar tu API con un agente de IA). Pero en lo personal creo que hay una vía más simple y muy "de desarrollador": crear un cliente de consola para tu propia API.

La idea: si tu backend expone rutas como /api/transactions, /api/notes o /api/contacts, puedes crear un CLI que consuma esas mismas rutas con comandos:

mycli transactions   # lista tus transacciones
mycli notes          # lista tus notas

¿Para qué, si es lo mismo que la API? Porque no es para ti, es para la IA. Un agente como OpenClaw ya sabe ejecutar comandos de sistema (bash, curl, apt…). Si le das un CLI con un buen --help, el agente lee los comandos disponibles y los usa como puente hacia tu API. En mi caso, le pido desde Telegram "consulta mi tarea menos prioritaria" y el agente ejecuta --help, descubre el comando de listado y me responde leyendo mis datos reales.

Incluso puedes añadir flags pensados para agentes, como salida en JSON para formatearla con jq.

Mi CLI está creado en TypeScript con Ink, el mismo proyecto que usa Claude Code: sintaxis de React, pero para construir aplicaciones de consola. No lo elegí por rendimiento (para eso iría Go o Rust), sino porque la cantidad de herramientas de consola modernas creadas con Ink es enorme y la lógica se parece a la del frontend.

Skills: instrucciones reutilizables

Como uso mucho Claude Code, también tengo skills propios. Un skill es básicamente un conjunto de instrucciones que escribes una vez y reutilizas. Por ejemplo, tengo uno que le dice al agente cómo desplegar el proyecto: "estoy en un Raspberry Pi, construye las imágenes en ARM64, súbelas a GHCR, paso uno, paso dos…". Lo creé porque a veces me quedaba sin horas de GitHub Actions, así que compilo en mi máquina y subo el contenedor directo a GHCR sin gastar minutos de CI.

Lo mejor: cuando algo cambie (por ejemplo, si vuelvo a usar Mac), solo añado una instrucción extra al skill.

App de escritorio con Tauri

El mismo proyecto tiene también versión de escritorio gracias a Tauri. La razón es simple: Tauri embebe tu aplicación de React (la misma que ya tienes escrita y optimizada con tooling en Rust) en una interfaz de escritorio, con un rendimiento excelente y compilación multiplataforma.

Es mucho más liviano que Electron (el que usa VS Code): consume menos recursos y, para un proyecto personal, la aplicación literalmente vuela. En el diagrama solo añades otro cliente más que consume la API.

Acceso desde cualquier lugar: Tailscale

Si te mueves entre varios computadores (laptop, escritorio, móvil), querrás acceder a tu sistema desde todos. Como el Raspberry está en tu red local, la solución es meter todo dentro de una VPN privada con Tailscale.

Tailscale le asigna una IP privada a cada dispositivo: tu Raspberry Pi, tu laptop, tu móvil… Instalas la app en cada uno y todos pueden comunicarse con tu servidor casero aunque estés fuera de casa, sin exponer nada a internet. (Si usas un VPS esto no es necesario, porque ya es accesible desde cualquier lugar.)

Y si quieres llevarlo más lejos: el Raspberry no tiene potencia para ejecutar modelos de IA locales, pero puedes añadir otro dispositivo a la red. Yo estos días tengo en mis manos un NVIDIA DGX Spark, que permite ejecutar modelos locales: es como tener tu propia IA autoalojada, sin pagar APIs.

El resultado: tu propio mini laboratorio

¿Qué terminas construyendo con todo esto? En mi caso, un dashboard sencillo (con componentes de shadcn/ui) donde manejo tareas, seguimiento de finanzas, proyectos personales y de clientes, e incluso un playground de IA propio. Ya no uso Obsidian ni pago aplicaciones de finanzas: todo está aquí.

Y sé que Obsidian es un gran proyecto, pero al final son puros archivos Markdown, y cuando quieres más control (una terminal integrada, módulos propios) llegas a saturarte de plugins. Con un sistema propio tienes algo adaptado exactamente a lo que tú usas, donde no tienes miedo a romper nada porque es tuyo, y cada paquete nuevo que aparece en internet tiene un lugar donde probarse.

Además, todo el corazón del sistema es un archivo SQLite: haces backup, migras o cambias de herramienta cuando quieras. No dependes de un agente o servicio que mañana puede desaparecer.

Resumen del stack

Para proyectos de clientes la historia es otra: ahí quieres terminar rápido y desplegar en una nube grande con una base que escale. Cambiaría SQLite por PostgreSQL, probablemente el frontend por Next.js, y quizás Go por Bun o Node si quieres ahorrar tiempo. Pero para mis herramientas personales, en 2026, esto es lo que más me gusta usar.

¿Qué otras herramientas añadirías tú al stack? ¿Tienes dudas de qué se puede o no se puede hacer con esto? Déjamelo en los comentarios: así también puedo aprender una herramienta más y sumarla.

Si quieres conocer más, visita fazt.dev, donde puedes reservar asesorías personalizadas sobre cualquiera de estos temas.