Case study
← All workSoundBYTE
Twelve services behind three front ends: a gallery, a members' club, and a playground where the public turns their own voice into art.
- Client
- Amrita Sethi
- Year
- 2026
- Discipline
- Platform · Generative art
Context
SoundBYTE is an art form and the platform that carries it: a voice — a spoken phrase, a recorded message — becomes a visual piece. The brief was everything around that idea at once. A catalogue that presents the work as a gallery would. A commissioning route. A members' club. And a playground where anyone can put their own voice in and get a piece out. Four different products with one thing in common, for an artist whose practice is the subject.
Constraints
A gallery and a piece of software want opposite things. The catalogue has to be quiet and give the work room; commissioning, membership and public generation are accounts, payments, queues and long-running jobs. Build it all as a portfolio site and the commissioning collapses into a contact form; build it all as an application and the art becomes a product photograph. Underneath both sits the awkward part: the subject is sound, on a medium that is silent by default and that punishes anything making noise uninvited.
Architecture
One monorepo, three deployed front ends, twelve services. The public catalogue, the playground and the studio's admin each build from the same repository against a different target, so shared code stays shared while the three surfaces stay genuinely separate. The playground runs its own API and its own datastore; the catalogue and club run on another. Generation reports progress over a WebSocket rather than by polling. Two PostgreSQL instances and two Redis, split the same way the applications are, across three environments.
01
Three front ends over shared services, not one app with roles.
A public catalogue and a studio back office change for entirely different reasons and on entirely different schedules. Splitting them means a change to the admin cannot break the gallery, and the gallery can stay as light as a gallery should be rather than shipping an admin bundle to every visitor.
What it cost
Three builds, three deploys, and shared code that has to be factored into monorepo packages rather than just imported.
02
The playground gets its own API and its own datastore.
Generation is bursty and slow; browsing is constant and fast. Sharing a backend means a queue of people making pieces degrades the experience of everyone looking at them — and the catalogue is the part that has to be reliable, because it is the shopfront.
What it cost
An auth boundary between the two halves, and a second store to operate and back up.
03
WebSocket for generation progress rather than polling.
A generation runs long enough that a spinner with no feedback reads as a broken page. A live progress channel is the difference between waiting and wondering whether it failed.
What it cost
A stateful connection in an otherwise stateless system, which is one more thing that has to reconnect cleanly.
04
Sound is offered, never autoplayed.
The site carries an explicit control to enable audio. On a work about sound that is a real cost — the defining quality is off until asked for — but a page that makes noise on arrival gets closed, and a muted autoplay would be the work with its subject removed.
What it cost
Most visitors will experience a sound-based practice in silence.
- Services in production
- 12
- read from deployment
- Deployment environments
- 3 — dev, staging, production
- read from deployment
- Datastores
- PostgreSQL ×2 · Redis ×2
- read from deployment
Live across three public subdomains — catalogue, playground and admin — on twelve production services with a separate API behind each half. The figures the site itself advertises are the artist's own; what is verifiable here is the system underneath them.
Stack
TypeScript · React · Node.js · PostgreSQL · Redis · WebSocket · Monorepo · Railway