SaaS websites that explain the product

# Design reference: Airtable
Source: https://www.airtable.com/
Swipefile reference: https://swipefile.design/ref/saas-airtable/
Captured: 2026-09-05. This is a dated reference, not a claim about the current live product.
Capture scope: one viewport. Do not infer unseen page sections or a complete user flow.

## Objective
Adapt the visual principles below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
- mood: Clear and flexible
- colors: White, charcoal, pastel pink
- typography: Medium-weight sans headline and compact navigation
- layout: Centered headline and trial/demo pair above a wide product preview
- motion: Static opening-screen capture. Visit the source to study transitions and interactive behavior.
- texture: Soft color fields around interface imagery
- dont: Adapt the hierarchy to your own product and content; use your own identity and imagery.

Useful for: Flexible work platforms that need to turn a broad category into a visible workflow.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Reusable components and semantic HTML express the interface. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Amplitude
Source: https://amplitude.com/
Swipefile reference: https://swipefile.design/ref/saas-amplitude/
Captured: 2026-09-05. This is a dated reference, not a claim about the current live product.
Capture scope: one viewport. Do not infer unseen page sections or a complete user flow.

## Objective
Adapt the visual principles below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
- mood: Practical and product-led
- colors: White, black, muted blue
- typography: Large sans headline with compact product labels
- layout: Headline and actions above a broad preview with capability tabs
- motion: Static opening-screen capture. Visit the source to study transitions and interactive behavior.
- texture: Restrained interface screenshots and light panel borders
- dont: Adapt the hierarchy to your own product and content; use your own identity and imagery.

Useful for: Analytics platforms explaining several workflows through one organized product preview.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Reusable components and semantic HTML express the interface. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Asana
Source: https://asana.com/
Swipefile reference: https://swipefile.design/ref/saas-asana/
Captured: 2026-09-05. This is a dated reference, not a claim about the current live product.
Capture scope: one viewport. Do not infer unseen page sections or a complete user flow.

## Objective
Adapt the visual principles below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
- mood: Collaborative and approachable
- colors: White, black, pink, small multicolor accents
- typography: Large clean sans display with a colored phrase
- layout: Centered message and account choices, framed by a loose network of work labels
- motion: Static opening-screen capture. Visit the source to study transitions and interactive behavior.
- texture: Thin connector lines, small avatars, and rounded UI fragments
- dont: Adapt the hierarchy to your own product and content; use your own identity and imagery.

Useful for: Collaboration software connecting an abstract teamwork promise to a concrete signup path.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Reusable components and semantic HTML express the interface. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: beehiiv
Source: https://www.beehiiv.com/
Swipefile reference: https://swipefile.design/ref/saas-beehiiv/
Captured: 2026-09-05. This is a dated reference, not a claim about the current live product.
Capture scope: one viewport. Do not infer unseen page sections or a complete user flow.

## Objective
Adapt the visual principles below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
- mood: Bold and creator-focused
- colors: Deep navy, white, pink-purple accents
- typography: Heavy uppercase stacked display
- layout: Left-aligned pitch and signup choices, right-side product panels, customer names below
- motion: Static opening-screen capture. Visit the source to study transitions and interactive behavior.
- texture: Dark flat field with softly glowing interface previews
- dont: Adapt the hierarchy to your own product and content; use your own identity and imagery.

Useful for: Creator SaaS that needs to show the publishing offer and a low-friction first step.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Reusable components and semantic HTML express the interface. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Brevo
Source: https://www.brevo.com/
Swipefile reference: https://swipefile.design/ref/saas-brevo/
Captured: 2026-09-05. This is a dated reference, not a claim about the current live product.
Capture scope: one viewport. Do not infer unseen page sections or a complete user flow.

## Objective
Adapt the visual principles below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
- mood: Fresh and commercially focused
- colors: Pale lime, white, black
- typography: Clean sans headline and compact supporting copy
- layout: Left-aligned introduction and actions, right-side UI collage, customer row underneath
- motion: Static opening-screen capture. Visit the source to study transitions and interactive behavior.
- texture: Flat pastel color with overlapping interface panels
- dont: Adapt the hierarchy to your own product and content; use your own identity and imagery.

Useful for: Marketing platforms using recognizable screens and customer context to support a broad offer.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Reusable components and semantic HTML express the interface. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Clay
Source: https://www.clay.com/
Swipefile reference: https://swipefile.design/ref/saas-clay/
Captured: 2026-09-05. This is a dated reference, not a claim about the current live product.
Capture scope: one viewport. Do not infer unseen page sections or a complete user flow.

## Objective
Adapt the visual principles below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
- mood: Playful and systematic
- colors: Forest green, sky blue, yellow, pastel colors
- typography: Large white sans statement with smaller supporting text
- layout: Broad illustrated scene above a split introduction and action area
- motion: Static opening-screen capture. Visit the source to study transitions and interactive behavior.
- texture: Tactile 3D objects, grass-like surfaces, and soft clouds
- dont: Adapt the hierarchy to your own product and content; use your own identity and imagery.

Useful for: Complex workflow products using a memorable visual metaphor before explaining the system.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Reusable components and semantic HTML express the interface. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Clerk
Source: https://clerk.com/
Swipefile reference: https://swipefile.design/ref/saas-clerk/
Captured: 2026-09-05. This is a dated reference, not a claim about the current live product.
Capture scope: one viewport. Do not infer unseen page sections or a complete user flow.

## Objective
Adapt the visual principles below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
- mood: Focused and technical
- colors: White, near-black, muted gray
- typography: Heavy sans headline with compact code-like text
- layout: Centered headline and short description, small implementation control, customer row
- motion: Static opening-screen capture. Visit the source to study transitions and interactive behavior.
- texture: Minimal decoration, light rules, and code-oriented UI
- dont: Adapt the hierarchy to your own product and content; use your own identity and imagery.

Useful for: Developer tools that need to explain one capability and make implementation feel close.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Reusable components and semantic HTML express the interface. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Customer.io
Source: https://customer.io/
Swipefile reference: https://swipefile.design/ref/saas-customer-io/
Captured: 2026-09-05. This is a dated reference, not a claim about the current live product.
Capture scope: one viewport. Do not infer unseen page sections or a complete user flow.

## Objective
Adapt the visual principles below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
- mood: Calm and direct
- colors: White, dark green, muted image colors
- typography: Large lightweight sans headline
- layout: Left-aligned statement and paired actions, wide media area below
- motion: Static opening-screen capture. Visit the source to study transitions and interactive behavior.
- texture: Generous white space and restrained product imagery
- dont: Adapt the hierarchy to your own product and content; use your own identity and imagery.

Useful for: Lifecycle messaging tools connecting the communication channel to a clear business use.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Reusable components and semantic HTML express the interface. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Dovetail
Source: https://dovetail.com/
Swipefile reference: https://swipefile.design/ref/saas-dovetail/
Captured: 2026-09-05. This is a dated reference, not a claim about the current live product.
Capture scope: one viewport. Do not infer unseen page sections or a complete user flow.

## Objective
Adapt the visual principles below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
- mood: Analytical and assertive
- colors: Black, white, electric blue
- typography: Heavy centered sans display
- layout: Centered headline and short explanation above paired actions and customer logos
- motion: Static opening-screen capture. Visit the source to study transitions and interactive behavior.
- texture: Subtle line grid and a bright product-related graphic
- dont: Adapt the hierarchy to your own product and content; use your own identity and imagery.

Useful for: Research and customer-intelligence products that need a strong point of view before showing details.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Reusable components and semantic HTML express the interface. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Dropbox
Source: https://www.dropbox.com/
Swipefile reference: https://swipefile.design/ref/saas-dropbox/
Captured: 2026-09-05. This is a dated reference, not a claim about the current live product.
Capture scope: one viewport. Do not infer unseen page sections or a complete user flow.

## Objective
Adapt the visual principles below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
- mood: Practical and familiar
- colors: Warm white, black, saturated blue
- typography: Compact bold sans headline and readable body text
- layout: Two-column introduction: message and actions left, workspace preview right
- motion: Static opening-screen capture. Visit the source to study transitions and interactive behavior.
- texture: Neutral page surface with crisp interface imagery
- dont: Adapt the hierarchy to your own product and content; use your own identity and imagery.

Useful for: File and knowledge platforms making the organization of content visible in the hero.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Reusable components and semantic HTML express the interface. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Grammarly
Source: https://www.grammarly.com/
Swipefile reference: https://swipefile.design/ref/saas-grammarly/
Captured: 2026-09-05. This is a dated reference, not a claim about the current live product.
Capture scope: one viewport. Do not infer unseen page sections or a complete user flow.

## Objective
Adapt the visual principles below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
- mood: Supportive and clear
- colors: White, deep green, pastel blue and lilac
- typography: Bold sans headline with smaller explanatory labels
- layout: Centered introduction and signup choices above a row of task-oriented cards
- motion: Static opening-screen capture. Visit the source to study transitions and interactive behavior.
- texture: Soft colored preview backgrounds and text-editing examples
- dont: Adapt the hierarchy to your own product and content; use your own identity and imagery.

Useful for: Assistive tools that can explain value through recognizable tasks rather than a long feature list.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Reusable components and semantic HTML express the interface. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: HubSpot
Source: https://www.hubspot.com/homepg-b?wfuid=ce45e84a0d.1788650983&wfsid=1788650983-d802-bdd7-3902ff2c79f1
Swipefile reference: https://swipefile.design/ref/saas-hubspot/
Captured: 2026-09-05. This is a dated reference, not a claim about the current live product.
Capture scope: one viewport. Do not infer unseen page sections or a complete user flow.

## Objective
Adapt the visual principles below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
- mood: Human and business-focused
- colors: Warm photography, white text, orange actions
- typography: Large centered serif headline with compact sans supporting text
- layout: Two utility and product-navigation rows above an image-led hero, centered message, and paired actions
- motion: Static opening-screen capture. Visit the source to study transitions and interactive behavior.
- texture: Natural team photography under a readability overlay
- dont: Adapt the hierarchy to your own product and content; use your own identity and imagery.

Useful for: Business platforms that connect an operational promise to the teams using the product.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Reusable components and semantic HTML express the interface. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Intercom
Source: https://www.intercom.com/
Swipefile reference: https://swipefile.design/ref/saas-intercom/
Captured: 2026-09-05. This is a dated reference, not a claim about the current live product.
Capture scope: one viewport. Do not infer unseen page sections or a complete user flow.

## Objective
Adapt the visual principles below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
- mood: Editorial and composed
- colors: Warm white, black, soft gray, muted photography
- typography: Large light sans display with selectively emphasized words
- layout: Centered statement with image strips at the edges and compact actions below
- motion: Static opening-screen capture. Visit the source to study transitions and interactive behavior.
- texture: Sparse photo collage and generous open space
- dont: Adapt the hierarchy to your own product and content; use your own identity and imagery.

Useful for: Support platforms balancing a human service story with a product-led first step.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Reusable components and semantic HTML express the interface. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Kit
Source: https://kit.com/
Swipefile reference: https://swipefile.design/ref/saas-kit/
Captured: 2026-09-05. This is a dated reference, not a claim about the current live product.
Capture scope: one viewport. Do not infer unseen page sections or a complete user flow.

## Objective
Adapt the visual principles below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
- mood: Personal and practical
- colors: Warm white, black, sky-blue accents
- typography: Heavy condensed-feeling sans headline and small labels
- layout: Message and action on the left, portrait on the right, small content cards below
- motion: Static opening-screen capture. Visit the source to study transitions and interactive behavior.
- texture: Portrait photography with a simple editorial frame
- dont: Adapt the hierarchy to your own product and content; use your own identity and imagery.

Useful for: Creator tools that can make their audience and use case tangible through real creator stories.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Reusable components and semantic HTML express the interface. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Loops
Source: https://loops.so/
Swipefile reference: https://swipefile.design/ref/saas-loops/
Captured: 2026-09-05. This is a dated reference, not a claim about the current live product.
Capture scope: one viewport. Do not infer unseen page sections or a complete user flow.

## Objective
Adapt the visual principles below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
- mood: Quiet and lightweight
- colors: White, pale gray, small orange accents
- typography: Small restrained sans text throughout
- layout: Small introduction near the upper center, broad workflow diagram below
- motion: Static opening-screen capture. Visit the source to study transitions and interactive behavior.
- texture: Thin outlined email panels and abundant white space
- dont: Adapt the hierarchy to your own product and content; use your own identity and imagery.

Useful for: Focused SaaS tools that benefit from a calm, low-density introduction.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Reusable components and semantic HTML express the interface. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Miro
Source: https://miro.com/
Swipefile reference: https://swipefile.design/ref/saas-miro/
Captured: 2026-09-05. This is a dated reference, not a claim about the current live product.
Capture scope: one viewport. Do not infer unseen page sections or a complete user flow.

## Objective
Adapt the visual principles below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
- mood: Open and collaborative
- colors: White, soft lilac, blue, pastel sticky-note colors
- typography: Medium-weight sans headline
- layout: Centered headline and action above a broad collaborative board preview
- motion: Static opening-screen capture. Visit the source to study transitions and interactive behavior.
- texture: Soft glow behind a crisp diagram-like workspace
- dont: Adapt the hierarchy to your own product and content; use your own identity and imagery.

Useful for: Canvas and collaboration tools whose visual workspace can explain the product quickly.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Reusable components and semantic HTML express the interface. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Mixpanel
Source: https://mixpanel.com/home/
Swipefile reference: https://swipefile.design/ref/saas-mixpanel/
Captured: 2026-09-05. This is a dated reference, not a claim about the current live product.
Capture scope: one viewport. Do not infer unseen page sections or a complete user flow.

## Objective
Adapt the visual principles below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
- mood: Modern and analytical
- colors: White, charcoal, coral, pale purple
- typography: Clear sans headline with compact supporting copy
- layout: Introduction above a wide product screenshot; subtle gradient carries the section
- motion: Static opening-screen capture. Visit the source to study transitions and interactive behavior.
- texture: Soft color bands behind structured analytics UI
- dont: Adapt the hierarchy to your own product and content; use your own identity and imagery.

Useful for: Analytics products that need to connect a high-level promise to visible reporting detail.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Reusable components and semantic HTML express the interface. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Neon
Source: https://neon.com/
Swipefile reference: https://swipefile.design/ref/saas-neon/
Captured: 2026-09-05. This is a dated reference, not a claim about the current live product.
Capture scope: one viewport. Do not infer unseen page sections or a complete user flow.

## Objective
Adapt the visual principles below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
- mood: Technical and concentrated
- colors: Near-black, green, white
- typography: Large clean sans headline with small technical labels
- layout: Wide graphic above a left-aligned introduction, then compact capability columns
- motion: Static opening-screen capture. Visit the source to study transitions and interactive behavior.
- texture: Glowing vertical bars and a flat dark background
- dont: Adapt the hierarchy to your own product and content; use your own identity and imagery.

Useful for: Developer infrastructure products using a technical visual identity without burying the offer.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Reusable components and semantic HTML express the interface. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: PostHog
Source: https://posthog.com/
Swipefile reference: https://swipefile.design/ref/saas-posthog/
Captured: 2026-09-05. This is a dated reference, not a claim about the current live product.
Capture scope: one viewport. Do not infer unseen page sections or a complete user flow.

## Objective
Adapt the visual principles below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
- mood: Playful and technical
- colors: Sage green, warm white, orange
- typography: Compact sans interface text with a larger central statement
- layout: Persistent desktop-style side navigation around a central product window and signup choices
- motion: Static opening-screen capture. Visit the source to study transitions and interactive behavior.
- texture: Illustrated icons, window borders, and a retro software-shell treatment
- dont: Adapt the hierarchy to your own product and content; use your own identity and imagery.

Useful for: Developer platforms with enough breadth to justify an exploratory, desktop-inspired navigation model.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Reusable components and semantic HTML express the interface. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Supabase
Source: https://supabase.com/
Swipefile reference: https://swipefile.design/ref/saas-supabase/
Captured: 2026-09-05. This is a dated reference, not a claim about the current live product.
Capture scope: one viewport. Do not infer unseen page sections or a complete user flow.

## Objective
Adapt the visual principles below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
- mood: Clear and developer-focused
- colors: White, charcoal, mint green
- typography: Clean sans headline and small capability labels
- layout: Split opening message followed by a tidy grid of capability panels
- motion: Static opening-screen capture. Visit the source to study transitions and interactive behavior.
- texture: Fine borders, line illustrations, and restrained green accents
- dont: Adapt the hierarchy to your own product and content; use your own identity and imagery.

Useful for: Infrastructure platforms that need a brief promise and recognizable technical building blocks.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Reusable components and semantic HTML express the interface. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Webflow
Source: https://webflow.com/
Swipefile reference: https://swipefile.design/ref/saas-webflow/
Captured: 2026-09-05. This is a dated reference, not a claim about the current live product.
Capture scope: one viewport. Do not infer unseen page sections or a complete user flow.

## Objective
Adapt the visual principles below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
- mood: Confident and output-focused
- colors: White, black, blue accents
- typography: Large heavy sans headline
- layout: Left-aligned introduction above a horizontal gallery of website examples
- motion: Static opening-screen capture. Visit the source to study transitions and interactive behavior.
- texture: Flat white page with crisp preview cards
- dont: Adapt the hierarchy to your own product and content; use your own identity and imagery.

Useful for: Creation platforms that can demonstrate their range through finished work.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Reusable components and semantic HTML express the interface. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: WorkOS
Source: https://workos.com/
Swipefile reference: https://swipefile.design/ref/saas-workos/
Captured: 2026-09-05. This is a dated reference, not a claim about the current live product.
Capture scope: one viewport. Do not infer unseen page sections or a complete user flow.

## Objective
Adapt the visual principles below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
- mood: Composed and technical
- colors: White, charcoal, lavender
- typography: Large sans headline with a colored second line
- layout: Left-aligned message and actions beside floating UI fragments, with customer logos below
- motion: Static opening-screen capture. Visit the source to study transitions and interactive behavior.
- texture: Soft shadows and pale interface panels
- dont: Adapt the hierarchy to your own product and content; use your own identity and imagery.

Useful for: Developer platforms turning an enterprise capability into a clear product promise.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Reusable components and semantic HTML express the interface. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.