Competitor Alternatives

Competitor Alternatives

Plan and draft competitor comparison and alternative pages that rank for competitive search terms, provide genuine value to evaluators, and position Tiger Data honestly. Covers four formats: singular alternative, alternatives roundup, direct comparison (Tiger Data vs X), and third-party comparison (X vs Y).

This is a content creation skill for public-facing comparison pages. For monitoring what competitors are doing, use competitive-intel-brief. For general SEO-led longform where the competitive frame is secondary, use seo-article-writer.

When to use this skill

• User asks for a "[competitor] alternative" or "alternatives to [competitor]" page
• User wants a "Tiger Data vs [competitor]" or "[competitor A] vs [competitor B]" page
• User asks for competitive comparison content, comparison landing pages, or migration pages
• User says "how do we compare to X?" and wants a publishable page (not an internal brief)
• User mentions "competitor teardown" in the context of public-facing content

When NOT to use this skill

• Monitoring competitor activity, news, or product launches — use competitive-intel-brief
• Internal sales battlecards or deal-level competitive intel — not covered by this skill
• Generic product pages without a competitive frame — use brand-voice-writer
• SEO-led longform where the competitive comparison is one section, not the whole page — use seo-article-writer

Scope

Included: [competitor] alternative pages, [product] vs [competitor] pages, alternatives roundup pages, migration framing, comparison tables

Excluded: Internal-only battlecards, live competitor news scans, generic product pages without competitive positioning

Step 0: Pre-flight check

Read REFERENCES.md from the plugin root and run the pre-flight check described there. Call list_marketing_references() to verify Tiger Den is reachable. If it fails or the tool is not found, STOP — do not continue. Follow the error handling in REFERENCES.md.

Once Tiger Den is confirmed, fetch the primary reference docs:

get_marketing_context(slugs: ["product-marketing-context", "brand-voice-guide"])

Then attempt the competitive guardrails doc separately:

get_marketing_reference(slug: "competitive-messaging-guardrails")

If competitive-messaging-guardrails is not found, inform the user:

"The competitive-messaging-guardrails reference doc is not yet available in Tiger Den. I'll proceed using the competitive framing guidance in product-marketing-context and this skill's editorial neutrality checklist. If your team has specific guardrails for how to discuss competitors publicly, share them now and I'll apply them."

Then continue. This is a soft dependency — the skill is functional without it.

Extract from `product-marketing-context`:

• Competitor list (primary and secondary)
• Tiger Data differentiators and proof points
• ICP context (who are the buyers evaluating alternatives?)
• Terminology glossary (product names, feature names — this is the authority for entity naming)

Extract from `brand-voice-guide`:

• Web page writing rules
• Absolute rules (no em dashes, active voice, etc.)
• AI slop self-check patterns

Tooling check: This skill benefits from web_search and web_fetch for competitor research (Step 3) and verification (Step 7). If web_search is unavailable, inform the user: "Web search isn't available — competitor research will rely on Tiger Den content and any info you provide. I'll skip web-based verification." Then continue.

Also read the three local reference files in this skill's references/ directory:

• references/page-templates.md
• references/comparison-table-patterns.md
• references/editorial-neutrality-checklist.md

Step 1: Identify comparison type and target query

Gather through conversational Q&A, one question at a time:

1. Competitor(s): Which competitor(s) are we comparing against? Confirm against the competitor list in product-marketing-context. If the user names a competitor not in the list, note it and proceed.

2. Page format: Auto-detect from the user's phrasing:

If ambiguous, present the four options and ask the user to pick.

3. Target search query: Propose the primary keyword based on format and competitor. Confirm with the user.

4. Primary audience: Which ICP segment is most likely searching this? Map to personas from product-marketing-context.

Step 2: Verify comparison entity layer

This is a critical guardrail. Before proceeding, classify the comparison:

Rules:

If the comparison mixes layers (e.g., "Tiger Data vs InfluxDB" — company vs product), STOP and ask the user to clarify:

"This comparison mixes entity layers: 'Tiger Data' is a company and 'InfluxDB' is a product. Should this be 'TimescaleDB vs InfluxDB' (product vs product) or 'Tiger Data vs InfluxData' (company vs company)? Getting this right affects terminology, SEO targeting, and positioning throughout the page."

If the comparison compares a product to a category (e.g., "InfluxDB vs time-series databases"), ask if the intent is a "best [category] tools" roundup instead.

Once the entity layer is confirmed, use consistent terminology throughout the draft. Do not mix "Tiger Data" (the company) with "TimescaleDB" (the product) interchangeably. The glossary in product-marketing-context is the authority.

Step 3: Research and gather differentiators

Gather raw material for the comparison from these sources, in priority order:

1. `product-marketing-context` — Extract Tiger Data's differentiators, proof points, and positioning against this specific competitor (if covered).

2. Tiger Den content search — Find existing Tiger Data content about this competitor:

search_content(query: "{competitor name}", limit: 10)
search_content(query: "{competitor name} comparison", limit: 10)
search_content(query: "{competitor name} alternative", limit: 10)

Deduplicate by URL. Flag existing comparison pages that overlap with this one — either update them or ensure the new page adds distinct value.

3. Tiger Docs search (if Tiger Docs MCP is available) — Find technical grounding for feature comparisons:

search_docs(source: "tiger", search_type: "keyword", query: "{feature being compared}")

Use this to verify Tiger Data feature claims (performance numbers, architecture details, API capabilities).

4. Web search (if available) — Research the competitor:

• "{competitor}" features OR capabilities — what do they offer?
• "{competitor}" pricing — current pricing model
• "{competitor}" vs — existing comparison content in the market
• "{competitor}" reviews G2 OR Capterra — common praise and complaint themes

Be selective with web_fetch — only fetch pages where search snippets leave claims ambiguous.

5. User-provided context — Ask: "Do you have specific differentiators, customer quotes from switchers, migration stories, or proof points you want included? Anything not in our docs?"

Compile into a working brief:

• Tiger Data strengths for this comparison
• Competitor strengths (be honest)
• Tiger Data limitations to acknowledge
• Competitor limitations
• Audience fit: who should pick Tiger Data, who should pick the competitor
• Migration angle (what transfers, what needs reconfiguration)
• Proof points (customer quotes, benchmarks, case studies)

Present the working brief to the user for review before drafting.

Step 4: Select page format and draft structure

Load the corresponding template from references/page-templates.md. Present the proposed page structure to the user:

• Proposed URL path
• Proposed title tag and meta description
• Section-by-section outline with what each section will cover
• Which comparison table pattern(s) from references/comparison-table-patterns.md will be used
• Target word count estimate

Get user approval before writing. Adjust the outline based on feedback.

Step 5: Draft the page

Write the full page content following:

• The approved structure from Step 4
• The template from references/page-templates.md
• The table patterns from references/comparison-table-patterns.md
• The editorial neutrality checklist from references/editorial-neutrality-checklist.md
• Brand voice guide rules (active voice, no em dashes, WABL principle)
• competitive-messaging-guardrails if loaded in Step 0

Content rules for all formats:

1. Lead with the reader's problem, not Tiger Data's features. The reader is evaluating — respect their process. 2. Acknowledge competitor strengths. Readers are comparing and will verify claims. Dishonest comparisons destroy credibility. 3. Be specific about who each solution is best for. "Best for teams who need X" is more useful than "better." 4. Include a migration section where applicable. Switching costs are a top objection. 5. No external links to competitor websites. Mention competitors by name but keep all links pointing to Tiger Data properties (tigerdata.com, Tiger Docs) or neutral third-party sources. 6. Include comparison tables using the patterns in references/comparison-table-patterns.md. Tables are scannable and favored by search engines for featured snippets. 7. Date the comparison. Include a "Last updated: [date]" note so readers know the information is current.

Write the page to a markdown file in the working directory: {url-slug}.md

Step 6: Post-draft checks

Run these checks against the draft. Fix all issues found, then re-run.

1. Em dash check — Search for em dashes (—). Replace all instances. Zero tolerance. 2. Editorial neutrality check — Walk through every dimension in references/editorial-neutrality-checklist.md. Flag and fix any violations. 3. Entity layer consistency — Verify the draft uses the confirmed entity layer terminology consistently. No mixing company names with product names. 4. Keyword placement — Primary target keyword appears in H1, first 100 words, and at least one H2. 5. Link format — All links are full URLs starting with https://. No relative paths, no links to competitor websites. 6. Words-to-avoid check — Check against the "words to avoid" section from product-marketing-context. 7. AI slop self-check — Per brand-voice-guide: check for negative seesaws, forced triples, copula dodging, vocabulary clusters, Hallmark-card endings. 8. Competitive guardrails check — If competitive-messaging-guardrails was loaded in Step 0, check the draft against those guardrails.

Step 7: Competitive verification

If web search is available: Verify competitor claims in the draft are current:

• Are product features described accurately?
• Is pricing current?
• Has the competitor rebranded, deprecated, or launched anything relevant since the research in Step 3?

If issues are found, update the draft and report changes.

If web search is unavailable: Skip this step and add a note to the output:

"Competitive verification skipped — web search was unavailable. Verify competitor claims manually before publishing, particularly pricing and feature descriptions."

Step 8: Offer next steps

Present the completed draft and ask:

"The draft is ready. Want me to:

- Run content-reviewer for a full quality rubric evaluation

- Run de-slop for an additional AI pattern cleanup pass

- Draft additional page formats for this competitor (e.g., also create the 'vs' page alongside the 'alternative' page)

- Plan the full competitive page set across all competitors (priority matrix)

- Hand off to seo-article-writer for deeper SEO optimization

- Hand off to website-content-editor to publish on tigerdata.com

- Hand off to page-mockup-builder to visualize the layout before design

- Run competitive-intel-brief for current signals on this competitor"

Output format

The primary output is a markdown file containing:

• Proposed URL path (as a comment at the top of the file)
• Title tag and meta description
• "Last updated" date
• Full page copy organized by section
• Comparison tables in markdown table format
• CTAs with button copy and supporting text
• Internal links to Tiger Data properties

Dependencies

• Required: Tiger Den connector (for product-marketing-context, brand-voice-guide, and content search)
• Soft dependency: competitive-messaging-guardrails Tiger Den reference (enhances guardrails but skill functions without it)
• Optional: web_search and web_fetch (for competitor research and claim verification), Tiger Docs MCP (for technical feature grounding)

Comparison Table Patterns

Reusable table structures for competitor comparison pages. Pick the pattern that fits the comparison type and customize for the specific competitors involved.

Feature-by-Feature Table

When to use: Direct comparisons (Format 3: Tiger Data vs Competitor) where feature parity is the primary evaluation axis.

Structure:

Rules:

• Never use checkmarks or X marks alone. They hide nuance and readers distrust them.
• Each cell should be a phrase or short sentence, not a single word.
• Include context: "Yes — via continuous aggregates" not just "Yes"
• If Tiger Data loses a dimension, say so. "Limited" or "Not supported" is honest and builds trust.
• Keep dimension names evaluator-friendly, not internal jargon. "Query language" not "DQL support."
• Order dimensions by importance to the evaluator, not by where Tiger Data looks best.

Example:

Audience-Fit Table

When to use: Alternative pages (Formats 1 and 2) where "who is this for?" matters more than feature checklists.

Structure:

Rules:

• Include rows where the competitor is the better fit. This is the trust-building move.
• Frame rows around buyer needs, not product features.
• Keep the "Why" column to one sentence. Link to a detailed section below the table for depth.

Example:

Pricing Comparison Table

When to use: Any format where pricing is a meaningful differentiator or a common evaluation factor.

Structure:

Rules:

• Compare apples to apples. If one product charges per GB ingested and the other per vCPU, explain the difference rather than forcing them into the same row.
• Include the "hidden costs" row. Buyers care about total cost, not sticker price.
• If pricing is complex or volume-dependent, link to a calculator or "contact sales" rather than oversimplifying.
• Date the pricing comparison. Pricing changes frequently.

Three-Way Comparison Table

When to use: Format 4 (Competitor A vs Competitor B) where Tiger Data is introduced as a third option.

Structure:

Rules:

• Tiger Data goes in the last column, not the first. You are entering as a helpful third option, not hijacking the comparison.
• Maintain editorial neutrality between Competitors A and B — you are the impartial analyst here.
• The table should be useful even if the reader ignores the Tiger Data column. That's the trust test.
• Do not add dimensions just to include Tiger Data. The dimensions should be the ones that matter for the A-vs-B evaluation.

Anti-Patterns

Avoid these patterns — they signal bias and undermine the page's credibility:

• Checkmark grids — A table of green checks for your product and red X marks for the competitor. Readers see through this instantly.
• All-wins tables — If Tiger Data "wins" every single row, the comparison dimensions were cherry-picked. Revise.
• Cherry-picked dimensions — Only listing features Tiger Data has. Include the dimensions the competitor is known for, even if Tiger Data doesn't match.
• Subjective star ratings — Unattributed ratings without explanation destroy trust.
• Outdated competitor data — Describing last year's competitor product against this year's Tiger Data. Date your comparisons.
• Asymmetric detail — Three sentences in the Tiger Data column, three words in the competitor column. Give both sides equal treatment.
• Misleading tier comparisons — Comparing Tiger Data's enterprise tier to the competitor's free tier.

Editorial Neutrality Checklist

Comparison content earns trust through honesty. Readers are in evaluation mode — they will fact-check claims against the competitor's own site, review platforms, and community forums. A biased comparison page may rank but won't convert. Run this checklist against every draft before publishing.

1. Accuracy

What to check:

• Are all competitor feature descriptions current and correct?
• Are pricing figures up to date? Include a "last verified" date where possible.
• Are technical claims verifiable? Link to Tiger Docs or a neutral source where possible.
• Are you describing the competitor's current product, not a deprecated version or sunset tier?
• If citing benchmarks, are they reproducible or sourced?

Common failures:

• Describing competitor features from a previous major version when they've shipped updates
• Using the competitor's free-tier limitations to represent their full product
• Conflating different competitor products or editions (e.g., open-source vs. cloud versions)
• Citing benchmarks run on unequal hardware or non-representative workloads
• Stating "doesn't support X" when the competitor added it recently

2. Fairness

What to check:

• Does the comparison acknowledge at least one area where the competitor is stronger?
• Are comparison dimensions chosen objectively, not cherry-picked to favor Tiger Data?
• Would the competitor's marketing team read this and say "that's accurate, even if we disagree with the conclusion"?
• Are "Best for" recommendations genuinely helpful, or do they funnel every persona to Tiger Data?
• If using a comparison table, do both columns get the same level of detail?

Common failures:

• Every dimension concludes Tiger Data is better (readers stop trusting the page)
• Competitor strengths mentioned but immediately minimized ("They support X, but nobody really needs that")
• Comparison dimensions suspiciously align with Tiger Data's strengths and avoid areas where the competitor leads
• Describing Tiger Data capabilities in detail but summarizing the competitor with one-liners
• Framing the competitor's architecture as a limitation when it's a deliberate design choice for a different audience

3. Tone

What to check:

• Is the tone respectful toward the competitor? No snark, no belittling.
• Does the page read like a helpful evaluator, not a salesperson?
• Are claims stated as observations, not attacks?
• Good: "InfluxDB uses a custom query language (Flux) rather than standard SQL"
• Bad: "InfluxDB forces you to learn a proprietary language"
• Are superlatives absent? ("vastly superior," "clearly the best," "hands-down winner")
• Is the opening paragraph empathetic to the reader's evaluation process, not dismissive of the competitor?

Common failures:

• Backhanded compliments ("They're fine for small projects")
• Marketing superlatives ("Tiger Data is vastly superior in every dimension")
• Implying the competitor's users made a bad choice or are unsophisticated
• Opening with "Why [Competitor] isn't good enough" instead of validating the reader's search
• Using "just" or "only" to diminish competitor capabilities ("They only support...")

4. Completeness

What to check:

• Does the comparison cover the dimensions that actually matter to evaluators, not just the ones Tiger Data wins?
• Common evaluation dimensions: query language, performance, scalability, pricing, ecosystem/integrations, support, ease of getting started, community, documentation
• Are tradeoffs acknowledged? (e.g., "Tiger Data's full SQL support means a richer query language but a steeper learning curve for teams not already using PostgreSQL")
• Is migration effort addressed honestly, including things that don't transfer easily?

Common failures:

• Omitting dimensions where the competitor is clearly stronger (e.g., ignoring ecosystem size when the competitor has more integrations)
• Presenting migration as effortless when it requires meaningful schema changes or query rewrites
• Skipping the pricing comparison because it's complex or unfavorable
• Not addressing the "good enough" objection — why switch if the current solution works?

5. Transparency

What to check:

• Is it clear that Tiger Data published this page? (Don't pretend to be a neutral third party)
• Are limitations of the comparison stated? ("This comparison focuses on time-series workloads; your evaluation may differ for other use cases")
• If information about the competitor was unavailable or unverifiable, is that noted?
• Are dates included so readers know when the comparison was last updated?

Common failures:

• Writing in a faux-neutral editorial voice that hides the publisher's identity
• Presenting the comparison as exhaustive when it covers a narrow slice of the products
• Not dating the content, leading to stale comparisons that damage credibility over time
• Burying the "we're Tiger Data" disclosure below the fold

Pre-publish quick scan

Before publishing, answer these five questions honestly:

1. Is there anything in this page that would embarrass us if a competitor screenshotted it? 2. Would a neutral analyst agree with our characterizations? 3. Have we acknowledged at least one area where the competitor is stronger? 4. Are all factual claims verifiable by a reader who checks? 5. Would a reader who ultimately chooses the competitor still find this page useful?

If any answer is "no," revise before publishing.

Competitor Page Templates

Structural templates for the four comparison page formats. Each template defines the page's job, search intent, URL pattern, target keywords, and section-by-section structure with writing guidance.

---

Format 1: [Competitor] Alternative (Singular)

The job: Convert a visitor who is actively looking to switch from a specific competitor. They have a pain point — validate it, then show how Tiger Data solves it.

Search intent: High commercial intent. The reader has a specific problem with their current tool and wants a replacement.

URL pattern: /alternatives/{competitor-slug} or /{competitor}-alternative

Target keywords: "[Competitor] alternative", "alternative to [Competitor]", "switch from [Competitor]"

Estimated length: 1,500-2,500 words

Section structure

1. Why people look for [Competitor] alternatives (2-3 paragraphs)

• Validate the reader's pain. What are the common frustrations that drive switching?
• Do NOT open with "Looking for a [Competitor] alternative?" — it's generic and adds no value.
• DO open with the specific problem that drives switching behavior. Lead with the pain, not the search query.
• Source frustrations from: review platforms, community forums, Tiger Den content search, user-provided context.

2. Tiger Data as the alternative (1 short section)

• TL;DR positioning: 2-3 sentences on why Tiger Data fits for readers who are scanning.
• This is the "quick answer" for skimmers — make it count.

3. Detailed comparison (longest section)

• Use the feature-by-feature table from comparison-table-patterns.md.
• Follow each table with paragraph explanations of the 3-4 dimensions that matter most.
• Go beyond features: include pricing model, support, ecosystem, and developer experience.

4. Who should switch (and who shouldn't)

• Be explicit: "Tiger Data is the right move if you need X, Y, or Z."
• Be equally explicit: "Stick with [Competitor] if you need A or B."
• This honesty is the trust-building move of the page.

5. Migration path

• What transfers cleanly, what needs reconfiguration, estimated effort level.
• Link to relevant Tiger Docs migration guides if they exist.
• If migration is complex, don't hide it. Address the complexity and describe the support available.

6. Social proof from switchers

• Customer quotes specifically about the switching experience (not generic testimonials).
• If no switcher quotes are available, use general proof points and note the gap for the team to fill.
• Include quantified results where possible ("After switching, [Company] saw X% improvement in Y").

7. CTA

• Primary: Start free trial or request demo.
• Supporting text: Reduce commitment anxiety. "No credit card required" or "See results in 15 minutes."

---

Format 2: [Competitor] Alternatives (Plural / Roundup)

The job: Help an early-stage evaluator understand the landscape. They're researching options, not ready to switch yet. Win by being the most helpful resource.

Search intent: Informational with commercial intent. The reader wants to understand their options.

URL pattern: /alternatives/{competitor-slug}-alternatives

Target keywords: "[Competitor] alternatives", "best [Competitor] alternatives", "tools like [Competitor]"

Estimated length: 2,500-4,000 words

Section structure

1. Why people look for [Competitor] alternatives (2-3 paragraphs)

• Common pain points driving the search. Be specific to this competitor.
• Tone: empathetic evaluator, not competitor-basher.

2. What to look for in an alternative (criteria framework)

• Define 5-7 evaluation criteria relevant to this category.
• This positions the reader to evaluate all options (including Tiger Data) on your terms.
• Keep criteria genuine — don't define criteria that only Tiger Data meets.

3. The alternatives (4-7 products)

• List Tiger Data first, but include real alternatives. Being genuinely helpful is the strategy.
• For each alternative: 2-3 paragraph overview, strengths, limitations, "best for" one-liner.
• Use the audience-fit table from comparison-table-patterns.md as a summary before the detailed breakdowns.

4. Summary comparison table

• Feature-by-feature or audience-fit table covering all listed alternatives.
• This is the scannable anchor of the page.

5. Recommendation by use case

• "If you need X, go with Y."
• Be honest. Not every use case should recommend Tiger Data.

6. CTA

• Softer than Format 1 — the reader is earlier in their journey.
• "Try Tiger Data free" alongside "Read our [Competitor] vs Tiger Data comparison" (link to Format 3 page if it exists).

---

Format 3: Tiger Data vs [Competitor] (Direct Comparison)

The job: Help an evaluator who is actively comparing Tiger Data against a specific competitor make a confident decision. This page should be the most comprehensive, honest resource for this specific comparison.

Search intent: High commercial intent. The reader is in active evaluation and likely comparing multiple sources.

URL pattern: /vs/{competitor-slug} or /compare/tigerdata-vs-{competitor-slug}

Target keywords: "Tiger Data vs [Competitor]", "[Competitor] vs Tiger Data", "TimescaleDB vs [Competitor product]"

Estimated length: 2,000-3,500 words

Section structure

1. TL;DR summary (2-3 sentences)

• Key differences in plain language. A reader who only reads this paragraph should walk away informed.

2. At-a-glance comparison table

• Feature-by-feature table from comparison-table-patterns.md.
• 8-12 dimensions maximum. More than that becomes noise.

3. Detailed comparison by dimension (3-5 most important dimensions)

• For each dimension: explain what each product does, why the difference matters, and who it matters to.
• This is where the page earns its depth. Don't just restate the table — add context, examples, and nuance.
• Include architecture or approach explanations where they help the reader understand the tradeoff.

4. Pricing comparison

• Use the pricing comparison table from comparison-table-patterns.md.
• Address total cost of ownership, not just list prices.

5. Who Tiger Data is best for

• Specific personas, use cases, and team profiles.

6. Who [Competitor] is best for

• Be genuine. If the competitor is better for certain use cases, say so.
• This section is what makes the page trustworthy.

7. What customers say

• Quotes from customers who evaluated both, or switched from the competitor.
• If unavailable, note the gap.

8. Migration path

• Same structure as Format 1, Section 5.

9. CTA

• Primary: trial or demo.
• Secondary: link to related comparison pages or migration documentation.

---

Format 4: [Competitor A] vs [Competitor B] (Third-Party Comparison)

The job: Capture search traffic for a competitor-vs-competitor query by providing a genuinely useful comparison, then introduce Tiger Data as a third option. The page must be useful even if the reader ignores Tiger Data entirely.

Search intent: Informational. The reader is comparing two products — neither of which is yours.

URL pattern: /compare/{competitor-a}-vs-{competitor-b}

Target keywords: "[Competitor A] vs [Competitor B]", "[Competitor B] vs [Competitor A]"

Estimated length: 2,000-3,000 words

Section structure

1. Overview of both products (1 paragraph each)

• Neutral, factual summaries. You are an analyst here, not a competitor.

2. Comparison by dimension (5-7 dimensions)

• Fair, balanced analysis of both products.
• Use the three-way comparison table from comparison-table-patterns.md but keep the narrative focused on the two competitors until Section 4.

3. Who each is best for

• Honest "best for" recommendations for each competitor.

4. The third option (introduce Tiger Data)

• Transition naturally: "If neither fully fits your needs, there's a third approach worth considering."
• Position Tiger Data against the specific gaps or tradeoffs identified in the comparison above.
• Keep this section shorter than the main comparison. You're a guest in this evaluation, not the host.

5. Three-way comparison table

• Tiger Data in the last column, not the first.
• Include only dimensions already discussed. Don't add new dimensions just to showcase Tiger Data.

6. CTA

• Soft: "Explore Tiger Data as an alternative" or "See how Tiger Data compares."
• The reader came for A vs B — don't hard-sell.

---

Section Scaffolding

Reusable markdown scaffolding for common sections across all formats. Use these as starting points — adapt the structure to fit the specific comparison, don't fill them in mechanically.

TL;DR Summary

**TL;DR**: [Competitor] excels at [strength] but struggles with [weakness].
Tiger Data is built for [focus], offering [key differentiator].
Choose [Competitor] if [their ideal use case]. Choose Tiger Data if [your ideal use case].

Paragraph Comparison

For each major dimension, write a paragraph pair — not just a table row. This is where the page earns depth.

## [Dimension Name]

[Competitor] offers [description of their approach]. Their strength is [specific strength],
which works well for [use case]. However, [limitation] can be challenging for [user type].

Tiger Data takes a different approach with [Tiger Data's approach]. This means [benefit],
though [honest tradeoff]. Teams who [specific need] often find this more effective.

Feature Comparison Section

Go beyond checkmarks. For each feature category, describe both sides and give a bottom line.

## Feature Comparison

### [Feature Category]

**[Competitor]**: [2-3 sentence description of how they handle this]
- Strengths: [specific]
- Limitations: [specific]

**Tiger Data**: [2-3 sentence description]
- Strengths: [specific]
- Limitations: [specific]

**Bottom line**: Choose [Competitor] if [scenario]. Choose Tiger Data if [scenario].

Pricing Comparison Section

## Pricing

| | [Competitor] | Tiger Data |
|---|---|---|
| Free tier | [Details] | [Details] |
| Starting price | [Price + what's included] | [Price + what's included] |
| Growth tier | [Price + what's included] | [Price + what's included] |
| Enterprise | [Pricing model] | [Pricing model] |

**What's included**: [Competitor]'s [tier] plan includes [features], while
Tiger Data's [tier] plan includes [features].

**Total cost consideration**: Beyond base pricing, consider [hidden costs,
add-ons, egress, overages]. [Competitor] charges extra for [X], while
Tiger Data includes [Y] in base pricing.

Service and Support Comparison

## Service and Support

| | [Competitor] | Tiger Data |
|---|---|---|
| Documentation | [Quality assessment] | [Quality assessment] |
| Response time | [SLA if known] | [SLA] |
| Support channels | [List] | [List] |
| Onboarding | [What they offer] | [What Tiger Data offers] |
| Dedicated CSM | [At what tier] | [At what tier] |

**Support quality**: Based on [G2/Capterra reviews, research],
[Competitor] support is described as [assessment]. Common feedback
includes [themes].

Tiger Data offers [support approach]. [Specific differentiator].

Who It's For Section

## Who Should Choose [Competitor]

[Competitor] is the right choice if:
- [Specific use case or need]
- [Team type or size]
- [Workflow or requirement]

**Ideal [Competitor] user**: [Persona description in 1-2 sentences]

## Who Should Choose Tiger Data

Tiger Data is built for teams who:
- [Specific use case or need]
- [Team type or size]
- [Workflow or requirement]

**Ideal Tiger Data user**: [Persona description in 1-2 sentences]

Migration Section

## Switching from [Competitor]

### What transfers
- [Data type]: [How easily, any caveats]
- [Data type]: [How easily, any caveats]

### What needs reconfiguration
- [Component]: [Why and effort level]
- [Component]: [Why and effort level]

### Migration support

Tiger Data offers [migration support details]:
- [Tools, guides, or white-glove assistance]
- [Documentation or migration guide links]
- [Timeline expectation]
- [Support during transition]

### What customers say about switching

> "[Specific quote about why they switched and the outcome]"
> — [Name], [Role] at [Company]

Social Proof Section

Focus on switchers, not generic testimonials.

## What Customers Say

### Switched from [Competitor]

> "[Specific quote about why they switched and outcome]"
> — [Name], [Role] at [Company]

> "[Another quote]"
> — [Name], [Role] at [Company]

### Results after switching
- [Company] saw [specific result] after migrating from [Competitor]
- [Company] reduced [metric] by [amount]