Personal project · 2026
Playlist Builder keeps sign-in, search, track selection, ordering, and saving in one responsive workflow. The finished playlist is written directly to the user's Spotify account.
1 flow
from sign-in and search to a saved playlist
0
user credentials stored by the application
1 refresh
shared by requests queued after a forced token expiry
Verification boundary
No public demo or source repository is linked. The case study records the authorization boundary, recovery exercise, and interaction checks, while the imagery remains explicitly editorial.
Building a playlist can require moving repeatedly between search results, track pages, and the playlist itself. The goal was to keep search results and the growing track list together on one screen. The application also needed to use the public Spotify Web API, authorize users without storing their credentials, and remain responsive while each action crossed the network.
Built independently, with usability feedback from friends who tested the playlist-building flow.
PKCE supports authorization without shipping a client secret to the browser, and tokens do not appear in the URL.
The flow adds verifier and challenge generation plus a token-exchange step.
Users can authorize the app without stored credentials or a client secret in the browser.
Keeping search results beside the selected tracks makes add and remove actions visible in context.
On narrow screens, the panes must stack and the add control needs a different placement.
Search results and selected tracks remain visible within one continuous workflow.
Waiting for Spotify before reflecting every edit makes routine actions feel unresponsive.
A failed request needs a visible rollback and a clear recovery path.
Edits appear immediately; failed requests roll back visibly and can be retried.
Symptom. Spotify access tokens expire during longer sessions. Without recovery, a request can fail while the user is still assembling a playlist.
Investigation & alternatives. I considered forcing another sign-in, refreshing on a timer, and refreshing only after an authorization failure. The implemented approach intercepts a 401 response, refreshes the token once, retries the failed request, and queues requests that arrive during the refresh so they do not each start another one.
Verification & result. I forced token expiry during a session and verified that the failed request retried after one refresh, queued requests resumed, and no action was submitted twice.
The finished application keeps the complete playlist-building flow on one screen and saves the result directly to Spotify. The project put particular emphasis on interaction quality through optimistic updates, keyboard support, responsive layout, and recoverable error states.
What I’d change. Search currently covers tracks only; album and artist browsing would support more playlist-building paths. I would also model the track list as reorderable from the start instead of adding drag-to-reorder later.
Next project
Pelican New Orleans