Full Stack Engineer to Build a Music-Release Ingestion Pipeline + Curation Dashboard (Music Tech)

# Full Stack Engineer to Build a Daily Music-Release Ingestion Pipeline + Curation Dashboard (Music Tech) ## About us We are a music technology company. Every day, thousands of new music releases go live across public catalogues and platforms, and we want to capture that firehose, clean it, classify it, filter out the junk, and surface the good stuff on an internal dashboard our team works from. That structured feed then powers downstream enrichment and outreach. We have the concept and the data sources mapped. We are starting this build from scratch and want an experienced data/backend engineer to own it. ## The project Build a daily ingestion pipeline that pulls new music releases from several public sources, normalizes them into one database, applies a genre/taxonomy policy and a quality-scoring layer to drop spam and low-value content, and presents the survivors on a fast internal web board with human review controls. Runs entirely on our own infrastructure. ## Scope of work **Ingestion and scraping** - Scheduled daily jobs pulling new releases from multiple public music sources (large catalogue APIs and independent platforms) - Resilient scraping/fetching with session reuse and graceful handling of source changes and rate limits - Provenance on every record: source URL and capture date **Data model and normalization** - Design and implement a PostgreSQL schema for releases, artists, labels, and content providers - Normalize inconsistent source data (names, dates, durations, identifiers) into one clean shape - De-duplication of the same release across sources - Schema owned in version control via a migration tool (Drizzle or similar) **Classification and filtering (the core logic)** - A genre/taxonomy policy engine that maps varied source tags into one canonical genre tree and decides what is eligible for ingestion and front-page placement - A scoring layer that flags likely spam / low-quality / automated-content-farm releases and demotes or drops them by rule - Keyword and source pre-filters, curated and easy to maintain - Self-instrumentation: each run reports what it dropped and what it could not classify, so the rules improve over time **Worker and orchestration** - Background worker running the daily pipeline reliably and idempotently - Monitoring and alerting so a broken source or a failed run is caught in hours, not weeks **Front end (curation dashboard)** - A fast, database-backed web board (SvelteKit, Next.js, or your recommendation) showing the day's kept releases with pagination and filtering - Human review controls: promote, demote, and flag levers that write back to the database **Back office and reporting** - NocoDB (or comparable) over the same database for bulk edits and manual curation by non-technical staff - Metabase (or comparable) dashboards for ingestion volume, drop rates, and source health **Deployment** - Provision and configure our existing VPS hosts (managed via Coolify) for the database, worker, web app, and supporting services ## Tech context Postgres, a version-controlled schema, a background worker, a modern web front end, NocoDB, Metabase, and Coolify-managed deployment on our own servers. Stack recommendations welcome, but we favor a maintainable, mainstream approach any developer can pick up later. ## What we are looking for - Strong data-engineering background: ingestion pipelines, scraping at scale, schema design, and data normalization - Comfort writing non-trivial business logic (classification, scoring, rule engines), not just plumbing - Enough front-end ability to ship the review dashboard, or a clear plan for how you would cover it - Someone who builds in working increments and instruments their own system ## How to apply Please include all of the following so we can compare proposals fairly: 1. A **fixed-price total** for the build, broken into milestones with what each delivers 2. Your **hourly rate** and an **estimated number of hours** for the full scope 3. A realistic **timeline** to first working pipeline and to full completion 4. Two or three relevant examples of similar data/ingestion work you have shipped 5. **Optional:** a monthly rate for ongoing maintenance, source upkeep, and support after launch Budget is open. We would rather see your honest number and reasoning than pad to a figure. Tell us how you would sequence the work and how you would keep the pipeline resilient as sources change.