Lo $teve: A Self-Updating Artist Site Wired to the Live Catalog

Overview

losteve.net is the official site for Lo $teve, a hip-hop artist out of New Orleans, Louisiana—70s and 80s soul, told in raps. It is a single, dense landing page: a spinning vinyl hero, the record catalog, an embedded listening section, merch previews, and a mailing-list signup.

The interesting part isn't the page. It's that nobody has to maintain it. The records, the tracklist, and the merch are not content I typed into a CMS—they are read from the artist's live Spotify catalog and Printful storefront at runtime. When a new single drops, it is on the site within the hour. No commit, no deploy, no phone call to me.

The Challenge

Independent artists get handed a website and then quietly abandon it. The release schedule moves faster than anyone's willingness to edit HTML, and within two releases the site is lying about what the artist has actually put out—which is worse than having no site at all, because the stale one still ranks.

The obvious fixes both fail. A CMS moves the chore rather than removing it; it still assumes the artist logs in after every release. A build-time fetch is worse in a subtler way: the site is only as fresh as its last deploy, so "new single is live" silently becomes "someone has to remember to redeploy."

There was a second constraint. The merch storefront at ospv.printful.me sits behind Cloudflare, so the products could not simply be scraped from the page.

The Solution

Both problems resolve the same way: treat the artist's existing platforms as the source of truth, and read them from the running server.

The catalog is fetched server-side through Spotify's Client Credentials flow—no user login, no OAuth dance, no token to expire in someone's account. Merch is read from the Printful API rather than the Cloudflare-fronted storefront, which sidesteps the scraping problem entirely and returns structured data besides.

Around both sits one caching design, chosen to keep a music site fast under traffic it can't predict:

• An in-process stale-while-revalidate cache. Every request is served instantly from the last known-good data. It never blocks on Spotify.
• A committed seed file. A cold pod—or a Spotify outage—renders a real catalog rather than an empty grid. The site has no "loading" state and no failure state; it degrades to slightly-stale and keeps going.
• A scheduled refresh on server boot. A 45-minute timer sits just under the one-hour cache TTL, so the cache is refreshed by the clock rather than by whoever happens to visit. New releases surface even during a dead-quiet traffic week.

The net effect is that traffic and time both keep the site current, and the two failure modes that actually matter—cold start and upstream outage—are covered by the same seed file.

My Role & Contributions

Sole architect and engineer—design, build, infrastructure, and deploy.

• Visual design and art direction: Built the 1970s soul-record-sleeve world—warm espresso and cream, gold leaf, burnt orange, and a velvet-teal accent, over spinning vinyl, sunburst rays, film grain, halftone print textures, and a scrolling marquee. Type pairs Ultra (chunky retro slab) with Fraunces (soulful editorial serif) over Hanken Grotesk.
• A deliberately dependency-free front end: The app ships with exactly three runtime dependencies—Next, React, and React DOM. The full design system is hand-written CSS, and every interaction (nav, scroll reveal, parallax, signup) is plain TypeScript that respects prefers-reduced-motion. No CSS framework, no animation library, nothing to keep patched.
• Live platform integrations: Designed and built both the Spotify and Printful pipelines—token handling, fetch, dedupe, normalization, and the stale-while-revalidate cache—plus snapshot scripts that regenerate the committed seeds on demand.
• Analytics as a boundary, not a sprinkle: Every custom GA4 event funnels through one track() function, and the page communicates with it through an allowlisted data-* attribute contract. An attribute that isn't on the list cannot leak into an analytics payload, which makes the tracking surface reviewable in one file instead of grep-able across the app.
• Secrets that are never handled by hand: Spotify and Printful credentials live in AWS Secrets Manager and are synced into the cluster by a controller as a Kubernetes Secret. The deployment references it as a required Secret, so a pod waits for the sync instead of booting half-configured—and re-syncs roll the deployment automatically when a key rotates.
• Hardened build and runtime: A multi-stage Docker build producing a minimal Node runtime that runs as a non-root user, on a Kubernetes Deployment with a read-only root filesystem and all Linux capabilities dropped.
• Deploy pipeline: GitHub Actions on master—lint, typecheck, and build, then a Trivy scan that fails the pipeline on CRITICAL or HIGH findings, an SPDX SBOM uploaded as an artifact, a push to Docker Hub, and a bastion-proxied rollout to the K3s node that auto-rolls-back on a failed deploy.
• Edge and SEO: Traefik IngressRoute with Let's Encrypt TLS, HTTPS redirection, and www folded onto the apex. Open Graph images, sitemap, robots, manifest, and icons are all generated as code rather than checked in as stale assets.

Engineering Notes

A few decisions worth calling out, because they're the ones that took judgment rather than typing:

• Fonts are self-hosted and selectively preloaded. All three faces are inlined at build time, but only the two that paint above the fold are preloaded—Fraunces is deliberately excluded, since none of it renders the LCP element. Preloading everything is the easy call and the slower one.
• The refresh timer lives in server instrumentation, not an endpoint. It starts once when the Node process boots and is skipped on the edge runtime. There is no cron, no exposed refresh route, and therefore no refresh endpoint for anyone to hammer.
• Rate limits are treated as a first-class state. A failing refresh backs off rather than retrying per request, so a Spotify hiccup degrades to stale data instead of amplifying into a request storm against a rate-limited API.
• Stale clients are absorbed at the proxy. The site defines no Server Actions, but browsers still running an older deployment can keep POSTing a stale Next-Action header. Those are caught before Next's action resolver and answered with a 204—turning a recurring, meaningless server error into nothing at all.
• Merch credentials are optional inside a required Secret. The Secret must exist; the Printful keys within it need not. Without them the app serves seed products silently, so the merch section could ship before the storefront keys did.

Impact

• The site maintains itself. New releases and new products appear without a commit, a deploy, or a request to me—which is the only version of "keep it updated" that survives contact with an artist's actual release schedule.
• It is fast under unpredictable traffic. A release-day spike hits an in-process cache, not the Spotify API. Response time doesn't depend on an upstream service being healthy.
• It has no empty state. Cold pods and upstream outages both render a real catalog from the committed seed.
• It is genuinely low-maintenance. Three runtime dependencies, a scanned and SBOM'd image, and no hand-managed secrets—so the security surface that usually rots on a small marketing site mostly isn't there.