Design Mode: Clonable Artist Landing Page

April 26, 2026

This case study covers a Design Mode session for an animated artist landing page. The architectural challenge here was different from most: the goal was not to build a complex system, but to build something deliberately simple that any artist could clone and own without depending on a platform, a subscription or a backend.

At a glance


Project	Clonable single-page artist landing template
Mode	Design Mode
Stack	Vanilla JS, Google Calendar API, Shopify Storefront API
Backend	None — single static HTML/JS, no server, no database
Animation target	24 fps animation engine
Output	Configurable template artists can fork and own

The brief

A music artist needed a web presence that:

Displayed upcoming events and concerts, auto-synced from Google Calendar.
Sold merchandise via Shopify integration.
Delivered a visually striking, animation-driven experience.
Could be cloned and rebranded by any other artist with minimal effort — swap logo, colours, API keys, done.

The polymorphic requirement was the constraint that shaped everything else.

The key architectural decision

No backend. No server. No framework.

The plan’s reasoning:

This is a single landing page with an animation system. No framework is warranted. Vanilla JS keeps the repo lightweight, zero-dependency, and trivially clonable. A React or Next.js version would add build complexity with no benefit for a single static page.

Architecture:

Static files (HTML + CSS + ES Modules)
├── config.js          ← artist-specific values (logo, colors, API keys)
├── AnimationEngine.js ← central 24fps recursive loop driving all effects
├── EventsModule.js    ← Google Calendar API fetch + render
└── MerchModule.js     ← Shopify Storefront API fetch + cart + checkout redirect

Deployment: Netlify / Vercel / GitHub Pages (any static host)

No build step required. No package manager required. Fork the repo, edit config.js, push — the page is live.

The animation engine design

The plan specified a central animation class — not scattered setInterval calls, not CSS animations for the complex effects — a single recursive loop running at 24fps that drives all visual state.

Rationale:

A centralised loop gives you one place to pause, resume and debug all animations. Scattered timers create timing drift and are impossible to coordinate.

The loop drives:

Glow pulse effects on key UI elements.
Parallax movement on scroll.
Countdown timer to next event (updates in the loop, not via setInterval).
Shimmer effects on the merch grid on hover entry.

External integrations

Google Calendar API:

Read-only fetch of public calendar events using a simple API key.
No OAuth — the calendar is public, the key is read-only.
Events filtered to upcoming dates, sorted by start time, rendered as cards.

Shopify Storefront API:

Product listing fetched client-side using a public Storefront access token.
Cart managed in browser state (no server-side sessions).
Checkout via Shopify’s hosted checkout URL — no payment processing in the page.

Both integrations use only public/read-only credentials. The artist can expose these in the client-side config file without security risk.

The polymorphic config layer

Every artist-specific value lives in a single config.js file:

export default {
  artist: {
    name: 'Artist Name',
    logo: './assets/logo.svg',
    primaryColor: '#ff3e00',
    accentColor: '#f4c430',
  },
  googleCalendar: {
    calendarId: 'your-calendar-id@group.calendar.google.com',
    apiKey: 'YOUR_GOOGLE_API_KEY',
  },
  shopify: {
    storeDomain: 'your-store.myshopify.com',
    storefrontAccessToken: 'YOUR_STOREFRONT_TOKEN',
  },
};

Fork the repo. Edit this file. Deploy. That is the full onboarding for a new artist.

What the plan produced

Technology stack:

Vanilla HTML/CSS/JavaScript (ES Modules) — zero framework, zero build step
Google Calendar API (read-only, public key)
Shopify Storefront API (public access token)
Static hosting (Netlify, Vercel, GitHub Pages — any works)

Milestones:

M1: Static scaffold + config layer + animation engine skeleton.
M2: Google Calendar integration + event card rendering.
M3: Shopify product grid + cart + checkout redirect.
M4: Full animation system (glow, parallax, countdown, shimmer).
M5: Clone documentation + configuration guide.

What makes this case study interesting

The architectural pressure here ran in one direction: resist adding dependencies.

At every decision point, the plan evaluated whether a library, framework or service was justified by the problem. In each case, it was not:

Events from Calendar? A fetch call. No SDK.
Merch from Shopify? Storefront API. No storefront framework.
Animations? A class and requestAnimationFrame. No animation library.
Deployment? Static files. No server.

The result is a repo that any developer can read in 30 minutes, fork in 5, and configure in another 5. That is the deliverable — not just the page, but the transferability of the page.

Honest limitations

The Google Calendar integration requires a public calendar. If the artist uses a private calendar, OAuth is required and the zero-backend architecture breaks.
Shopify Storefront API exposes products and handles checkout redirect but does not support custom checkout flows or discount codes applied in-page.
The animation engine is a custom implementation. If the artist wants to extend it significantly, they need to understand the 24fps loop pattern — it is not a documented open-source library.
SEO is limited by the single-page static nature. Server-side rendering would improve event discoverability in search engines but contradicts the zero-backend constraint.

Browse the full case study library →