Veintiocho sistemas, descritos con sinceridad.

Django 5.2, PostgreSQL y MariaDB, renderizado en servidor, sin SPA. Alrededor de 120 modelos en catorce aplicaciones y 170 plantillas. Deploy en hosting compartido bajo Passenger, con cron en lugar de Celery porque allí ningún proceso en segundo plano sobrevive.

Conversions API del lado del servidor con deduplicación frente al Pixel del navegador mediante un event id compartido, datos personales hasheados, enviado en un hilo en segundo plano y con fail-open. Drivers de impresora fiscal con un modo degradado de driver nulo, de modo que un dispositivo inalcanzable marca el ticket como pendiente en lugar de bloquear la venta. Una API con bearer token para un cliente Windows de control horario que vive fuera del repositorio y sube instantáneas de actividad minuto a minuto. Un sistema de roles resuelto por prioridad - superusuario, luego grupo, luego ficha de personal de la clínica - que alimenta diez dashboards distintos desde una sola base de código.

Django 5.2, PostgreSQL, Stripe, constructor de páginas GrapesJS en el admin. Veinticinco modelos repartidos en cuatro aplicaciones con modelos.

El backend de IA vive detrás de un único tipo de resultado normalizado con tres implementaciones intercambiables - mock, API alojada y self-hosted - seleccionadas por una sola variable de entorno, de modo que el producto entero funciona de principio a fin sin ningún proveedor de IA conectado y sin cambios de código. Un pipeline clínico de subida → análisis → hallazgos → plan de tratamiento → líneas de presupuesto, y cada hallazgo lleva su propia banda de confianza. Middleware de atribución first-touch que captura cuatro click ids de plataformas publicitarias en un informe de embudo de lead a cliente de pago.

Django 5.2, MySQL, modeltranslation en tres aplicaciones, CKEditor 5, constructor de landings GrapesJS.

Una máquina de estados de solicitud a aprobación para las citas: la solicitud de un visitante queda pendiente hasta que el personal la aprueba, momento en el que se crea o se empareja una ficha de paciente y se materializa una cita real. Cada lead guarda sus respuestas dos veces - como JSON y como filas individuales - junto con IP, user agent, referrer, geografía y el conjunto completo de UTM y click ids de Meta. Las landings de campaña se montan fuera del enrutado con prefijo de idioma, así que el tráfico de pago nunca cae en un redirect de locale.

Django 5.2 con DRF y JWT, PostgreSQL, Celery y Redis, hashing Argon2, cuarenta y nueve aplicaciones locales. React con Vite y Tailwind en el front, Flutter para móvil. Sentry, gunicorn con gevent.

Un motor de recomendación que clasifica siete estados del sistema nervioso a partir de un check-in, aplica filtros duros de elegibilidad, comprime la prioridad en una banda de seis puntos para que el contexto gane a la popularidad, y luego muestrea por softmax en vez de tomar el argmax - así todo el catálogo sigue siendo alcanzable en lugar de colapsar sobre los mismos veinte elementos. Un cuarto hueco queda reservado al descubrimiento y se muestrea por recencia. Usa consultas directas a través del driver en lugar del ORM, porque se ejecuta en cada pantalla. El retrieval está anclado en unas treinta mil soluciones estructuradas extraídas de unos noventa y cinco libros, con un prompt que prohíbe al modelo responder desde su propio conocimiento general y una rama explícita para situaciones de crisis. Un harness Monte Carlo ejecuta el motor real sobre sesiones sintéticas - cincuenta mil check-ins en una ejecución, setenta mil sesiones equilibradas en otra - comprobando que ningún estado de crisis recibe una tarjeta inadecuada y que ninguna tarjeta queda inalcanzable. También sacó a la luz una carencia real de detección, que es justo para lo que sirve un harness. La elección de proveedor y cada clave de API se resuelven desde una tabla editable en el admin antes de recurrir a las variables de entorno, así que proveedores y claves rotan sin deploy.

Django 5.1, MySQL en producción con PostgreSQL y SQLite como alternativas para desarrollo, Celery y Redis con fallback eager, bloqueo con django-axes, profiling con Silk, constructor GrapesJS. Cuarenta modelos repartidos en seis aplicaciones.

La finalización del pago está deliberadamente duplicada y es idempotente - la misma rutina se ejecuta desde el webhook de Stripe y desde la página de retorno, y sale de inmediato si la reserva ya está pagada, así que un webhook que no llega no puede hacer perder una reserva pagada. El channel manager no ofrece ningún esquema de firma para webhooks, así que el endpoint se autentica con un secreto en la ruta de la URL, con un test que lo deja vacío para demostrar que es fail-closed. Una máquina de estados de reservas envía las estancias confirmadas al canal directo y los bloqueos a otro aparte; la propiedad sin id de canal se empareja localmente por slug. Cada correo saliente se persiste antes de enviarse, mediante un backend de correo propio.

Django 5.1, MySQL, Celery con fallback eager y Redis opcional, admin Unfold con un studio incluido en el repositorio, HTMX y Alpine sobre Tailwind. Alrededor de cuarenta modelos en diez aplicaciones. Flutter para los dos clientes móviles, JWT en secure storage.

Un checkout en curso se guarda como reserva temporal y solo se convierte en reserva real cuando Stripe confirma la sesión, así que un checkout abandonado nunca retiene inventario. Seis tipos distintos de documento fiscal comparten mixins comunes de partes y de líneas, en lugar de ser un único modelo de factura con un flag de tipo. Las fichas de huésped se concilian entre canales mediante una capa de huésped canónico, con registros separados para personas físicas y para empresas, así que la misma persona que llega desde una OTA y desde una reserva directa es una sola ficha. Cada secreto de integración se resuelve primero desde la base de datos, con una caché de sesenta segundos, así que las claves rotan en caliente.

Django 5.0, MySQL, modeltranslation en ocho idiomas, Tailwind y Alpine desde CDN sin paso de build. Treinta y ocho modelos.

Confirmación de la reserva mediante un código de seis dígitos enviado por correo, con límite de peticiones por IP, tope de cinco intentos, caducidad a los quince minutos y cooldown de reenvío. Unos tokens firmados y limitados en el tiempo dan a un visitante anónimo acceso a su propia página de reserva durante veinticuatro horas, sin cuenta. El precio se recalcula en el servidor en cada guardado, a partir de una tabla de cinco tramos de días cruzada con el nivel de seguro, con el descuento aplicado solo al subtotal del alquiler - nunca se acepta el que llega del cliente.

Django 5.1, MySQL, Redis y Celery, DRF con JWT y OpenAPI, admin Unfold, modeltranslation y parler. Una aplicación React 19 construida con Vite y entregada ya compilada. Catorce aplicaciones, siete idiomas con catálogos de traducción completos.

Puntuación de leads con un modelo de lenguaje que busca en la web: las respuestas del formulario, las UTM, los click ids, el resultado de la autenticación y el estado do-not-call se reúnen en un dosier y se puntúan en una banda, con una justificación y una acción recomendada, usando una clave por cliente. Un stack de cumplimiento en tres partes - scrub completo con detección de tipo de línea y de números móviles, comprobación de litigantes y búsqueda de número reasignado contra la fecha de consentimiento. El tenant se resuelve desde la cabecera Host con una caché de cinco minutos, y cada envío de formulario se vuelve a comprobar contra el cliente de ese host, así que un lead que cruce de un tenant a otro es estructuralmente imposible. El constructor de formularios guarda un HMAC de cada código de verificación en lugar del código, y cada casilla de consentimiento escribe un registro inmutable con el texto exacto, la IP y la URL.

Django 5.2 con Wagtail, dos almacenes de datos - PostgreSQL para el estado operativo y ClickHouse como firehose de tracking - Redis, Celery con beat y Flower, DRF más una capa JWT escrita a mano para móvil. Cuarenta y seis modelos solo en la aplicación central.

Cada proveedor se asigna a una de tres subpuntuaciones - contactabilidad, autenticidad, intención - ejecutadas en paralelo mediante un thread pool y promediadas en una nota compuesta con pesos ajustables desde el admin. Los adaptadores que fallan o se saltan salen del denominador en lugar de puntuar cero, y cualquier adaptador bloqueante impone directamente la nota más baja. El conjunto de señales incluye biometría de comportamiento, fingerprinting de TLS, profundidad de scroll y cadencia de escritura en el formulario, junto con tres subseñales de modelos de lenguaje. El enrutado a compradores filtra por crédito, horario de trabajo, capacidad diaria y semanal, vertical y geografía, y luego desempata por la carga de las últimas veinticuatro horas antes que por prioridad. Cada llamada saliente a un proveedor escribe una fila de log con endpoint, estado y resumen de la respuesta, precisamente para poder conciliar el coste de proveedor por lead.

Flutter con Riverpod, Dio y go-router, secure storage para los tokens. Una aplicación Django complementaria que expone el registro del admin como REST.

Los permisos no se reimplementan: la API mapea los verbos HTTP sobre los propios permisos de Django - view, add, change y delete - y la búsqueda, la paginación y el orden de las listas salen directamente de la configuración de cada clase de admin. Añadir un modelo al admin de Django lo añade a la app móvil. Una app hermana para compradores refleja los catorce conjuntos de tema por cliente de la aplicación web, leyendo el activo al iniciar sesión y cacheándolo para que no haya un destello de identidad visual equivocada en el arranque en frío.

Django 5.2 con Wagtail, MySQL, Redis, Celery con beat, Channels y Daphne para WebSockets, DRF con JWT, pandas y numpy, web3 para la vía cripto. Flutter y Dart para los clientes móvil y de escritorio, un único lib/ compartido por los tres. Diecisiete idiomas configurados.

Siete lecturas independientes de indicadores por timeframe, y un timeframe solo está de acuerdo cuando al menos cinco de las siete coinciden - y por encima, confirmación multi-timeframe, con filtros opcionales de candlestick y de noticias y con stops y objetivos derivados del ATR. Cada pasada escribe una fila de auditoría, haya producido señal o no, y el dry-run es el modo por defecto. La vía de pago cripto no guarda ninguna clave privada en el servidor: una tarea programada vigila la cadena en busca de transferencias a una dirección de cobro, empareja los depósitos pendientes por importe y confirma tras doce confirmaciones. Dos middlewares apilados dejan el producto inalcanzable hasta que el onboarding está de verdad completo.

Django 4.2, MySQL, admin Unfold con un dashboard en Chart.js, modeltranslation en ocho idiomas, Tailwind y Alpine desde CDN. Sesenta y dos modelos en nueve aplicaciones, sesenta y tres tablas.

La cadena de fulfilment es real y no declarativa: la generación de la guía de envío registra la petición completa, la respuesta y el error contra el pedido, y la facturación emite documentos y rectificativas contra él. El precio en dos monedas guarda el importe nativo y el importe mostrado como par, en vez de un importe y un tipo de cambio, así que un pedido antiguo no se reprecia en silencio cuando se mueve el tipo de cambio.

Django 4.2, MySQL, admin Unfold, ReportLab con una tipografía registrada a medida para componer los PDF. Cincuenta y cinco modelos.

El cuerpo del contrato es una plantilla legal estructurada que se numera sola, congela los datos del beneficiario en el momento de la firma y valida que un contrato se vincule a una persona física o a una empresa, pero nunca a las dos. Los PDF de oferta se componen habitación por habitación - ocho tipos de estancia, cada uno con su descripción, precio y fotografías - como documento maquetado y no como plantilla rellenada. Cada importe se guarda en las dos monedas, en columnas paralelas.

Django 5.2, MySQL, admin Unfold con plantillas propias de calendario y de hoja de horas. El cliente de escritorio es Tkinter - unas 1.600 líneas - empaquetado con PyInstaller en un solo ejecutable y distribuido mediante un instalador.

La parte interesante es la lógica de salida automática: una sesión se cierra en su último heartbeat solo cuando ya ha pasado el fin de jornada previsto y no ha llegado ningún heartbeat durante diez minutos - y un heartbeat posterior que lleve una marca de tiempo de aplicación viva puede revivir una sesión que un corte real había cerrado. Eso es un problema de estado distribuido tratado como se debe, y no un cron nocturno que adivina.

Laravel 11 con Breeze, MySQL, Blade con Vite, Tailwind y Alpine, DomPDF. Once modelos, dieciocho migraciones.

Nada arquitectónicamente inusual, y tampoco tiene por qué fingir lo contrario: es una herramienta interna pequeña y correcta. La pieza con sustancia es el dashboard de pipeline, que agrega los recuentos por tipo de espacio y uso, la distribución por tramos de superficie y el presupuesto medio frente al valor total y cobrado de las proformas.

Django 4.2, MySQL, admin Unfold, modeltranslation en diez idiomas, Tailwind y Alpine. Alrededor de treinta modelos. Un plugin complementario para una herramienta de diseño, fuera del runtime de Django.

El pipeline toma el código fuente pegado, genera a partir de él diagramas de arquitectura y de flujo, y luego construye una especificación de pantallas y paleta que un plugin de una herramienta de diseño descarga y dibuja como frames reales y editables. Es una herramienta pequeña, pero elimina la hora menos agradable del comienzo de cualquier proyecto.

Solo la biblioteca estándar de Python. Sin framework, sin dependencias, sin paso de build, unas 920 líneas. El servidor es el propio servidor HTTP de la biblioteca estándar, con una cola de trabajos en hilos.

Gestiona correctamente la autenticación de dos niveles del proveedor - credenciales de servicio para emitir credenciales de cliente, y luego credenciales de cliente para generar, cacheadas y reutilizadas - y trata la generación como algo de verdad asíncrono, consultando cada trabajo en su propio hilo y con timeout. Si no hay credenciales configuradas, la interfaz desactiva la generación y lo dice, en lugar de fallar en el momento de usarla.

PHP y Laravel 8 con Jetstream y Livewire, MySQL, plantillas Blade, Laravel Mix compilando Tailwind, Bootstrap, jQuery, Alpine y Sass. Trece modelos, veintinueve migraciones, treinta y dos controladores, Apache sobre cPanel.

La traducción vive en el esquema y no en un paquete: los modelos de entrada, tienda, galería y menú llevan cada uno cuatro conjuntos paralelos de columnas, uno por idioma, y el rumano llegó cinco años después del lanzamiento mediante migraciones que ensanchan todos ellos. Es un diseño más tosco que una tabla de traducciones, y tiene una virtud real - leer una fila traducida es exactamente la misma consulta que leer una sin traducir, sin join y sin lógica de fallback que se pueda hacer mal. Merece decirse sin rodeos: esto es un monolito CRUD convencional sobre un stack que ha envejecido. Lo que demuestra no es ingenio, sino que se ha mantenido discretamente durante años después de la entrega.

Django 4.2, MariaDB, admin Jazzmin con inlines anidados, modeltranslation y Rosetta para editar las traducciones en el navegador, Bootstrap y AOS. Treinta modelos. Cuatro contenedores: nginx, web, base de datos y un scheduler.

El emisor de campañas calcula cuántos intervalos han pasado desde la hora de inicio y envía el siguiente lote de diez destinatarios, registrando el progreso y escribiendo un log de entrega con un message id generado por destinatario - un ritmo de envío pensado para sobrevivir en un servidor de correo compartido en vez de dar por supuesto un proveedor de envío. Después, una tarea horaria consulta IMAP, parsea las notificaciones de rebote y las concilia con esos logs de entrega por message id. Debajo, antiabuso por capas: trampas honeypot en URLs que bloquean la IP de origen durante treinta días, una lista de bots no deseados y límites de peticiones por vista.

HTML estático con Tailwind compilado en una sola hoja de estilos, módulos de JavaScript sin librerías, un único endpoint PHP para el formulario de contacto. Apache en hosting compartido.

El endpoint de correo habla SMTP directamente - abre un socket TLS y hace él mismo el handshake de autenticación, sin ninguna librería de correo - porque el hosting no ofrecía ninguna alternativa usable. La analítica es de verdad consent-first: la etiqueta no se carga en absoluto hasta que el consentimiento está guardado, además respeta Do-Not-Track y se niega a ejecutarse fuera del hostname de producción. La escritura de derecha a izquierda se resuelve en la fuente de Tailwind y no se añade como una segunda hoja de estilos, y cada URL declara sus alternativas de idioma.

Django 4.2, MySQL, admin Unfold, modeltranslation. PayPal llamado directamente por REST en vez de a través de un SDK.

Un patrón de CMS con modelos singleton, en el que cada una de las cerca de veinte secciones de página se crea su propia fila en la migración, así que un editor nunca abre el admin sobre una pantalla vacía ni tiene que saber qué es un fixture. Todas las claves de terceros viven en una caja fuerte en la base de datos y no en archivos de entorno, que es la elección correcta para un cliente que cambia de proveedor más a menudo de lo que hace deploy.

HTML estático. Sin framework, sin base de datos, sin paso de build - la respuesta correcta para un catálogo que cambia dos veces al año y tiene que durar más que la ventana de soporte de cualquier framework.

Nada, y esa es precisamente la idea. No todo encargo es un sistema, y un sitio estático que el cliente puede alojar en cualquier sitio durante una década es aquí mejor resultado que un CMS en el que nadie va a entrar.

Django 4.2 con django-unfold, MySQL vía PyMySQL, modeltranslation en ocho idiomas, CKEditor para los campos largos, Tailwind y Alpine cargados desde un CDN sin paso de build, Whitenoise, Passenger sobre cPanel. Treinta y dos modelos en tres aplicaciones.

Nada de esto es difícil, y la entrada se gana su sitio demostrando la habilidad opuesta: un sitio cuyo propietario no necesita nunca a un desarrollador para cambiarle una palabra. El defecto, dicho con honestidad, se ve en el esquema - el modelo de portfolio todavía lleva un campo de superficie y otro de ubicación heredados de la plantilla inmobiliaria de la que se hizo el fork, y alrededor de un tercio de la lista de dependencias viene arrastrada de allí y no se importa nunca. Eso es lo que cuesta de verdad hacer fork de un proyecto que funciona para ahorrar una semana, y prefiero enseñarlo antes que sacarlo del relato.

Vue 3 con la Composition API, Vue Router, Vite con chunking manual de dependencias, Tailwind, GSAP, iconos Lucide. Unas seis mil trescientas líneas en ocho rutas, una de ellas una página de design system. Apache sirviendo la salida del build.

Doce componentes de animación, uno por servicio, escritos y no sacados de una librería, con composables de intersection observer y de conteo ascendente debajo. Es trabajo de artesanía y esa es toda su ambición. También lleva el ejemplo más claro que tengo de una dependencia que sobrevive a su propósito: reCAPTCHA v3 se carga en cada página y no protege nada, porque en el sitio no hay ningún formulario - la ruta de contacto es un enlace mailto, y la librería de validación instalada para el formulario que nunca se construyó sigue en el manifiesto. Un script de terceros que se ejecuta en cada carga de página y no hace nada es un problema de consentimiento y no un resto inofensivo, y está en la lista de cosas a quitar.

Solidity 0.8.24 con OpenZeppelin 5.1 fijado exactamente, Hardhat y ethers v6, Node 20 para el relayer y el faucet, Terraform y Docker Compose para la flota de validadores, un stack Blockscout incluido en el repositorio y detrás de nginx para el explorador, JavaScript sin librerías para las dApps y el wallet, Rust y Anchor para la rama de Solana. 3.500 líneas de Solidity original, 12.000 de JavaScript, 142 tests de contrato en cuatro suites.

Un único archivo de asignación es la fuente de verdad para los cien millones de suministro, y el build genera a partir de él el genesis, los directorios de compose por rol y los scripts de deploy, igual para devnet, testnet y mainnet - así las tres redes no pueden desviarse entre sí. Un paso de preflight se niega a construir un genesis de mainnet mientras quede alguna dirección de relleno. El faucet reimplementa el propio protocolo WebSocket del cliente de nodo para que la página no necesite ningún caso especial para redes locales. El relayer avanza su cursor de bloques solo después de que cada mensaje de un rango esté persistido, porque avanzar antes pierde transferencias para siempre y no hay nada que reescanee. La conservación del suministro es un invariante de diseño y no una comprobación: exactamente una cadena mantiene el escrow y todas las demás acuñan, el tope del token es igual al suministro del genesis, y los scripts de deploy no acuñan nada. La versión de OpenZeppelin está fijada porque la 5.2 emite un opcode posterior a la EVM del nodo - una librería más nueva produciría bytecode que sus propios validadores no podrían ejecutar. El bridge es un bridge de quórum de confianza y se describe como tal en tres sitios distintos, en lugar de llamarlo trustless.

Python 3.11 con pandas y numpy, con versiones acotadas a propósito para que las wheels precompiladas se instalen en hosting compartido sin compilador. SQLite para el diario de operaciones, MySQL para exportar, el propio servidor HTTP de la biblioteca estándar para el dashboard. 18.000 líneas en 94 módulos y 541 tests.

El modelo de lenguaje corre en su propio reloj en segundo plano y escribe una caché que el bucle de trading lee al instante, porque una ida y vuelta de uno a tres segundos sobre barras de cinco segundos significa actuar sobre un precio que ya no existe - y ese fallo es silencioso, porque la respuesta sigue pareciendo razonable. Puede emitir un sesgo y dos multiplicadores; no puede inventar una operación, ni elegir una dirección, ni dimensionar una posición, ni mover un stop, y ante un fallo vuelve a neutral. La capa de aprendizaje es una regresión logística escrita a mano precisamente para que no pueda esconder el overfitting: in-sample y out-of-sample siempre se reportan juntos, las divisiones respetan el orden temporal, y al lado se imprime una línea base ingenua que toma todas las operaciones. Las salidas se disparan con el precio del subyacente y no con la prima de la opción, porque la prima se mueve por volatilidad y por el paso del tiempo. El supervisor usa un lock de fichero después de que dos ejecuciones lanzadas con segundos de diferencia se colaran por una comprobación de pidfile y dejaran dos bots operando en la misma cuenta.

Django 4.2, django-unfold, MySQL, modeltranslation en diez idiomas, CKEditor, Tailwind y Alpine desde un CDN, Passenger sobre cPanel. Treinta modelos en tres aplicaciones, más un plugin de Figma complementario.

El generador para Figma construye su árbol de nodos de forma determinista - frames, rectángulos y texto colocados por código - y solo después ofrece una pasada opcional por un modelo para embellecerlo. Ese orden es todo el diseño: el mismo proyecto produce siempre el mismo layout, y el modelo puede mejorar el resultado pero nunca es la razón de que exista. El plugin descarga su especificación mediante una URL de admin firmada, así que la app de escritorio de Figma puede traerse un diseño sin mantener una sesión. Dos huecos que no voy a fingir que están terminados: la parte de push de la integración con Figma sigue siendo un stub, y el cliente de OpenAI se importa sin estar fijado en las dependencias, así que una instalación limpia de ese panel falla hasta que se añade.

Python 3.11 y Django 5.2 LTS, django-unfold, MySQL vía PyMySQL, Redis, Celery con beat, resultados y Flower, Strawberry GraphQL con la extensión de optimización para Django, modeltranslation, Silk solo en desarrollo, React 18 y Vite para la isla de front-end. Diez aplicaciones, treinta y tres modelos, unas ocho mil doscientas líneas de Python.

El seguimiento de conversiones se dispara dos veces a propósito: el pixel del navegador y la API del lado del servidor envían el mismo evento bajo el mismo event id, así que la plataforma los deduplica, y los eventos que los bloqueadores borrarían de otro modo - normalmente entre una quinta y dos quintas partes - sobreviven. Los campos personales se hashean antes de salir, y un fallo de tracking se absorbe en lugar de propagarse, porque vale más un lead que un lead perfectamente reportado. El motor de formularios son nueve modelos y doce tipos de pregunta sobre un funnel de cinco estados, con un rastro de auditoría por eventos; sus endpoints públicos están exentos de CSRF a propósito, porque el markup se escribe en el admin y se sirve tal cual, y un id de sesión emitido por el servidor e imposible de adivinar hace el trabajo que habría hecho el token. Cada restricción de versión del fichero de dependencias lleva el motivo por el que existe, incluidas las que preferiría no necesitar. El punto débil es la cobertura: veintitrés tests de humo para ocho mil líneas, que no es suficiente y lo sé.