This post is based on an article, I wrote on LinkedIn. Read the article here: LinkedIn

MyCousinVinyl started as a way of testing the code assistants, Claude and Codex: I wanted to compare the two. Our household collects records, but managing a growing vinyl library across multiple people quickly becomes messy. I wanted a system that treats a collection like a shared catalog rather than a single-user list, and I wanted it to be fast, reliable, and pleasant to use on any device. Building such a system, using the latest technologies and coding practices, seemed like a worthy challenge.

The application is called MyCousinVinyl - a play on words and a silent homage to the 1992 movie “My Cousin Vinny.” I kept it low-key, but the wink is there for anyone who like quoting the courtroom scenes.

What the application does

At its core, MyCousinVinyl is a shared vinyl collection manager. It tracks artists, albums, pressings, and individual collection items. It also adds two features that make it more than a catalog:

• Collection sharing: Each user’s collection is their own, but users can see, if another member of their group has a pressing in their collection - great when shopping for presents.
• AI-based album wizard: A tool that helps you identify the right album and pressing quickly, even when you only have partial info.

Why I built it this way

I wanted a system that would be robust enough for real use but still approachable for homelab deployment. That pushed the design in a few directions:

• A React SPA so the UI is quick and works on desktop and mobile.
• Clear architecture boundaries so features can evolve without a full rewrite.
• Docker-first deployment so I can run it on a NAS or a local dev stack without friction.
• Tight security at the edges, with simple core logic inside.
• Azure Entra ID for authentication and RBAC.

Chosen components and how they fit

The stack is deliberate and opinionated:

• Frontend: React + Vite, served as static assets by nginx. It keeps the UI fast and decoupled from the API.
• Backend: FastAPI in a hexagonal architecture (domain, application, ports, adapters, entrypoints). I wanted the domain logic to stay clean and testable.
• Database: PostgreSQL for structured, relational data that fits a collection model well.
• Messaging: ActiveMQ by default, with MQTT as an alternative. This keeps integrations async and resilient.
• Workers: Outbox processor, event consumer, pricing worker, cache cleanup, and an activity bridge to keep everything consistent.
• Discogs proxy service: A small service that handles Discogs API access cleanly and safely.
• Auth: Azure Entra ID with group-based RBAC enforced at HTTP entrypoints.

The two standout features

Collection sharing is the heart of the app. The goal is to make a family collection feel like a shared library, but still respect boundaries and responsibilities. The RBAC model keeps it simple: Admin, Editor, Viewer.

The create wizard is the other differentiator. It is designed to reduce the friction of adding records by guiding you through identification and matching.

What I would change next

I want to expand the wizard with better suggestions and richer metadata validation. I also want the sharing model to support multiple collections with different visibility rules, so a household can maintain sub-collections without splitting the system.

If you want the full architecture details or the code, the repository is public and contains additional documentationssssss:

https://github.com/cajo-dk/mycousinvinyl.