Template: Comparison (X vs Y) skill
Template Name: Comparison (X vs Y Analysis)
by AgriciDaniel·MIT license·★ 2,219 Stars on the repo·GitHub ↗
Files of Template: Comparison (X vs Y)
AgriciDaniel/
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:
- Quick verdict (1 sentence): Name the overall winner and the single strongest reason.
- Exception (1 sentence): Name the specific use case where the other option wins.
- 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:
- Timeliness hook (1-2 sentences): What happened recently (release, trend, shift) that makes this comparison urgent?
- 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.
- Scope statement (1 sentence): What specific dimensions will this comparison cover?
- 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:
- Winner declaration (1 sentence): "[Product A/B] wins on [category] because [specific reason]."
- Product A evaluation (2-3 sentences): How Product A performs in this category with specific details, metrics, or examples.
- Product B evaluation (2-3 sentences): How Product B performs in this category with specific details, metrics, or examples.
- Nuance (1-2 sentences): When does the losing product actually come close or even win in a sub-scenario?
- 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:
- Direct cost comparison (2-3 sentences): Side-by-side pricing for the most common tier or usage pattern.
- Free tier analysis (1-2 sentences): What's actually usable in each free tier? What are the real limits?
- Scaling costs (2-3 sentences): How does pricing change as usage grows? Where are the inflection points?
- Hidden costs (1-2 sentences): Any costs not immediately obvious: migration effort, required add-ons, lock-in implications.
- 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:
- Persona 1 (bold): "[Profile description]" -> Recommendation + reason
- Persona 2 (bold): "[Profile description]" -> Recommendation + reason
- Persona 3 (bold): "[Profile description]" -> Recommendation + reason
- 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:
- "Is [Product A] better than [Product B]?" (Restate verdict with nuance)
- "Can I migrate from [A] to [B]?" (Address switching costs and feasibility)
- "Can I use [A] and [B] together?" (Address hybrid approaches if applicable)
- "[Specific feature] question" (Address the most searched feature-specific question)
- "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:** |
| 45 | **Quick verdict** (1 sentence): Name the overall winner and the single strongest reason. |
| 46 | **Exception** (1 sentence): Name the specific use case where the other option wins. |
| 47 | **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:** |
| 59 | **Timeliness hook** (1-2 sentences): What happened recently (release, trend, shift) that makes this comparison urgent? |
| 60 | **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. |
| 61 | **Scope statement** (1 sentence): What specific dimensions will this comparison cover? |
| 62 | **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:** |
| 113 | **Winner declaration** (1 sentence): "[Product A/B] wins on [category] because [specific reason]." |
| 114 | **Product A evaluation** (2-3 sentences): How Product A performs in this category with specific details, metrics, or examples. |
| 115 | **Product B evaluation** (2-3 sentences): How Product B performs in this category with specific details, metrics, or examples. |
| 116 | **Nuance** (1-2 sentences): When does the losing product actually come close or even win in a sub-scenario? |
| 117 | **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:** |
| 195 | **Direct cost comparison** (2-3 sentences): Side-by-side pricing for the most common tier or usage pattern. |
| 196 | **Free tier analysis** (1-2 sentences): What's actually usable in each free tier? What are the real limits? |
| 197 | **Scaling costs** (2-3 sentences): How does pricing change as usage grows? Where are the inflection points? |
| 198 | **Hidden costs** (1-2 sentences): Any costs not immediately obvious: migration effort, required add-ons, lock-in implications. |
| 199 | **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:** |
| 222 | **Persona 1** (bold): "[Profile description]" -> Recommendation + reason |
| 223 | **Persona 2** (bold): "[Profile description]" -> Recommendation + reason |
| 224 | **Persona 3** (bold): "[Profile description]" -> Recommendation + reason |
| 225 | **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:** |
| 247 | "Is [Product A] better than [Product B]?" (Restate verdict with nuance) |
| 248 | "Can I migrate from [A] to [B]?" (Address switching costs and feasibility) |
| 249 | "Can I use [A] and [B] together?" (Address hybrid approaches if applicable) |
| 250 | "[Specific feature] question" (Address the most searched feature-specific question) |
| 251 | "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 | |
| 303 | Before 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
Browse more free Claude skills or everything in Product.