Real-World Product Workflows

When to Use @Solar in Your Product Process

Stage	How @Solar helps
Discovery	Rapidly test assumptions — "chart vs. table?"
Definition	Throwaway prototypes to align stakeholders before writing specs
Design review	Live version of a Figma mockup to test interactions
Sprint planning	Estimate effort — if @Solar builds it in 5 prompts, it's simple
Demo / showcase	Working prototype URL instead of static screenshots
User testing	Clickable prototype for usability studies

Scenario A: Rapid Requirement Exploration

Situation: Your team is deciding between a chart-heavy dashboard and a table-centric view.

@Solar approach:

1. Build variant A (charts) in 10 minutes
2. Build variant B (tables) in 10 minutes
3. Share both URLs with stakeholders
4. Decide based on working prototypes, not static mockups

Scenario B: Stakeholder Alignment

Situation: A VP asks "what would a merchant reporting portal look like?"

@Solar approach:

1. Build a 3-page prototype in 30 minutes
2. Share the URL before the next meeting
3. Iterate based on feedback in real time during the meeting

Scenario C: Design Handoff Validation

Situation: A designer hands off a Figma mockup. Does it work as an interactive app?

@Solar approach:

1. Describe the Figma mockup to @Solar
2. Compare the interactive prototype with the static mockup
3. Surface edge cases (What happens when the table is empty? When there are 1000 rows?)

Scenario D: Feature Scoping

Situation: How complex is this feature really?

@Solar approach:

1. Build it with @Solar
2. Count the prompts and pages needed
3. If it took 5 prompts → straightforward. If 20 prompts → complex.

Key Principle

@Solar prototypes are for validation and alignment — not production code. They help you make better product decisions faster.