Template: Comparison (X vs Y) skill

Template Name: Comparison (X vs Y Analysis)

by AgriciDaniel·MIT license·★ 2,219 Stars on the repo·GitHub ↗

Use now

Files of Template: Comparison (X vs Y)

AgriciDaniel/main1 file
comparison.md
Show the full text324 lines

Template: Comparison (X vs Y)

Template Name: Comparison (X vs Y Analysis) Target Word Count: 1,500-2,000 words Description: A structured, fair, category-by-category comparison of two (or occasionally three) competing products, tools, strategies, or approaches. Each category section is framed as a question the reader is actually asking, with a clear winner declared per category and an overall verdict. Designed to rank for "[A] vs [B]" queries, capture decision-stage traffic, and earn featured snippets for direct comparison questions.

When to Use This Template

  • Content Goals: Capture high-intent "[A] vs [B]" search traffic, help readers make confident purchase/adoption decisions, build authority as a fair evaluator, rank in "People Also Ask" boxes
  • Search Intent: Commercial investigation: the reader has narrowed their options to 2-3 choices and needs help making the final decision
  • Best For: Software comparisons, tool evaluations, framework decisions, platform migrations, methodology debates, service provider comparisons
  • Avoid When: The two options aren't genuinely comparable (different categories), one option is clearly obsolete, or you need to evaluate more than 3 options (use the Listicle template instead)

Section-by-Section Structure


Title (H1)

Format: "[Product A] vs [Product B]: [Key Differentiator] Compared ([Year])"

Examples:

  • "Next.js vs Astro: Performance and DX Compared (2026)"
  • "PostgreSQL vs MySQL: Which Database Fits Your Stack? (2026)"
  • "Tailwind CSS vs Styled Components: Styling Approaches Compared (2026)"

Rules:

  • Put the more popular/searched product first (higher search volume = first position)
  • Include a differentiating phrase that signals what the comparison covers
  • Include the year for freshness signals
  • Keep under 65 characters if possible
  • Never use "Which is Better?": be more specific about the dimension of comparison

TL;DR Box (40-60 words)

[ANSWER-FIRST] Deliver the verdict immediately. The reader should be able to stop here and have a useful answer.

Format: A visually distinct callout box placed immediately after the title.

Structure:

  1. Quick verdict (1 sentence): Name the overall winner and the single strongest reason.
  2. Exception (1 sentence): Name the specific use case where the other option wins.
  3. Decision rule (1 sentence): "Choose [A] if [X]. Choose [B] if [Y]."

Example:

TL;DR: Astro wins for content-heavy sites: it's faster out of the box and ships zero JS by default. Next.js wins for interactive web applications where you need server-side rendering, API routes, and a mature ecosystem. Choose Astro if your site is mostly content. Choose Next.js if your site is mostly application.


Introduction (100-150 words)

[ANSWER-FIRST] Open with the specific market context that makes this comparison relevant right now. What changed recently that makes people search for this?

Structure:

  1. Timeliness hook (1-2 sentences): What happened recently (release, trend, shift) that makes this comparison urgent?
  2. The core tension (1-2 sentences): What is the fundamental trade-off between these two options? Frame it as a genuine dilemma, not a strawman.
  3. Scope statement (1 sentence): What specific dimensions will this comparison cover?
  4. Credibility anchor (1 sentence): What qualifies you to make this comparison? (testing methodology, experience with both, etc.)

[STAT: Market context statistic: adoption rates, npm downloads, GitHub stars, survey data that frames both options]

[INFO-GAIN: hands-on experience] Briefly state your direct experience with both options: what you built, how long you used them, at what scale.

[INTERNAL-LINK] Link to individual deep-dive posts on each product: "For standalone reviews, see our [Product A Guide] and [Product B Guide]."


Quick Comparison Table (H2)

[VISUAL: comparison-table]

Format: A comprehensive feature matrix as a markdown table, placed early in the post for scanners.

Required rows (adapt to your category):

Category [Product A] [Product B]
Best For [Primary use case] [Primary use case]
Pricing [Specific tiers] [Specific tiers]
Learning Curve [Specific assessment] [Specific assessment]
[Key Metric 1] [Specific value] [Specific value]
[Key Metric 2] [Specific value] [Specific value]
[Key Metric 3] [Specific value] [Specific value]
[Key Metric 4] [Specific value] [Specific value]
Community / Ecosystem [Specific data point] [Specific data point]
Our Verdict [Win/Lose/Tie per row] [Win/Lose/Tie per row]

Rules:

  • Use specific, measurable values: never "Good" or "Fast"
  • Bold the winner in each row
  • Include a "Best For" row at the top and "Our Verdict" row at the bottom
  • Keep to 8-12 rows: enough to be comprehensive, not so many that it's overwhelming

[STAT: Include at least one benchmark or metric in the table that you measured yourself]

[INFO-GAIN: original benchmark] If you ran your own performance tests, note the methodology in a footnote below the table.

Benchmark data sourcing. Every stat in a comparison table must follow the FLOW evidence triple: year anchor (preferably in the row caption or surrounding paragraph), inline citation in the source column or as a footnote, and URL plus retrieval date in compact references or retrieval notes at the bottom of the post. See skills/blog/references/flow-alignment.md.


Category 1: Which Has Better [Core Feature]? (150-200 words)

[ANSWER-FIRST] Open by naming the winner of this category and the single strongest reason in the first sentence.

H2 format: Frame each category as a question: ## Which Has Better Performance?

Structure for EVERY category section:

  1. Winner declaration (1 sentence): "[Product A/B] wins on [category] because [specific reason]."
  2. Product A evaluation (2-3 sentences): How Product A performs in this category with specific details, metrics, or examples.
  3. Product B evaluation (2-3 sentences): How Product B performs in this category with specific details, metrics, or examples.
  4. Nuance (1-2 sentences): When does the losing product actually come close or even win in a sub-scenario?
  5. Verdict (bold, 1 sentence): Restate the winner with a qualifier.

[STAT: Specific metric comparing both products in this category]

[IMAGE] Side-by-side screenshot, benchmark result, or visual comparison showing the difference in this category.

Example:

Which Has Better Build Performance?

Astro wins on build speed: building our 500-page test site in 4.2 seconds compared to Next.js's 18.7 seconds.

Astro's build pipeline is optimized for static content. It processes Markdown files in parallel and only bundles JavaScript for components explicitly marked as interactive. Our test site with 500 MDX pages and 12 interactive islands built in 4.2 seconds consistently.

Next.js processes every page through its full rendering pipeline, including server component resolution. The same 500 pages took 18.7 seconds. However, Next.js's incremental static regeneration means subsequent builds only reprocess changed pages: after the first build, adding a single page took 1.1 seconds.

Verdict: Astro wins for full builds. Next.js wins for incremental updates in large, frequently-changing sites.


Category 2: Which Has Better [Second Feature]? (150-200 words)

[Follow the same structure as Category 1]

[STAT: Comparative metric for this category]

[INFO-GAIN: real-world observation] Share something you noticed during actual usage that benchmarks don't capture.


Category 3: Which Has Better [Third Feature]? (150-200 words)

[Follow the same structure as Category 1]

[STAT: Comparative metric for this category]

[IMAGE] Visual comparison for this category.


Category 4: Which Has Better [Fourth Feature]? (150-200 words)

[Follow the same structure as Category 1]

[STAT: Comparative metric for this category]

[INFO-GAIN: ecosystem or community insight] Share an observation about documentation quality, community helpfulness, or ecosystem maturity that comes from real experience.


Category 5: Which Has Better [Fifth Feature]? (150-200 words)

[Follow the same structure as Category 1]

[STAT: Comparative metric for this category]


Categories 6-7: [Additional categories as needed] (150-200 words each)

[Follow the same structure. Use 5-7 categories total. Common categories include:]

  • Performance / Speed
  • Developer Experience / Learning Curve
  • Ecosystem / Plugins / Integrations
  • Documentation / Community Support
  • Scalability
  • Security
  • Customization / Flexibility
  • Pricing / Value

Note: Choose categories based on what your audience actually cares about, not what's easiest to compare. Survey your readers or check "People Also Ask" boxes for guidance.


Pricing Comparison (150-200 words)

[ANSWER-FIRST] Open with the bottom line: "For [typical use case], [Product A] costs [X] and [Product B] costs [Y]."

Structure:

  1. Direct cost comparison (2-3 sentences): Side-by-side pricing for the most common tier or usage pattern.
  2. Free tier analysis (1-2 sentences): What's actually usable in each free tier? What are the real limits?
  3. Scaling costs (2-3 sentences): How does pricing change as usage grows? Where are the inflection points?
  4. Hidden costs (1-2 sentences): Any costs not immediately obvious: migration effort, required add-ons, lock-in implications.
  5. Value verdict (bold, 1 sentence): Which provides better value and for whom.

[VISUAL: pricing-comparison-table] A simple table showing pricing tiers side by side.

Tier [Product A] [Product B]
Free [Details] [Details]
Starter / Pro [Price + details] [Price + details]
Enterprise [Price + details] [Price + details]

[STAT: Total cost of ownership for a specific scenario (e.g., "For a 10-person team with 100K monthly users")]

[INFO-GAIN: hidden cost insight] Share a pricing detail that isn't obvious from the pricing page: something you discovered during actual usage (overage charges, required add-ons, support tier limitations).


Who Should Choose What (100-150 words)

[ANSWER-FIRST] Open with the simplest possible decision rule: "If [condition], choose [Product]. If [condition], choose [Product]."

Format: 2-4 reader profiles, each as a bolded persona with a 1-2 sentence recommendation.

Structure:

  1. Persona 1 (bold): "[Profile description]" -> Recommendation + reason
  2. Persona 2 (bold): "[Profile description]" -> Recommendation + reason
  3. Persona 3 (bold): "[Profile description]" -> Recommendation + reason
  4. Edge case (1 sentence): When neither option is right and what to consider instead.

[INTERNAL-LINK] Link to a detailed guide for each recommended product: "Getting started with [Product A]? Read our [Setup Guide]."

Example:

Solo developers building content sites: Choose Astro. You'll ship faster, spend less time configuring, and get better performance out of the box.

Teams building SaaS applications: Choose Next.js. The API routes, authentication patterns, and middleware ecosystem will save you months.

Agencies managing multiple client sites: Choose Astro for marketing/content sites, Next.js for web applications. Most agencies end up using both.

If neither fits: you need a full-stack framework with batteries included: look at Remix or SvelteKit.


Frequently Asked Questions (3-5 questions)

[FAQ]

Format: Each question as an H3, answer in 2-4 sentences.

Question selection criteria:

  1. "Is [Product A] better than [Product B]?" (Restate verdict with nuance)
  2. "Can I migrate from [A] to [B]?" (Address switching costs and feasibility)
  3. "Can I use [A] and [B] together?" (Address hybrid approaches if applicable)
  4. "[Specific feature] question" (Address the most searched feature-specific question)
  5. "Is [Product] still worth using in [Year]?" (Address relevance and future trajectory)

[STAT: Include at least one statistic in your FAQ answers]

Example:

Is Next.js better than Astro?

[2-4 sentence answer reframing as "it depends on your use case" with specific criteria.]

Can I migrate from Next.js to Astro?

[2-4 sentence answer with migration feasibility, estimated effort, and key considerations.]

Can I use Next.js and Astro together?

[2-4 sentence answer addressing monorepo setups or hybrid architectures if applicable.]

Which has better SEO?

[2-4 sentence answer with specific SEO-relevant differences and metrics.]

Is [Product] still relevant in 2026?

[2-4 sentence answer addressing trajectory, recent releases, and community momentum.]


Verdict with Category Winners (50-100 words)

Format: A summary table followed by an overall recommendation.

Category Winner
[Category 1] [Product]
[Category 2] [Product]
[Category 3] [Product]
[Category 4] [Product]
[Category 5] [Product]
Pricing [Product]
Overall [Product] (for [specific use case])

Overall verdict (2-3 sentences): Restate the decision rule from the TL;DR with any additional nuance earned through the detailed analysis.

CTA (1 sentence): "Disagree? Share your experience in the comments" or "Subscribe for more head-to-head comparisons."

[INTERNAL-LINK] Link to 2-3 related posts: getting-started guides for the winner, alternative comparisons, or the listicle that includes both products.


Template Checklist

Before publishing, verify:

  • Title includes both product names, a differentiator, and the current year
  • TL;DR box delivers a clear verdict in under 60 words
  • Introduction establishes timeliness: why this comparison matters now
  • Quick comparison table uses specific metrics, not vague ratings
  • Every category section opens by naming the winner (answer-first)
  • Every category section evaluates both products with comparable depth and fairness
  • Every category section includes a nuance statement (when the loser might win)
  • 5-7 categories cover the dimensions that matter most to the target audience
  • Pricing comparison includes free tiers, scaling costs, and hidden costs
  • "Who Should Choose What" provides clear persona-based recommendations
  • At least 3 [INFO-GAIN] elements with original testing data or observations
  • At least 5 [STAT] markers filled with sourced or first-party statistics
  • At least 2 [IMAGE] markers with side-by-side visual comparisons
  • FAQ addresses migration, hybrid use, and product relevance
  • Verdict table summarizes category winners clearly
  • All [INTERNAL-LINK] zones have contextual links to related content
  • Word count falls within 1,500-2,000 range
  • Both products are treated fairly: no strawman arguments
  • Meta description written (under 160 characters, includes both product names)
1# Template: Comparison (X vs Y)
2 
3**Template Name:** Comparison (X vs Y Analysis)
4**Target Word Count:** 1,500-2,000 words
5**Description:** A structured, fair, category-by-category comparison of two (or occasionally three) competing products, tools, strategies, or approaches. Each category section is framed as a question the reader is actually asking, with a clear winner declared per category and an overall verdict. Designed to rank for "[A] vs [B]" queries, capture decision-stage traffic, and earn featured snippets for direct comparison questions.
6 
7## When to Use This Template
8 
9- **Content Goals:** Capture high-intent "[A] vs [B]" search traffic, help readers make confident purchase/adoption decisions, build authority as a fair evaluator, rank in "People Also Ask" boxes
10- **Search Intent:** Commercial investigation: the reader has narrowed their options to 2-3 choices and needs help making the final decision
11- **Best For:** Software comparisons, tool evaluations, framework decisions, platform migrations, methodology debates, service provider comparisons
12- **Avoid When:** The two options aren't genuinely comparable (different categories), one option is clearly obsolete, or you need to evaluate more than 3 options (use the Listicle template instead)
13 
14---
15 
16## Section-by-Section Structure
17 
18---
19 
20### Title (H1)
21 
22**Format:** "[Product A] vs [Product B]: [Key Differentiator] Compared ([Year])"
23 
24**Examples:**
25- "Next.js vs Astro: Performance and DX Compared (2026)"
26- "PostgreSQL vs MySQL: Which Database Fits Your Stack? (2026)"
27- "Tailwind CSS vs Styled Components: Styling Approaches Compared (2026)"
28 
29**Rules:**
30- Put the more popular/searched product first (higher search volume = first position)
31- Include a differentiating phrase that signals what the comparison covers
32- Include the year for freshness signals
33- Keep under 65 characters if possible
34- Never use "Which is Better?": be more specific about the dimension of comparison
35 
36---
37 
38### TL;DR Box (40-60 words)
39 
40[ANSWER-FIRST] Deliver the verdict immediately. The reader should be able to stop here and have a useful answer.
41 
42**Format:** A visually distinct callout box placed immediately after the title.
43 
44**Structure:**
451. **Quick verdict** (1 sentence): Name the overall winner and the single strongest reason.
462. **Exception** (1 sentence): Name the specific use case where the other option wins.
473. **Decision rule** (1 sentence): "Choose [A] if [X]. Choose [B] if [Y]."
48 
49**Example:**
50> **TL;DR:** Astro wins for content-heavy sites: it's faster out of the box and ships zero JS by default. Next.js wins for interactive web applications where you need server-side rendering, API routes, and a mature ecosystem. Choose Astro if your site is mostly content. Choose Next.js if your site is mostly application.
51 
52---
53 
54### Introduction (100-150 words)
55 
56[ANSWER-FIRST] Open with the specific market context that makes this comparison relevant *right now*. What changed recently that makes people search for this?
57 
58**Structure:**
591. **Timeliness hook** (1-2 sentences): What happened recently (release, trend, shift) that makes this comparison urgent?
602. **The core tension** (1-2 sentences): What is the fundamental trade-off between these two options? Frame it as a genuine dilemma, not a strawman.
613. **Scope statement** (1 sentence): What specific dimensions will this comparison cover?
624. **Credibility anchor** (1 sentence): What qualifies you to make this comparison? (testing methodology, experience with both, etc.)
63 
64[STAT: Market context statistic: adoption rates, npm downloads, GitHub stars, survey data that frames both options]
65 
66[INFO-GAIN: hands-on experience] Briefly state your direct experience with both options: what you built, how long you used them, at what scale.
67 
68[INTERNAL-LINK] Link to individual deep-dive posts on each product: "For standalone reviews, see our [Product A Guide] and [Product B Guide]."
69 
70---
71 
72### Quick Comparison Table (H2)
73 
74[VISUAL: comparison-table]
75 
76**Format:** A comprehensive feature matrix as a markdown table, placed early in the post for scanners.
77 
78**Required rows (adapt to your category):**
79 
80| Category | [Product A] | [Product B] |
81|----------|-------------|-------------|
82| **Best For** | [Primary use case] | [Primary use case] |
83| **Pricing** | [Specific tiers] | [Specific tiers] |
84| **Learning Curve** | [Specific assessment] | [Specific assessment] |
85| **[Key Metric 1]** | [Specific value] | [Specific value] |
86| **[Key Metric 2]** | [Specific value] | [Specific value] |
87| **[Key Metric 3]** | [Specific value] | [Specific value] |
88| **[Key Metric 4]** | [Specific value] | [Specific value] |
89| **Community / Ecosystem** | [Specific data point] | [Specific data point] |
90| **Our Verdict** | [Win/Lose/Tie per row] | [Win/Lose/Tie per row] |
91 
92**Rules:**
93- Use specific, measurable values: never "Good" or "Fast"
94- Bold the winner in each row
95- Include a "Best For" row at the top and "Our Verdict" row at the bottom
96- Keep to 8-12 rows: enough to be comprehensive, not so many that it's overwhelming
97 
98[STAT: Include at least one benchmark or metric in the table that you measured yourself]
99 
100[INFO-GAIN: original benchmark] If you ran your own performance tests, note the methodology in a footnote below the table.
101 
102**Benchmark data sourcing.** Every stat in a comparison table must follow the FLOW evidence triple: year anchor (preferably in the row caption or surrounding paragraph), inline citation in the source column or as a footnote, and URL plus retrieval date in compact references or retrieval notes at the bottom of the post. See `skills/blog/references/flow-alignment.md`.
103 
104---
105 
106### Category 1: Which Has Better [Core Feature]? (150-200 words)
107 
108[ANSWER-FIRST] Open by naming the winner of this category and the single strongest reason in the first sentence.
109 
110**H2 format:** Frame each category as a question: `## Which Has Better Performance?`
111 
112**Structure for EVERY category section:**
1131. **Winner declaration** (1 sentence): "[Product A/B] wins on [category] because [specific reason]."
1142. **Product A evaluation** (2-3 sentences): How Product A performs in this category with specific details, metrics, or examples.
1153. **Product B evaluation** (2-3 sentences): How Product B performs in this category with specific details, metrics, or examples.
1164. **Nuance** (1-2 sentences): When does the losing product actually come close or even win in a sub-scenario?
1175. **Verdict** (bold, 1 sentence): Restate the winner with a qualifier.
118 
119[STAT: Specific metric comparing both products in this category]
120 
121[IMAGE] Side-by-side screenshot, benchmark result, or visual comparison showing the difference in this category.
122 
123**Example:**
124> ## Which Has Better Build Performance?
125>
126> **Astro wins on build speed**: building our 500-page test site in 4.2 seconds compared to Next.js's 18.7 seconds.
127>
128> Astro's build pipeline is optimized for static content. It processes Markdown files in parallel and only bundles JavaScript for components explicitly marked as interactive. Our test site with 500 MDX pages and 12 interactive islands built in 4.2 seconds consistently.
129>
130> Next.js processes every page through its full rendering pipeline, including server component resolution. The same 500 pages took 18.7 seconds. However, Next.js's incremental static regeneration means subsequent builds only reprocess changed pages: after the first build, adding a single page took 1.1 seconds.
131>
132> **Verdict: Astro wins for full builds. Next.js wins for incremental updates in large, frequently-changing sites.**
133 
134---
135 
136### Category 2: Which Has Better [Second Feature]? (150-200 words)
137 
138[Follow the same structure as Category 1]
139 
140[STAT: Comparative metric for this category]
141 
142[INFO-GAIN: real-world observation] Share something you noticed during actual usage that benchmarks don't capture.
143 
144---
145 
146### Category 3: Which Has Better [Third Feature]? (150-200 words)
147 
148[Follow the same structure as Category 1]
149 
150[STAT: Comparative metric for this category]
151 
152[IMAGE] Visual comparison for this category.
153 
154---
155 
156### Category 4: Which Has Better [Fourth Feature]? (150-200 words)
157 
158[Follow the same structure as Category 1]
159 
160[STAT: Comparative metric for this category]
161 
162[INFO-GAIN: ecosystem or community insight] Share an observation about documentation quality, community helpfulness, or ecosystem maturity that comes from real experience.
163 
164---
165 
166### Category 5: Which Has Better [Fifth Feature]? (150-200 words)
167 
168[Follow the same structure as Category 1]
169 
170[STAT: Comparative metric for this category]
171 
172---
173 
174### Categories 6-7: [Additional categories as needed] (150-200 words each)
175 
176[Follow the same structure. Use 5-7 categories total. Common categories include:]
177- Performance / Speed
178- Developer Experience / Learning Curve
179- Ecosystem / Plugins / Integrations
180- Documentation / Community Support
181- Scalability
182- Security
183- Customization / Flexibility
184- Pricing / Value
185 
186**Note:** Choose categories based on what your audience actually cares about, not what's easiest to compare. Survey your readers or check "People Also Ask" boxes for guidance.
187 
188---
189 
190### Pricing Comparison (150-200 words)
191 
192[ANSWER-FIRST] Open with the bottom line: "For [typical use case], [Product A] costs [X] and [Product B] costs [Y]."
193 
194**Structure:**
1951. **Direct cost comparison** (2-3 sentences): Side-by-side pricing for the most common tier or usage pattern.
1962. **Free tier analysis** (1-2 sentences): What's actually usable in each free tier? What are the real limits?
1973. **Scaling costs** (2-3 sentences): How does pricing change as usage grows? Where are the inflection points?
1984. **Hidden costs** (1-2 sentences): Any costs not immediately obvious: migration effort, required add-ons, lock-in implications.
1995. **Value verdict** (bold, 1 sentence): Which provides better value and for whom.
200 
201[VISUAL: pricing-comparison-table] A simple table showing pricing tiers side by side.
202 
203| Tier | [Product A] | [Product B] |
204|------|-------------|-------------|
205| Free | [Details] | [Details] |
206| Starter / Pro | [Price + details] | [Price + details] |
207| Enterprise | [Price + details] | [Price + details] |
208 
209[STAT: Total cost of ownership for a specific scenario (e.g., "For a 10-person team with 100K monthly users")]
210 
211[INFO-GAIN: hidden cost insight] Share a pricing detail that isn't obvious from the pricing page: something you discovered during actual usage (overage charges, required add-ons, support tier limitations).
212 
213---
214 
215### Who Should Choose What (100-150 words)
216 
217[ANSWER-FIRST] Open with the simplest possible decision rule: "If [condition], choose [Product]. If [condition], choose [Product]."
218 
219**Format:** 2-4 reader profiles, each as a bolded persona with a 1-2 sentence recommendation.
220 
221**Structure:**
2221. **Persona 1** (bold): "[Profile description]" -> Recommendation + reason
2232. **Persona 2** (bold): "[Profile description]" -> Recommendation + reason
2243. **Persona 3** (bold): "[Profile description]" -> Recommendation + reason
2254. **Edge case** (1 sentence): When neither option is right and what to consider instead.
226 
227[INTERNAL-LINK] Link to a detailed guide for each recommended product: "Getting started with [Product A]? Read our [Setup Guide]."
228 
229**Example:**
230> **Solo developers building content sites:** Choose Astro. You'll ship faster, spend less time configuring, and get better performance out of the box.
231>
232> **Teams building SaaS applications:** Choose Next.js. The API routes, authentication patterns, and middleware ecosystem will save you months.
233>
234> **Agencies managing multiple client sites:** Choose Astro for marketing/content sites, Next.js for web applications. Most agencies end up using both.
235>
236> If neither fits: you need a full-stack framework with batteries included: look at Remix or SvelteKit.
237 
238---
239 
240### Frequently Asked Questions (3-5 questions)
241 
242[FAQ]
243 
244**Format:** Each question as an H3, answer in 2-4 sentences.
245 
246**Question selection criteria:**
2471. "Is [Product A] better than [Product B]?" (Restate verdict with nuance)
2482. "Can I migrate from [A] to [B]?" (Address switching costs and feasibility)
2493. "Can I use [A] and [B] together?" (Address hybrid approaches if applicable)
2504. "[Specific feature] question" (Address the most searched feature-specific question)
2515. "Is [Product] still worth using in [Year]?" (Address relevance and future trajectory)
252 
253[STAT: Include at least one statistic in your FAQ answers]
254 
255**Example:**
256 
257#### Is Next.js better than Astro?
258 
259[2-4 sentence answer reframing as "it depends on your use case" with specific criteria.]
260 
261#### Can I migrate from Next.js to Astro?
262 
263[2-4 sentence answer with migration feasibility, estimated effort, and key considerations.]
264 
265#### Can I use Next.js and Astro together?
266 
267[2-4 sentence answer addressing monorepo setups or hybrid architectures if applicable.]
268 
269#### Which has better SEO?
270 
271[2-4 sentence answer with specific SEO-relevant differences and metrics.]
272 
273#### Is [Product] still relevant in 2026?
274 
275[2-4 sentence answer addressing trajectory, recent releases, and community momentum.]
276 
277---
278 
279### Verdict with Category Winners (50-100 words)
280 
281**Format:** A summary table followed by an overall recommendation.
282 
283| Category | Winner |
284|----------|--------|
285| [Category 1] | [Product] |
286| [Category 2] | [Product] |
287| [Category 3] | [Product] |
288| [Category 4] | [Product] |
289| [Category 5] | [Product] |
290| **Pricing** | [Product] |
291| **Overall** | **[Product] (for [specific use case])** |
292 
293**Overall verdict** (2-3 sentences): Restate the decision rule from the TL;DR with any additional nuance earned through the detailed analysis.
294 
295**CTA** (1 sentence): "Disagree? Share your experience in the comments" or "Subscribe for more head-to-head comparisons."
296 
297[INTERNAL-LINK] Link to 2-3 related posts: getting-started guides for the winner, alternative comparisons, or the listicle that includes both products.
298 
299---
300 
301## Template Checklist
302 
303Before publishing, verify:
304 
305- [ ] Title includes both product names, a differentiator, and the current year
306- [ ] TL;DR box delivers a clear verdict in under 60 words
307- [ ] Introduction establishes timeliness: why this comparison matters *now*
308- [ ] Quick comparison table uses specific metrics, not vague ratings
309- [ ] Every category section opens by naming the winner (answer-first)
310- [ ] Every category section evaluates both products with comparable depth and fairness
311- [ ] Every category section includes a nuance statement (when the loser might win)
312- [ ] 5-7 categories cover the dimensions that matter most to the target audience
313- [ ] Pricing comparison includes free tiers, scaling costs, and hidden costs
314- [ ] "Who Should Choose What" provides clear persona-based recommendations
315- [ ] At least 3 [INFO-GAIN] elements with original testing data or observations
316- [ ] At least 5 [STAT] markers filled with sourced or first-party statistics
317- [ ] At least 2 [IMAGE] markers with side-by-side visual comparisons
318- [ ] FAQ addresses migration, hybrid use, and product relevance
319- [ ] Verdict table summarizes category winners clearly
320- [ ] All [INTERNAL-LINK] zones have contextual links to related content
321- [ ] Word count falls within 1,500-2,000 range
322- [ ] Both products are treated fairly: no strawman arguments
323- [ ] Meta description written (under 160 characters, includes both product names)
324 

Discussion

Alternatives

Company valuationEstimate the intrinsic value of a public company using DCF, relative (peer multiple) and sum-of-parts (SOTP) methods, then triangulate to an implied share price with upside/downside versus the current market price. Use this skill whenever the user asks: what is AAPL worth", "valuation of NVDA", "fair value of TSLA", "intrinsic value", DCF for MSFT", "build a DCF", "discounted cash flow", "WACC", "terminal value", implied share price", "upside to fair value", "is X overvalued/undervalued", relative valuation", "peer comparison valuation", "EV/EBITDA target", "SOTP", sum of the parts", "how much is [company] worth", "price target from fundamentals", value this company", or any ticker in the context of computing intrinsic or relative valuation. Default to running ALL three methods (DCF + relative + SOTP-if-applicable) and presenting a blended implied price with a sensitivity table. Do not answer valuation questions from memory — always run the workflow. · MITCompetitor gapFind keywords a competitor ranks for that the user's site doesn't — the content gap, prioritized by volume and winnability. Use when asked "what does competitor.com rank for", "keyword gap vs X", "steal competitor keywords", or "why do they outrank us".Business & ops · MITAd angle minerMine the highest-converting ad angles from customer reviews, Reddit complaints, support tickets, and competitor ads. Extracts actual pain language, competitor weaknesses, and outcome phrases that real buyers use. Outputs a ranked angle bank with proof quotes and recommended ad formats per angle.Business & ops · MITX audience insightsRead your X (Twitter) audience and niche from real data. Pull a handle's recent tweets (yours or a competitor's) with likes, replies, and views, see which formats and hooks are working, read the repliers on a tweet (X gates likers, so repliers are the signal), and scan a niche query for top tweets. Powered by Apify, no login. Triggers on "analyze my tweets", "what is working on X", "read the replies", "competitor tweets", "who is engaging". Not for writing a tweet (use x-post-writer).Marketing · MIT