← ☕︎ mmaria · EzpelZaintza2050 · Estrategia de delivery software · agosto 2026
Fase 1 · Prioridad nº 1

Estrategia de delivery

Cómo evitar que el proyecto funcione en la pantalla del desarrollador y no en la de EzpelZaintza. Se decide y se valida desde el primer día, no en las últimas semanas.

Hay dos tipos de experiencia con software descargado de GitHub o Hugging Face: la de HandBrake, Demucs GUI o XnConvert, que se abren y funcionan a la primera — y la de proyectos que exigen montar un entorno con Conda/Anaconda/Miniconda a mano, donde arreglar una dependencia rompe otras tres. La diferencia entre ambas casi nunca está en la calidad del código: está en cómo se empaqueta y se entrega.
Funciona a la primeraUn único instalador o ejecutable — en este proyecto, uno que arranca el servidor local y abre el navegador solo. Todo lo necesario va dentro. Cero pasos técnicos para quien lo usa.
Pesadilla de dependenciasCódigo fuente + "instala esto primero". El usuario monta su propio entorno y hereda cada conflicto de versión.
Objetivo central
🎯 Delivery success
EzpelZaintza abre la app en navegador y funciona, a la primera, sin ayuda
1

Arquitectura recomendada: app local para navegador

En vez de una app de escritorio "nativa" (con su propia ventana, su propio framework gráfico, su propia compilación por sistema operativo), el programa arranca un servidor pequeño en el propio ordenador y se usa desde el navegador que EzpelZaintza ya tiene instalado y ya conoce — el mismo con el que abre Kaleidoscope o BuscaBoj.

Sigue haciendo falta empaquetar ese servidor en un único ejecutable para que no tenga que instalar nada a mano, pero es una superficie de empaquetado mucho más pequeña: sin framework gráfico nativo, el mismo código de interfaz sirve en Windows y Mac casi sin cambios. Al ser local —no una web alojada en internet— el servidor tiene acceso normal al disco para leer la tarjeta SD y guardar el dataset, sin las limitaciones de una página web de verdad.

Por qué importa: convierte "empaquetar una app gráfica completa" en el problema mucho más pequeño de "empaquetar un servidor sin interfaz", justo lo que mejor empaquetan herramientas como PyInstaller.
2

Volumen de audio y almacenamiento

Una grabación en el canal audible (48kHz, el que importa para el masticado) pesa, sin comprimir, unos 300-350 MB por hora. Si el grabador captura a la vez el canal ultrasónico, esa cifra puede multiplicarse por diez o más — conviene confirmarlo mirando la configuración real de grabación de EzpelZaintza, no asumirlo.

Es aventurado asumir que EzpelZaintza trabaja con un portátil, o que tiene espacio libre de sobra en el disco que use — podría ser un equipo de sobremesa, y podría tener el disco ocupado. Por eso el diseño deja que sea ella quien elija cuál es el almacenamiento principal y cuál la copia de seguridad: disco local + Cloudflare R2 como backup periódico, o al revés, R2 como principal + disco local como copia de trabajo reciente. R2 encaja en cualquiera de los dos papeles, con una precisión importante: su capa gratuita (10 GB) alcanza para las notas del inbox, no para todo el audio — un dataset de decenas o cientos de GB la superará. Aun así, R2 de pago sigue siendo barato (~0,015 €/GB al mes) y no cobra por descargar los datos, importante el día que haya que bajarlos todos para entrenar un modelo. Se recomienda además un disco duro externo físico como copia adicional — gasto de hardware aparte, no incluido en este presupuesto.

3

Ficha técnica del ordenador — desde hoy, no al final

Antes de escribir nada, se le pide a EzpelZaintza la configuración exacta de su equipo.

  • Sistema operativo y versión exacta
  • Arquitectura del procesador (Apple Silicon / Intel, si es Mac)
  • ¿Tiene permisos de administrador para instalar programas?
  • ¿Es un equipo institucional con antivirus o políticas restrictivas?
  • Espacio libre en disco
  • Conexión a internet disponible en el momento de instalar
4

Un solo ejecutable, cero configuración

Se decide antes de escribir la primera función, no se improvisa al final. Todo el intérprete y las librerías van empaquetados dentro del programa. Nunca se entrega código fuente con un "instala esto primero".

Si se ignora: exactamente el escenario de Conda rompiéndose por un sitio, apañado, roto por otro.
5

Cero dependencias de ML/GPU — ya resuelto por diseño

La causa más habitual de infierno de dependencias (drivers de GPU, versiones de librerías de IA) no existe en el alcance de esta fase: no hay entrenamiento de modelo aquí. Ese riesgo ya se eliminó al fijar el alcance.

6

"Hola mundo" empaquetado en la semana 1

Antes de construir ninguna función real, se empaqueta una versión mínima —una ventana que se abre y ya— y se prueba que llega e instala bien. Si el canal de entrega falla, se descubre con una semana perdida, no con seis.

7

Compilar en el mismo sistema operativo de destino

Nunca generar el paquete de Windows desde un Mac (o al revés) confiando en que "algo cruzado funciona". Se construye en el mismo sistema operativo que va a usar EzpelZaintza.

8

Probar en una máquina limpia, nunca solo en la de desarrollo

El ordenador donde se programa tiene de fondo herramientas ya instaladas que esconden dependencias que en realidad faltan. Antes de entregar, se prueba en un equipo (o máquina virtual) sin nada preinstalado.

9

Avisos de seguridad esperados, no sorpresa

Windows y macOS van a mostrar advertencias sobre software sin firmar la primera vez que se abra. Se prepara de antemano una instrucción sencilla, con captura de pantalla, de cómo continuar — para que no sea un susto que la haga abandonar.