Brand site for a hydration company · Live in production

Redwood & Water

The storefront and journal for an endurance hydration brand — built to send people to Amazon and then prove whether it worked.

Role: Site design, content system, and direction of the agents that wrote it.

Timeline: Live in production

Database tables

4

posts, subscribers, settings, amazonClicks. Counted in the repository on 8 August 2026.

API paths

18

Paths defined in the OpenAPI spec. Counted in the repository on 8 August 2026.

Source files

214

TS/TSX/MJS/JS files excluding node_modules. Counted in the repository on 8 August 2026.

What was actually broken

A physical product sold on Amazon has a problem the marketplace can't solve: Amazon is a checkout, not a brand. There is nowhere to explain what the product is for, no editorial voice, no email list, and no way to know which part of your marketing actually sent someone to buy.

The site has to be the brand, and it has to be measurable, even though the transaction happens somewhere you don't control.

The flow I designed

One destination, measured. Every path through the site leads to the same place — the Amazon listing — and every outbound click is tagged with where on the page it came from. "Buy" in the hero and "Buy" at the bottom of a journal post are the same action but very different signals, and treating them as one number throws away the only attribution available.

The Supplement Facts panel is an overlay, not a page. Checking the ingredients is a detour, not a departure. It opens over the page and returns you exactly where you were — a scroll position restored is a small thing that makes a site feel like it respects your time.

The journal earns the search traffic. Editorial content with topic pages, structured data, and a generated sitemap, so the brand can be found by people who are not yet looking for it by name.

The email list is asked for once, in the right place. After the content, not over it.

An admin owns the content. Posts, scheduling, cover images, the live product price and the subscriber list are all editable without a deploy. A brand site nobody can update without an engineer becomes a stale brand site.

Interface notes

1. One destination, repeated

   Every route through the site ends at the same Amazon listing. There is no second, competing call to action to dilute it.

2. The same action, counted separately

   This button and the one in the nav are tagged with different placements. Which one people actually use is the only attribution a marketplace leaves you, so collapsing them into one number throws it away.

3. The footage is generated

   Shot descriptions authored as structured data, rendered through video models, then stitched in a separate deterministic step — so the edit can change without paying to regenerate everything.

The hard part

Making the hero video without a film crew.

The hero footage is generated — shot descriptions authored as structured data, rendered through video models, then stitched into a sequence. For a small brand that would otherwise have either a stock clip or nothing, this is the difference between looking real and looking like a template.

The engineering lesson was about determinism. Generative video is expensive and slow, so a run you can't reproduce is a run you can't iterate on. Shots are described as data and stitching is a separate deterministic step, which means the composition can be adjusted without regenerating footage — and any single shot can be re-rolled without disturbing the rest.

The pattern: when a step in your pipeline is slow, costly or non-deterministic, put a hard boundary around it and make everything downstream of it reproducible.

Stack

Outcome

Published and live, with a working admin, editorial journal, email capture, structured data, and outbound click attribution running against real traffic.

All work · Start a project