Desarrollo con Python y Django para SaaS, fintech y productos de datos

Django gana en tres ejes: un ORM maduro que gestiona esquemas complejos sin tener que recurrir demasiado a SQL en bruto, el Django Admin, operativamente indispensable para SaaS B2B y productos de operaciones internas, y un ecosistema (django-allauth, django-tenants, django-filter, DRF, Wagtail) que cubre el 80 % de las necesidades habituales de un SaaS sin que tenga que reinventarlas. Elija FastAPI para servicios puramente asíncronos de alta concurrencia. Elija Go para binarios limitados por CPU. Elija Rails solo si ya cuenta con experiencia en Ruby en el equipo: la distancia con Django es pequeña, pero la reserva de talento en la UE y EE. UU. en 2026 favorece claramente a Python.

Django 5.1 LTS es la opción por defecto para los desarrollos nuevos (LTS hasta abril de 2028), con Django 4.2 LTS para destinos de migración de sistemas heredados. Python 3.12 por defecto y 3.13 cuando el ecosistema se ponga al día (T3 de 2026 en nuestro caso). DRF 3.15+ con Spectacular para OpenAPI 3.1. mypy 1.11+ en modo estricto con django-stubs. Usamos uv para la gestión de dependencias y ruff para linting y formato; ambos han sustituido a pip-tools, black y flake8 en nuestra cadena de herramientas desde 2025.

Sí. El despliegue por defecto es AWS eu-central-1 / eu-west-1, GCP europe-west3 / europe-west1 y Azure germany-westcentral bajo petición. La PII en reposo se cifra con django-cryptography o pgcrypto, con claves de KMS custodiadas en la cuenta del cliente. Firmamos DPA del artículo 28 del RGPD, realizamos DPIA para los tratamientos de alto riesgo y mantenemos los registros del artículo 30. Para SOC 2 Type I/II entregamos el paquete de evidencias de controles: revisiones de acceso, gestión de cambios mediante PR, copias de seguridad cifradas, registros de auditoría y gestión de proveedores. Para los clientes de EE. UU. replicamos en us-east-1 / us-west-2 con controles de la CCPA y, cuando procede, de HIPAA.

A partir de unas 500 tareas/s en un único broker de Redis, repartimos las colas de Celery por tipo de carga, pasamos el fan-out pesado a Dramatiq o Temporal y adoptamos Redis Cluster o RabbitMQ con un ajuste correcto del prefetch. Monitorizamos con Flower más Sentry Cron y Datadog APM. Para la semántica exactly-once usamos el patrón outbox sobre Postgres en lugar de confiar en las garantías de entrega del broker. El mayor pipeline que operamos actualmente ejecuta 8M de tareas de Celery al día en un despliegue de EKS con 12 workers y una latencia p95 inferior a 1.2 segundos.

Sí; es uno de nuestros proyectos más habituales. Hacemos actualizaciones incrementales: 2.2 LTS → 3.2 LTS → 4.2 LTS → 5.1 LTS, con la batería de pruebas en verde en cada paso. Las actualizaciones de Python 3.7 → 3.8 → 3.10 → 3.12 se hacen en paralelo. Añadimos django-stubs y mypy estricto por app, no de forma global. El patrón strangler fig separa los contextos delimitados en servicios FastAPI o Django Ninja allí donde lo asíncrono o el escalado independiente lo justifican. Un monolito típico de 100k líneas de código tarda de 5 a 8 meses, sin tiempo de inactividad visible para los clientes.

El precio es de alcance cerrado y total, presupuestado en USD, sin recargo por intermediación ni sobrecostes por herramientas. Un MVP de aplicación web o un panel de cliente parte de $4,100 (4–8 semanas); un CRM o portal B2B, de $8,100 (8–12 semanas); una plataforma SaaS multi-tenant en producción, de $13,800 (más de 12 semanas); y un marketplace o desarrollo de alta carga, de $28,700. La cifra exacta depende de la superficie del modelo de datos y de administración, del número de integraciones, del perfil de rendimiento y del alcance del cumplimiento. Usted ve el presupuesto desglosado antes de que se escriba una sola línea de código y lo aprueba. Todos los proyectos incluyen jornada CET con solapamiento de 9:00–13:00 ET para clientes de EE. UU. y NDA + DPA + cesión de la propiedad intelectual firmados antes del arranque.

Sí, aunque el patrón importa. Para inferencia de baja frecuencia (<100 solicitudes/min) llamamos a un modelo de scikit-learn, XGBoost u ONNX directamente desde una vista de Django: es sencillo y no requiere infraestructura adicional. Para mayor rendimiento ejecutamos un servicio de inferencia FastAPI dedicado (con Uvicorn y el modelo cargado una sola vez al arrancar) tras un balanceador de carga interno, y la aplicación Django lo llama con httpx asíncrono. Para cargas intensivas en GPU (inferencia de LLM, generación de imágenes) desplegamos instancias separadas de Triton Inference Server o vLLM en nodos con GPU y las llamamos desde tareas de Celery para mantener rápida la ruta de la solicitud web. Los pipelines de características que alimentan los modelos pasan por Airflow o Prefect con transformaciones de dbt y salida a ClickHouse o Postgres para servirlas. Tenemos experiencia en producción con integraciones de OpenAI, Anthropic, Mistral y Llama autoalojado desde Django mediante los SDK estándar.

Pytest con factory_boy para los fixtures; evitamos el TestCase de Django cuando los fixtures transaccionales de pytest-django sirven mejor. El objetivo de cobertura es más del 80 % en la lógica de negocio y las vistas de la API; no perseguimos el 100 % en CRUD trivial. Pruebas basadas en propiedades con Hypothesis para la lógica de validación y los serializadores cuando el espacio de entradas es grande. Pruebas de contrato con Pact o un snapshot ligero de OpenAPI frente a los servicios dependientes para detectar cambios incompatibles sin ejecutar toda la dependencia. Pruebas de carga con Locust antes de cada versión importante, sobre todo del rendimiento de las colas de Celery y de los planes de consulta de Postgres bajo una concurrencia realista. mypy estricto detecta una clase de errores de ejecución en CI y no en producción. Cada PR ejecuta la batería completa en GitHub Actions (normalmente en menos de 4 minutos en un runner de gama media con paralelismo de pruebas mediante pytest-xdist).

Tratamos las migraciones como código crítico para producción. Cada migración se revisa en cuanto a la adquisición de bloqueos: añadir una columna con valor por defecto o una columna NOT NULL sin valor por defecto toma un bloqueo completo de la tabla en Postgres, lo que bloquea las lecturas en tablas grandes. Usamos django-pg-zero-downtime-migrations o escribimos migraciones manuales de varios pasos (añadir como nullable, rellenar por lotes con RunPython y establecer NOT NULL con una restricción de comprobación para evitar un escaneo completo). La creación de índices siempre se ejecuta con CONCURRENTLY. El squashing se hace de forma programada para mantener manejable el historial de migraciones. En el despliegue: las migraciones se ejecutan en un paso previo dedicado antes de desplazar el tráfico (blue/green o rolling) y mantenemos un plan de rollback probado (normalmente una migración inversa o un snapshot de datos) para cada migración que toca datos existentes. En la separación de un monolito en servicios con strangler fig, coordinamos los periodos de doble escritura y usamos feature flags para controlar las lecturas del servicio nuevo mientras la tabla antigua sigue siendo la fuente de verdad.

Tres modelos, elegidos al principio y no tras un incidente. Un periodo de garantía (normalmente 90 días, incluido en el precio de alcance cerrado) cubre sin coste adicional los defectos atribuibles a nuestra implementación. Un modelo de iguala le da un SLA definido de tiempo de respuesta (P1 <1 h, P2 <4 h, P3 al siguiente día hábil), actualizaciones mensuales de dependencias con Renovate, revisiones de consultas lentas de Postgres, controles del coste de la nube y un número fijo de horas por sprint para pequeñas funciones e integraciones. La ampliación de equipos (staff augmentation) mantiene de forma permanente a uno o dos ingenieros sénior integrados en su squad: su stand-up, su backlog, su proceso. Todos los modelos incluyen la documentación de traspaso de guardias (runbooks, paneles de SLO en Grafana, enrutamiento de PagerDuty) y una sesión de transferencia de conocimiento antes de reducir el tamaño del equipo.