mixshift.ai (opens in a new tab) is the marketing site for an Amazon marketplace analytics platform. I built it from the first commit and I am its origin and top author: 163 commits, 1,142 files touched, 162 components across 31 routes, 13 posts and 7 newsletter issues.
The home page. One signal green on near-black, and a diagram that has to explain a platform in one look.
The design system it runs on is here, running: open it →. Thirty cards covering brand, color, type, spacing and the component set, each drawn from the same tokens the site ships, with the marketing UI kit at the end.
At a glance
- Role. Designer and frontend lead. Sole author.
- Built. A brand and design-system overhaul, then the site on top of it: product pages for the platform, the plugin and MCP surfaces, intelligence, DSP, pricing, partners and customers.
- Kept correct. Consent-gated analytics and ads tracking, forms and meetings, per-channel mailing lists, four tiers of anti-spam, a domain migration, and the content pipelines behind the blog and newsletter.
- What it shows. That I treat a marketing site as production software, because under real traffic that is what it is.
The brand first, then the site
A marketing site built before its design system is a set of pages that will disagree with each other within a quarter. So the order was brand and design system first, site second.
The lockup carries the whole system in one line: the mark reads at a favicon, the wordmark is letterspaced wide enough to hold its own beside it, and the one green appears exactly once, on the suffix. Everything else on the site is built from that restraint.
Then six rounds of design and content audit. One of those rounds removed fabricated content and unverified statistics the company could not support. That is worth stating plainly: the most useful thing I did to that copy was delete claims we had no basis for. A marketing site that overstates is a liability the first time a customer checks.
Product pages carry the weight, because this is a platform with a lot of surface and a buyer who needs to place it quickly.
Report Center. The product page for the reporting surface.
Builder Platform. The page for people who want the credential and the docs, not a demo.
Pricing. The page that has to survive the most scrutiny, so it makes the fewest claims.
The plumbing, which is the actual work
The pages are the visible half. The half that takes the time:
- Analytics with Consent Mode v2, and ads conversion tracking gated behind consent rather than fired regardless. Forms and meeting booking, and mailing-list audiences with per-channel delivery.
- Anti-spam escalated in four tiers as attackers adapted: request guards first, then a honeypot, then a challenge, then domain blocks. Each tier went in because the previous one stopped being enough, which is the only honest way to build that kind of defense.
- A domain consolidation, host-scoped. Moving from one top-level domain to another is routine until you notice a subdomain in the blast radius. The platform subdomain backed a listing that had just been submitted to a partner portal, and a naive redirect would have broken it mid-review. The redirect was scoped to the host so the subdomain survived.
- Content pipelines feeding the blog and newsletter from the team's own tooling, with the publishing run for everyone: whitepapers, newsletter issues, the author registry.
- A standing SEO and answer-engine review that every piece of content clears before it links out.
The bug worth writing down
A navigation crash kept surfacing and kept getting misattributed. The root cause was the cookie-consent tool: it was mutating analytics scripts that React owned, so the framework and the consent vendor were fighting over the same nodes, and the visible symptom was a crash several steps downstream.
The reason that one is worth recording is not the fix. It is that the obvious suspect was the framework, and the framework was innocent. The consent layer is the last place most people look because it is the part nobody chose to build.
The decisions worth naming
- Brand before pages. A design system is cheaper to impose at commit one than to retrofit at commit two hundred.
- Delete claims you cannot support, including your own employer's marketing copy.
- Escalate defense in tiers, and keep the ladder. The record of what stopped working and when is more useful than whatever finally held.
- Scope a migration to the thing that can break. The redirect knew about the subdomain because someone went looking for what depended on it.
MixShift Marketing is one strand of a larger engagement. The rest of it, the product design system, Report Center 2.0, the knowledge base and the automation underneath the team, is in the MixShift case study.