Slogan

Slogan is a social product for music conversation.

The core loop is simple: you discover music (or a label, artist, event), you post a Thread about it, and other people respond. The important bit is that Threads don’t float in the void. They attach to real “assets” in the system:

• Singles
• Albums
• Artists
• Labels
• Events

So the discussion stays anchored to something concrete, and over time you get a graph of taste, opinions, and momentum around music and culture.

Where the product is today

Right now, Slogan is in a pre-MVP state: the frontend experience exists and is usable for visualising flows, but the data behind it is still largely mocked. That’s intentional. We wanted to get the UX and content model right before committing to a backend that hardens the wrong assumptions.

The build work now is turning those screens into a real application with:

• real auth
• real database entities
• real CRUD
• real feeds
• real notifications

The data model (how we avoid building nonsense)

The fastest way to kill a social app is a sloppy schema.

We’ve already defined the core entity graph in a structured way (profiles, labels, label members, singles, albums, events, threads, fires, comments, replies, follows, notifications). The goal is a normalized relational model that stays flexible as the product grows and as we learn what users actually do.

At a high level:

• a User has a Profile
• a Profile can create Threads
• a Thread can reference a Single (and conceptually we treat Singles/Albums/Artists/Labels as things people can discuss)
• Profiles can follow other Profiles
• Labels are first-class entities with membership/roles
• Notifications are an explicit table so the app can support both realtime updates and push notifications cleanly

How we’re building the backend (and why)

Slogan’s backend plan is opinionated for one reason: speed without chaos.

We’re introducing an Express server between the app and Supabase. Supabase stays the database + auth provider, but the API becomes the place where business logic lives: validation, permissions, aggregation, feeds, and background jobs.

Stack

Backend:

• Node.js + TypeScript
• Express
• Supabase Postgres + Auth + Storage
• OpenAPI 3.1 as the contract
• express-openapi-validator for request/response validation
• Zod for business rules that go beyond schema shape
• Pino for structured logs
• Helmet + rate limiting
• Vitest + supertest for integration tests
• expo-server-sdk for push notifications
• node-cron for scheduled jobs

Frontend:

• Expo + React Native
• Tanstack
• Jotai
• a clean “API services → state → components” flow so screens don’t become untestable.

The architecture pattern

The server is split into:

• Routes: HTTP wiring only
• Controllers: business logic and orchestration
• Repos: the only place we touch Supabase queries

That separation is not academic. It makes the system easier to test, easier to refactor, and easier to scale across multiple contributors.

Contract-first API (OpenAPI + generated client)

This is one of the most important choices: the API spec is the source of truth.

OpenAPI drives:

• runtime validation (bad requests get rejected before they hit controllers)
• typed client generation for the mobile app
• documentation and long-term stability as the team grows.

The payoff is that the mobile app stops guessing what the server returns, and the server stops shipping breaking changes accidentally.

Feeds, trending, and background jobs

Slogan is not just “CRUD some tables”.

The home screen is an aggregated feed: trending threads, trending people, labels, singles, albums, events. That aggregation belongs on the server because:

• it reduces client round trips
• it’s easier to evolve ranking formulas
• it’s safer (no leaking logic or privileged queries to the client)

We also explicitly plan scheduled jobs (e.g., trending recalculation) so the “what’s hot” section isn’t a random query that gets slower over time.

Authentication and real-world constraints

Auth is handled by Supabase. The server validates Supabase-issued tokens for protected routes. That gives us a clean baseline and avoids rolling our own auth machinery.

On the product side, we’re also dealing with real integration constraints early. One example: Facebook login is implemented but blocked on Meta Business Verification before it can be live for general users. That’s not engineering work, it’s compliance work that still needs to be tracked like a critical path item.

Spotify is another constraint. It’s central to the product, but playback and in-app listening experience decisions are non-trivial, so we’re treating it as a deliberate strategy decision rather than rushing something half-working into the build.

What I like about this build

Slogan is the kind of app that becomes messy fast: multiple entity types, cross-linking, feeds, notifications, search, moderation later, and eventually real-time.

The way we’re structuring it keeps the velocity high while still setting standards:

• typed contracts
• clear layering
• predictable data model
• incremental migration from mocked UI to real endpoints

That’s how we keep shipping without paying the rewrite tax every few months.