storehand.github.io

The landing page for StoreHand. One self-contained index.html — no build step, no dependencies, no external requests when the page loads (the fonts are served from this repository).

Served by GitHub Pages at https://storehand.github.io.

What the page is for

One job: explain what StoreHand does in about ten seconds, send developers to the repository, and collect email addresses for a possible hosted version. Everything that did not serve one of those three was removed.

Design constraints

Deliberate, and not to be undone without a reason:

• Black and white only. #000 and #FFF, with #525252 for secondary text, #A3A3A3 for dim text on black and #E5E5E5 for hairlines. No accent colour. Hierarchy comes from size, weight and whitespace — never from hue.
• No navigation. A landing page with one job does not need links that lead away from that job. The repository link appears twice, both times below the sign-up form.
• One primary call to action (the email field). "Read the code" is deliberately a plain text link, not a second button.
• Zero border radius, no shadows, no gradients. Depth is a 2px black border or an inverted section.
• Nothing is fetched from a third party. Fonts live in this repo, the grain texture is an inline SVG data URI. The only outbound request happens when somebody submits the form.

All contrast pairs are ≥7.8:1 (WCAG AAA).

Why this is its own repository

GitHub Pages serves an organisation site from the root of a repository named <org>.github.io, so the page has to live here. Keeping a second copy in the product repo would only guarantee the two drift apart — and a marketing page is not what people come to that repo for.

The sign-up form

The form posts straight to Buttondown — a plain HTML POST, no JavaScript, so it keeps working with scripts disabled. The endpoint is:

https://buttondown.com/api/emails/embed-subscribe/steffano

The username is visible in the page source to every visitor. That is normal for an embed endpoint and not a leak, but it does mean spam filtering has to happen on Buttondown's side — the URL itself is not a secret.

Submitting leaves the page: Buttondown answers with its own confirmation screen. That is the trade-off for a form with no JavaScript, and it is the reliable option — a fetch() to that endpoint is blocked by CORS, which would fail silently and swallow addresses.

Double opt-in is on and cannot be switched off from the settings screen — it is a hidden setting only Buttondown support can change. So a sign-up is two steps: the form, then a click in the confirmation mail. The page says so, and it means unconfirmed addresses do not count towards the minimum.

The promise the page makes, in full: one email when the launch date is known, and if a minimum number of sign-ups is not reached, the list is deleted and nothing is sent at all. Deleting it is a manual action in Buttondown (Subscribers → select all → delete). If that promise ever changes, the page text has to change with it before the list is used for anything else.

Custom domain

If getstorehand.com is ever bought, point it here with a CNAME file and the DNS records GitHub asks for. Nothing else moves.