Resomix

Overview

Resomix is a music discovery platform that finds tracks by how they actually sound rather than by genre, popularity or metadata. It is in production beta today.

I have been its sole developer for 20 months, from a short brief through research and prototype to the platform running now, across more than twenty repositories. Python and FastAPI, React and TypeScript, relational and document databases alongside a search cluster, independent services behind queues and caching, partner catalogue ingestion, a partner-facing API, billing, and an operations dashboard.

What I own

Architecture, backend, front end, data layer, infrastructure, deployment and production operations. Also the parts people forget are engineering work: capacity planning, the commercial model, standards compliance, and the technical documentation partners are given.

The platform runs as Linux services under systemd behind nginx, with S3-compatible object storage, automated TLS, firewalling, antivirus scanning on every upload, and monitoring.

Complexities tackled

Four months of open-ended research, with no guarantee at the end of it. The first phase was not implementation. Several approaches were designed, built and discarded before one worked, and at the outset nobody could say whether the core idea was achievable at all. Staying productive under that uncertainty, reporting honestly about what was failing, and knowing when to abandon a direction that looked promising, was harder than any code in the project.

A single-purpose tool that had to become a platform. The original brief described one feature. What the business actually needed was multi-tenant infrastructure serving partners with large catalogues, each isolated, each with their own data, quotas and access. Growing into that without stopping to rewrite meant separating concerns long before there was an obvious reason to, and accepting some overhead early to avoid a rebuild later.

Multi-tenancy as an architectural property, not a feature. Partner isolation reaches into storage, processing, search, API access, billing and every audit path. It is close to impossible to retrofit honestly, so it shapes the data model and everything built on top of it.

Migrating a live system onto a new data model. The platform outgrew the schema it started with. Replacing it meant mapping the legacy structure in full, planning the migration path, and moving across without losing data or interrupting a service already in use.

Meeting an industry’s standards rather than a specification. Music distribution has established conventions for delivery, metadata and reporting, and partners expect them. Designing ingestion around what labels and distributors actually send, rather than what would be convenient to build, was months of specification and research work before any of it was implemented.

Turning “it works” into “it holds”. Prototype quality and production quality are different engineering problems. Understanding real capacity, failure behaviour, resilience and recovery, and finding the system’s limits before users did, ran as a structured programme rather than as reactive fixes.

The commercial layer, designed with the product rather than after it. Plans, quotas, metering and billing had to be built alongside the platform, because what you can meter constrains what you can sell, and that decision reaches back into the architecture.

Operating what I build. I deploy this and I am responsible when it misbehaves. Owning production changes how you design: you build for the version of yourself who gets woken up, not the version writing the first draft.

What I take from it

Long engagements are won on judgement more than throughput. The decisions that mattered here were what to build later, what to isolate early, and when to say an approach was not going to work. No amount of clean code rescues a system structured wrong in month three.

Note

The PYXIS-1 analysis engine at the centre of the product is the client’s proprietary work and is not described here.