Tras detallar la interfaz del participante y la lógica de gestión en el panel de coordinación, llegamos al núcleo que sostiene la aplicación: el modelo de datos relacional en Neon PostgreSQL.

Para garantizar que el MVP fuera robusto y fácil de mantener a largo plazo, estructuré la información en tres tablas principales con responsabilidades bien separadas.

Diseño de la Base de Datos: Tres tablas relacionales

1. Tabla usuarios (Entidad central y control de acceso):

   • id: Identificador único (Clave primaria).
   • nombre / email: Datos de identificación del usuario.
   • password_hash: Contraseña encriptada mediante algoritmo seguro (Bcrypt).
   • rol: Perfil asignado (participante o coordinacion).

2. Tabla fichajes (Registros de tiempo cuantitativos):

   • id: Clave primaria.
   • usuario_id: Clave foránea vinculada a la tabla de usuarios.
   • fecha_inicio: Marca de tiempo (timestamp) de entrada con zona horaria.
   • fecha_fin: Marca de tiempo de salida (nula mientras la sesión está activa).

3. Tabla tarifas_mensuales (Acuerdos económicos y herencia):

   • id: Clave primaria.
   • usuario_id: Clave foránea asociada al participante.
   • anio / mes: Periodo al que aplica el acuerdo.
   • precio_hora: Tarifa acordada (€/h) fijada por la coordinación.

Ventajas Clave de la Estructura

• Trazabilidad de roles: La separación por roles asegura que un participante solo interactúe con sus propios fichajes, mientras que la coordinación accede al resumen global.
• Flexibilidad sin redundancia: Al independizar la tabla de tarifas_mensuales del registro diario de fichajes, es posible ajustar el precio por hora de un mes entero sin modificar los registros pasados.
• Consultas eficientes: Las métricas mensuales se calculan mediante consultas agregadas directas a la base de datos, optimizando la memoria de la aplicación.

Código fuente: Puedes consultar la implementación en Python, las consultas SQL y la configuración del proyecto en GitHub.

Limitaciones y Fricciones del MVP Actual

Al tratarse de una primera versión orientada a validar la adopción del sistema, asumí deliberadamente algunas limitaciones para mantener el desarrollo ágil:

• Alta manual de usuarios: No existe un flujo público de registro (sign-up). Las cuentas de usuario y sus roles se crean manualmente por administración. Si el proyecto tiene buena acogida, se implementará un flujo de autoregistro y recuperación de credenciales.
• Tiempo de encendido (Cold Start): Debido a la arquitectura serverless en las capas gratuitas, tras periodos de inactividad la aplicación puede tardar unos 10-15 segundos en despertar al recibir una nueva petición.

Próximas Mejoras (Roadmap)

De cara a evolucionar la herramienta más allá de este MVP, las líneas prioritarias de mejora son:

1. Geolocalización en el fichaje: Capturar las coordenadas GPS (latitud y longitud) mediante la API del navegador en el momento exacto de iniciar y finalizar la sesión para validar la ubicación del servicio.
2. Generación de reportes en PDF: Complementar la exportación nativa en CSV con la descarga de resúmenes mensuales formateados en PDF para su entrega formal.
3. Notificaciones de olvido: Integrar avisos automáticos para alertar al participante si deja una sesión abierta durante más tiempo del habitual.

Conclusión Final

Este MVP demuestra cómo la combinación de Python, Streamlit Cloud y Neon PostgreSQL permite desplegar soluciones funcionales, profesionales y con coste cero de infraestructura. La inclusión de herramientas nativas de Streamlit —como la exportación directa a CSV, la búsqueda en tablas o el temporizador mediante @st.fragment— permitió acortar los plazos de desarrollo y entregar un producto 100 % operativo para el control de tiempo en entornos informales.