patricianine.com

My work as a DJ keeps producing dates, videos and sessions. A traditional press kit means selecting that material, updating it and sending it again every time someone asks. I built patricianine.com so that isn't needed.

It's a static, bilingual website with my background, the archive of my gigs since 2023, sessions and upcoming dates. Promoters and brands can see the whole picture without asking me for a dossier.

An archive, not a gallery

I wanted the dates to work as an archive, not as a photo gallery. Every gig since 2023 lives in a single data source with a shared schema. The interface generates the filters by kind and year from it, without reloading the page.

Residencies are the only dates shown in black. They carry the most weight in my history, so they're also the first thing that stands out in the archive.

On a computer, each date shows its video on hover; on a phone, on tap. Each video has a still frame so an empty box never appears while it loads.

Private dates never reach the browser: they're taken out of the data before the page is served. If I only hid them on screen, they'd still be in the page's code for anyone to see.

One ink

The whole interface starts from one constraint: black on white. No brand colours. Hierarchy comes from size, weight and levels of grey.

System type and one structure of rows, lines and labels. The same rules build the archive, the calendar and the sessions. The intention was for the site to feel more like a catalogue than the usual artist promo website.

A custom player on top of SoundCloud

I wanted to host the sessions where the audio already was, without bringing another platform's visual player into the interface. SoundCloud is the source, not the interface. On top of its Widget API I built custom controls for play, pause and progress, kept in sync with SoundCloud. The bar drags with a mouse or a finger.

Each session plays from its row, without leaving the page.

A calendar that ages on its own

The site is static, but upcoming dates change every week. Instead of republishing after every gig, the browser compares the dates with today and stops showing the ones that have passed.

When none are left, the calendar shows that I'm available for bookings.

Designing directly on the product

I didn't start by asking an AI to generate a finished website.

I built several directions directly in code, compared them running in the browser and chose from there what to keep.

After that the process became a loop: I decide what should change and how it should behave; Claude Code implements it; I test the result on the real site and step in again.

Working this way also changed where design happens. Many decisions I would once have settled in a mockup first, I now make on the working product: with real data, real responsive behaviour and real states.

What I haven't solved yet

I didn't build a CMS. Gigs are still added directly to the data source because, at the current volume and with me as the only person maintaining the site, an admin interface would have added more system than I need.

I don't have enough analytics yet to know how promoters and brands use the site. It's the main missing piece for making the next decisions with data rather than observation alone.

See patricianine.com ↗