I started AI Design HQ to solve a problem I kept running into: useful guidance for designers moving into AI-native work was scattered, hard to evaluate, and rarely tested in real work.
I designed, built, and curated a solo resource library of 65+ resources across seven categories, checking each against real tool use. I kept the structure deliberately small so it works as a practical stack rather than another directory.
Most "AI design resources" roundups treat the topic like a directory problem. Collect a URL, slap a logo on it, sort alphabetically — the same ten tools in every list, the same 80% outdated within six months, and the things that actually matter to a designer moving into AI-native work buried under three layers of SEO. I wanted a small, opinionated library where every entry had been used in real client work, organised around what designers actually do, not what vendors want to be known for.
I deliberately scoped the library to seven categories — Tools, Read, Watch, Learn, Follow, Join, MCPs. A 50-category directory would have read as a directory; a seven-category stack reads as a system you can actually hold in your head. Every category answers a question a designer asks: what to use, what to read, what to watch, where to learn, who to follow, where to talk, what to plug in. MCPs earned its slot because nobody else was curating them for designers — engineers had lists, designers didn't.
Designed, built, and curated the entire product solo. No team, no funding, no agency handoff. The first version shipped in roughly six weeks of evenings and weekends.
The build stack was the same stack the library recommends — MagicPath and Paper for the design direction and creating little components I could copy in, Cursor and Claude Code for the actual main work and implementation. The site is its own best case study: I built it the way I recommend other AI-native designers build their own work. I caught and rewrote every AI-generated blurb and tool description before it shipped — the first drafts were confident-sounding and subtly wrong in ways that only show up if you actually use the tools. AI speed, human taste.
A list of tools is not enough on its own — most designers know which tools to read about, but they stall on how to actually chain them into a working workflow. I added a Workflows section with step-by-step guides for using the tools together in real client work: how to brief an agent before a build, how to keep a design system in sync with code, how to hand a prototype off without it falling apart.
The other problem the library didn't solve was commitment. Too many tools, too much noise, easy to get analysis paralysis. Find your stack is a short step-by-step questionnaire that walks you through what you actually need — what kind of work you do, where the gaps are, what fits your budget — and lands on a small recommended stack to commit to for the next month. It's the part of the project I wish existed when I started.
Every resource was tested for usefulness before it shipped — not in formal client work, but in actually trying to use each tool for the things the library claims it can do. The cost is slower to add entries; the payoff is a library that compounds in trust as it grows, not one that dilutes.
Building in the open is the marketing. The library is the case study for the design work I do every day — every entry is an opinion I've defended by using the tool myself. Curating beats aggregating: a library of 65 entries I've used is worth more than 500 entries someone scraped. AI-native doesn't mean AI-generates — I rewrote every AI-generated blurb before it shipped, because the first drafts were confident and subtly wrong in ways that only show up if you actually use the tool.
If I were starting over, I'd reduce the time slightly between designing and actually building it in code. That's the change.
