Opero Lisssto!, una plataforma SaaS de presencia digital para negocios locales. Clientes reales, un servidor, una persona. Sin equipo de ingenieria. Sin inversionistas. Sin frameworks de moda.

Este articulo explica que tecnologias uso, por que las elegi, y que evito a proposito.

La filosofia: aburrido es bueno

Cada tecnologia que elegimos cumple una regla simple: tiene que ser lo suficientemente aburrida como para que no me de problemas a las 3am.

No uso lo mas nuevo. Uso lo mas probado. Cuando eres una persona operando todo, cada dependencia es un punto de fallo potencial que vas a tener que resolver tu solo. Menos piezas, menos problemas.

Mi criterio para elegir una tecnologia:

  1. Que tenga una comunidad grande (si tengo un problema, alguien ya lo resolvio)
  2. Que mi agente de IA la conozca bien (si la tecnologia es oscura, el agente va a improvisar)
  3. Que pueda funcionar sin mi (si me voy de vacaciones, no se cae nada)

Backend: Python + FastAPI

El backend completo esta en Python con FastAPI. No Django, no Flask, no Node.js.

Por que FastAPI:

  • Es rapido en ejecucion (async nativo) y rapido en desarrollo
  • La documentacion es excelente — importante cuando tu "equipo" son agentes de IA
  • Soporte nativo de WebSockets (necesario para el chat en tiempo real)
  • Python es el lenguaje que mejor entienden los modelos de IA, lo que hace que mis agentes sean mas efectivos al escribir y modificar codigo

Por que no un framework full-stack como Django: Porque no necesito todo lo que Django trae. Prefiero ensamblar piezas simples que entiendo, antes que heredar un framework con magia que no controlo.

Frontend: HTML renderizado en el servidor

Aqui es donde la mayoria de la gente se sorprende: no uso React, ni Vue, ni Angular, ni ningun framework de JavaScript.

El frontend es Jinja2 (templates de HTML) renderizado en el servidor, con Tailwind CSS para estilos y JavaScript vanilla para interactividad. Donde necesito algo dinamico, uso HTMX — que permite hacer peticiones al servidor sin escribir JavaScript complejo.

Por que server-side rendering (SSR):

  • Una sola base de codigo (Python). No hay un "proyecto frontend" separado con su propio build, su propio deploy, y sus propios problemas
  • Carga rapida. El HTML llega completo al navegador. No hay "loading spinners" mientras un framework de JavaScript se inicializa
  • SEO nativo. Los motores de busqueda ven el contenido directamente
  • Menos complejidad operativa. No hay que mantener un servidor de Node.js adicional, ni un CDN para assets, ni un pipeline de build

Lo que pierdo: interfaces ultra-interactivas tipo aplicacion nativa. Pero mis clientes son negocios locales — doctores, abogados, empresas de servicios. Necesitan dashboards funcionales, no animaciones de Silicon Valley.

Base de datos: PostgreSQL

PostgreSQL. Sin ORM pesado, sin base de datos NoSQL, sin servicios gestionados caros.

Es la base de datos mas versatil que existe. Maneja datos relacionales, JSON, busqueda de texto completo, y extensiones especializadas que me permiten hacer cosas que normalmente requeririan servicios externos adicionales.

Cada cliente de Lisssto! vive en la misma base de datos, aislado por su identificador. Multi-tenant simple. Sin complejidad de bases de datos separadas por cliente.

Infraestructura: un VPS, Docker, y un reverse proxy

Todo corre en un solo VPS. No uso Kubernetes, ni AWS, ni microservicios. Un servidor con Docker Compose orquestando los containers.

La arquitectura:

  • Reverse proxy al frente — maneja SSL automatico, ruteo por dominio, y redireccion HTTP a HTTPS. Cada cliente puede tener su dominio propio apuntando al mismo servidor
  • Containers Docker — la aplicacion, la base de datos, el cache, y los sitios web estaticos de clientes, cada uno aislado en su container
  • Red interna — la base de datos y el cache estan en una red que no tiene acceso a internet. Solo la aplicacion puede hablar con ellos
  • Blue-green deployment — dos instancias de la aplicacion corriendo en paralelo. Cuando despliego una version nueva, el trafico cambia de una a otra sin downtime

Por que no "la nube": A mi escala actual, un VPS de $30/mes es mas que suficiente. AWS o GCP me costarian 5-10x mas por la misma carga, con la complejidad adicional de decenas de servicios que configurar y mantener. Cuando tenga 500 clientes, migro. Hasta entonces, un servidor es perfecto.

Automatizacion: scripts, no IA

Esto lo explique en detalle en mi post sobre metodologia, pero vale repetirlo aqui en el contexto del stack.

Tengo mas de una docena de tareas automatizadas corriendo en el servidor: backups, recordatorios a clientes, monitoreo, limpieza de datos, sincronizacion. Ninguna usa inteligencia artificial. Son scripts de Python y Bash ejecutados por timers del sistema operativo.

Un agente de IA me ayudo a crearlos. Pero una vez creados, corren solos. Sin tokens, sin APIs de IA, sin costos variables.

La IA entra unicamente donde se necesita criterio: el chatbot que habla con los clientes de mis clientes, la generacion de contenido, y el analisis de datos. Para todo lo demas, un if/else bien escrito es mas confiable, mas rapido, y gratis.

Sitios web de clientes: HTML estatico

Los sitios web que Lisssto! genera para sus clientes son HTML estatico servido por Nginx. No hay un CMS, no hay WordPress, no hay un servidor de aplicacion detras de cada sitio.

Ventajas:

  • Velocidad maxima (no hay nada mas rapido que un archivo HTML)
  • Seguridad maxima (no hay base de datos que hackear, no hay login de admin, no hay plugins vulnerables)
  • Costo marginal por cliente: practicamente cero
  • Si el backend de Lisssto! se cae, los sitios de los clientes siguen funcionando

El dashboard de Lisssto! genera y publica estos sitios. El cliente edita su contenido en el dashboard, y el sistema genera el HTML optimizado y lo despliega automaticamente.

Backups: tres capas, cero confianza

Mi politica de backups parte de un principio simple: si no tienes al menos dos copias en lugares diferentes, no tienes backup.

Tengo tres capas:

  1. Backup diario a la nube — automatico, con retencion de una semana
  2. Backup local comprimido — automatico, con retencion de dos semanas
  3. Snapshots de version — automaticos antes de cada cambio hecho por un agente de IA

Los tres corren sin intervencion humana. Los dos primeros se ejecutan por timers del sistema operativo. El tercero esta integrado en el flujo de trabajo de los agentes.

Lo que no uso (a proposito)

  • React / Vue / Angular — complejidad innecesaria para mi caso de uso
  • TypeScript — una capa mas de build que mantener. Python con type hints es suficiente
  • Kubernetes — a mi escala es como matar un mosquito con un cañon
  • Servicios gestionados (RDS, CloudFront, etc.) — costo desproporcionado para mi escala actual
  • ORMs pesados — prefiero SQL directo. Es mas transparente y los agentes lo escriben mejor
  • n8n / Zapier / Make — los reemplace por scripts. Mas control, menos dependencias, cero costos recurrentes
  • WordPress — para los sitios de clientes, HTML estatico es superior en todo sentido

El resultado

Con este stack opero una plataforma que sirve a multiples negocios, genera sus sitios web, maneja sus chatbots, automatiza sus recordatorios, y gestiona su presencia digital. Todo desde un servidor de $30/mes.

No es el stack mas elegante. No es el mas moderno. Pero funciona, es mantenible por una persona asistida por agentes de IA, y me deja dormir tranquilo.

Al final, la mejor tecnologia no es la que esta de moda. Es la que te permite enfocarte en tu negocio en lugar de en tu infraestructura.

Nota: por razones de seguridad, omito deliberadamente detalles de configuracion interna, versiones especificas, y mecanismos de proteccion. Lo que comparto aqui es la filosofia y las decisiones de arquitectura, no un manual de replicacion.