Software cultural

// El problema

Un museo regional guarda sus fichas de objetos, imágenes y préstamos en un archivo de FileMaker creado hace veinte años, en un solo ordenador de la oficina, sin copia de seguridad y con un único registrador que sabe cómo funciona.

// Lo que construiríamos

Empezamos con una breve revisión de arquitectura del archivo antiguo y de cómo lo usa su registrador, y después trasladamos cada ficha, imagen y préstamo a un sistema web de gestión de colecciones con roles, un registro de cambios y copias de seguridad cada noche. Cada ficha trasladada se cuenta y se revisa con su registrador, y el archivo antiguo queda en solo lectura hasta que lo retire.

// Qué incluye

// Tecnologías

• Next.js
• PostgreSQL
• Importación de FileMaker y Access
• Almacenamiento de objetos para imágenes
• DigitalOcean Toronto

// El problema

Una galería tiene miles de obras catalogadas pero casi ninguna en línea, y su antiguo visor de colecciones falla en móviles y con lectores de pantalla.

// Lo que construiríamos

Una colección pública en línea diseñada con su equipo y probada con visitantes reales, incluidas personas que usan lectores de pantalla y teclado, con búsqueda por artista, época, lugar y tema, publicada desde su sistema de colecciones para que cada ficha esté en un solo sitio. Los derechos de imagen y los créditos aparecen en cada obra.

// Qué incluye

// Tecnologías

• Next.js
• API del sistema de colecciones
• Visor de imágenes IIIF
• CMS sin cabecera
• DigitalOcean Toronto

// El problema

Un teatro vende entradas con un servicio, abonos con otro y recibe donativos en papel, y su responsable de finanzas concilia los tres a mano cada mes.

// Lo que construiríamos

Venta de entradas para funciones y entradas con hora, abonos con renovaciones y precios para socios, y donativos al pagar, todo con tarjeta a través de Stripe, con las ventas enviadas a QuickBooks Online mediante su API. Cada espectador tiene una sola cuenta para entradas, abono y donativos.

// Qué incluye

// Tecnologías

• Next.js
• PostgreSQL
• Stripe
• API de QuickBooks Online
• DigitalOcean Toronto

// El problema

Un sitio patrimonial imprime su guía en dos idiomas, las visitas en otros idiomas necesitan un guía en plantilla, y la recepción responde todo el día a las mismas preguntas sobre horarios, accesos y aparcamiento.

// Lo que construiríamos

Una guía de visita en el navegador del móvil, abierta con un código en cada parada, en los idiomas de sus visitantes, con un asistente que responde a partir de sus propios textos, cita su fuente y pasa al personal lo que no puede responder. Su equipo de interpretación escribe y aprueba cada texto.

// Qué incluye

// Tecnologías

• Next.js
• API de Claude
• PostgreSQL con pgvector
• CMS sin cabecera
• DigitalOcean Toronto

// El problema

Varios museos se prestan obras entre sí, y cada uno guarda su propia copia de la investigación de procedencia, los informes de estado y los contratos de préstamo, que con los años dejan de coincidir.

// Lo que construiríamos

Una aplicación web compartida donde cada institución registra la investigación de procedencia y los documentos de préstamo, con una huella de cada documento escrita en un registro privado con permisos del que cada miembro ejecuta un nodo. Un PDF firmado suele bastar; el registro ayuda cuando varias instituciones quieren un registro que ninguna tenga sola.

// Qué incluye

// Tecnologías

• Next.js
• Hyperledger Besu (privado, con permisos)
• PostgreSQL
• DigitalOcean Toronto

// El problema

Un consejo municipal de las artes recibe las solicitudes por correo electrónico, prepara a mano los expedientes del jurado y rehace las cifras de su informe anual a partir de hojas de cálculo.

// Lo que construiríamos

Un portal donde artistas y organizaciones presentan su solicitud, la guardan y vuelven a ella, un espacio de jurado con puntuación y declaraciones de conflicto de intereses, cartas de concesión e informes finales, y un panel de solicitudes, concesiones y resultados por programa. Las reglas y los criterios son los que fija su consejo.

// Qué incluye

// Tecnologías

• Next.js
• PostgreSQL
• Metabase
• Correo transaccional
• DigitalOcean Toronto

// El problema

Un festival de verano recluta cada año a cientos de voluntarios en varios recintos, cubre los turnos desde una hoja de cálculo compartida y envía cada cambio por mensaje de grupo.

// Lo que construiríamos

Inscripción de voluntarios con roles y disponibilidad, turnos por recinto que los coordinadores crean y cambian, y un bot de Telegram que envía recordatorios, registra la llegada y permite intercambiar turnos, en los idiomas de sus voluntarios.

// Qué incluye

// Tecnologías

• Next.js
• PostgreSQL
• API de bots de Telegram
• DigitalOcean Toronto