The landing page copy that competed in the wrong category

I read the Deep Cut Atlas landing page for the first time in a while and it didn’t sound like the app I built. The intro paragraph said it “surfaces the new albums, EPs, and singles you’ve missed.” Feature one was titled “New releases, filtered to what you actually follow.” That’s an accurate description of what the app does. It’s also, word for word, the pitch for MusicHarbor, an app that’s been doing new-release tracking for Apple Music for years and does it well.

Competing on someone else’s home turf is a losing move when you don’t have to. So I opened the actual view model to check what the app was built to do.

The doc comment had the real pitch

DiscoverViewModel has a doc comment describing what it surfaces: “deep cuts”, catalog releases by the user’s library artists that they don’t already own. Not “new” releases. Any release, from any point in an artist’s catalog, that never made it into the user’s library. New drops are a subset of that. The back catalog is the rest of it, and it’s usually much bigger.

The landing page never made that distinction. It also never explained the name. “Deep Cut Atlas” is a good name for an app that maps an artist’s whole catalog. It’s a strange name for an app that only tells you about this week’s singles.

Rewriting around the real feature

The fix was copy-only: five spots across the marketing page and the homepage project card, no code changes. The hook I landed on: “The algorithm found the artist. Deep Cut Atlas finds the albums.” It draws the line between what Apple Music’s own recommendation engine already does (surface artists) and what this app adds (surface everything by those artists you don’t have yet).

I also touched two spots the issue didn’t explicitly call out: a “How it works” step still titled “See what’s new,” and the page’s meta description, still promising “new releases” for search engines and social previews. Leaving either one alone would have quietly undone half the rewrite, so I brought them in line too.

A quoting gotcha in Astro attributes

One edit broke the build in a way that took a second to parse. The page’s meta description is a bare HTML attribute on an Astro component: description='...'. My rewrite needed an apostrophe in “you’re missing” inside that single-quoted string, so I backslash-escaped it: you\'re. That’s valid inside a JS string literal. It is not valid inside a bare HTML attribute, because a bare attribute isn’t a JS expression at all, it’s just text up to the matching quote character. Prettier tried to reparse the file, hit the stray backslash and quote, and rewrote the whole attribute into a garbled multi-line mess of bare words.

The fix was to stop fighting the two quote characters the string needed (an apostrophe and a pair of double quotes around “To Check Out”) and switch the attribute to a JS expression with a template literal: description={…}. Backticks don’t need either quote character escaped, so the whole sentence, apostrophe and all, just works.

Result

npm run check, format:check, and build all passed. I ran a local preview and curled both pages to confirm “new release” doesn’t appear anywhere on the site anymore, and the new framing renders where it should. Small change, but it moves the app into a category it can actually win instead of one where the incumbent always wins the comparison.