Video summary

How I designed my SaaS landing page using AI tools

Main summary

Key takeaways

Technology

AI-assisted SaaS landing page design workflow

Iterate through tools to find a workable approach

The creator tried multiple AI design tools (with varying results) before settling on an approach that works for their landing page.

Key lesson: don’t ask AI to generate the entire page in one go. Instead:

  • start from a static skeleton
  • then iterate section-by-section until implemented

Experimenting with AI landing-page generators (lessons from failures)

Vercel v0

  • Worked well for a TOTP form
  • Later produced boring results for landing page iteration

GPT Images 2.0

  • Produced highly impressive visuals
  • Example inspiration included:
    • a Fuji mountains background
    • a screenshot-style composition
    • a multi-section structure
  • This helped define a clearer style direction

Claude Design

  • Included odd/undesired styling (e.g., “red sun” on a SaaS page)
  • Japanese prose looked nonsensical, and the layout broke
  • The creator also perceived a tendency for Claude to produce a similar look/vibe across different sites

awesome-design-md

  • Popular repo (noted as having 115k stars)
  • But designs felt generic/average, often borrowing from big-brand styles (e.g., Clickhouse/Apple/BMW/Claude)
  • The creator felt these weren’t distinctive enough for their needs

Design philosophy: “attractive UI” vs “understandable product”

The creator drew inspiration from designers like Oğuz Yağız Kara, but identified a key issue:

Animations and UI mocks can distract from explaining what the product actually does.

They also questioned long-term maintainability for indie developers:

  • complex UI mock animations are hard to update later

Solution: interactive demo + real app UI (not screenshots-only)

Since screenshots/videos don’t let visitors try the product (especially for native apps), the creator uses an approach compatible with their stack:

  • The product is an Electron app
  • The React UI is browser-compatible

Two-part landing page

  1. A demo with real UI components to show look & feel
  2. A real editor component so visitors can interact directly on the web page

Example: rebuilding an Inkdrop landing page demo

  • The demo self-plays an editing session on load
  • Users can edit notes directly inside the embedded demo app

Implementation approach (engineering details)

Component extraction

  • Refactored the desktop app to extract React components into a shared library called UIKit

Storybook-driven UI verification

  • Used Storybook to inspect/verify component designs
  • Included layouts like:
    • control view
    • sidebar layout

Interactive layout

  • Implemented a realistic main layout example that supports real interaction

UI structure pattern

  • Used a Radix UI design pattern to structure the UI implementation

Easier UI propagation to the website

  • The landing page integrates React components
  • This makes it easier to propagate updates from the app’s UI to the website

Video/multimedia integration idea

To avoid showing their face or mentioning their channels, the creator embeds recorded footage of themselves composing a tech note behind the interactive editor.

Claimed outcome:

  • the editor syncs with the background footage
  • improving comprehension while staying non-distracting

Prompting / agentic coding tips and templates (explicit workflow)

1. “Plan in a note, execute by phase”

  • Ask AI to produce an implementation plan first
  • Then implement phase-by-phase
  • Uses Inkdrop note templates as the plan template
  • Uses Claude Code to update the plan as new issues/decisions appear

2. “Point at working code, not descriptions”

Instead of pasting code into chat, the creator directs the agent to:

  • the desktop app repository
  • Storybook stories
  • documentation

Example pattern:

  • implement missing features by referencing a specific story file

3. “Report bugs like a QA report”

When a responsive bug appears (e.g., demo frame breaks on smaller screens / iPhone rotation), they report:

  • device
  • symptom
  • hypothesis (e.g., CSS/scale transform sign issue)

This enables faster, more precise debugging by agents.

4. “Read the source code and point out strange parts”

They actively review code and ask targeted refactoring questions, such as:

  • whether certain styles/filters are still needed
  • why duplicate/wrapper logic exists

If an agent adds a workaround/duplicate function:

  • the creator rejects it
  • performs a style refactor to maintain separation of concerns

5. “Trust your instinct; don’t generate everything at once”

  • Starts with underspecified requirements
  • Requests a static skeleton first

Example:

  • ask for a demo frame that only renders key UI regions (e.g., sidebar + note list)
  • postpone animations/scenes until the structure is validated visually

Main speakers / sources

  • Speaker: Takuya (creator/channel host)

Referenced tools, platforms, and inspirations

  • Claude Design / Claude Code
  • Vercel v0
  • GPT Images 2.0
  • awesome-design-md
  • Oğuz Yağız Kara (design inspiration)
  • Radix UI (design pattern)
  • Storybook
  • Three.js (effects inspiration)
  • CodeMirror and Waku (mentioned for an interactive self-typing editor demo video)
  • Inkdrop (product being rebuilt/demonstrated)

Original video