A music-heritage catalog, from a public map to a self-building admin

Context

The catalog is a body of music heritage — composers, their compositions, and the performances tied to places on a map. The client needed two things over the same data at once: a public-facing app where anyone can explore the catalog, and an internal tool where editors keep it accurate and growing. They didn't want to coordinate three vendors across the front end, the back office, and the infrastructure — they wanted one team to own all of it.

Problem

Two audiences, one catalog, and a data model that won't sit still.

• Two very different front ends over one catalog. A fast, public, map-first browser for visitors, and a dense form-and-table back office for editors.
• The catalog's shape changes. Add a field to a composition and both the editor's form and its table have to follow. Done by hand, that's a code change and a release every time.
• Public reach without an app-store-only gate. It should install to the home screen and work offline, on the web and as an Android app, without building it twice.
• All of it self-hosted and deployable as one system, not a scatter of disconnected services.

Approach

The public app is a Next.js PWA with a Leaflet map that clusters composers, compositions, and performances by place, translated for more than one language and backed by Appwrite. It installs to the home screen, works offline, and is packaged as an Android app from the same codebase through a Trusted Web Activity — one build, served on the web and shipped to the Play Store.

The back office doesn't hard-code its screens. Appwrite cloud functions generate a JSON Schema and table definitions from the catalog's data model, and the MUI-based admin renders the editor forms and data grids from that. Change the model, and the admin follows — there's no hand-built screen to maintain per entity, which is what keeps the editor from lagging behind the data.

Shared TypeScript packages keep the web app, the admin, and the cloud functions speaking the same types, and the whole system self-hosts from one deployment. One team owned every layer, so a change to the catalog's shape moves through the public map, the admin, and the backend at once.

Outcome

Visitors explore the catalog on a map — on the web or from an installed app — while editors curate it through forms and tables that track the data model instead of trailing behind it. Because one team owned the web app, the admin, the Appwrite functions, and the deploy, the catalog can grow and change shape without a release-by-release scramble to keep every surface in sync.