feat: content expansion — comparisons, richer use cases, updated nav

src/app/compare/[slug]/page.tsx

@@ -0,0 +1,49 @@
+import { notFound } from "next/navigation";
+import { compareNav } from "@/lib/compare-nav";
+import Link from "next/link";
+
+export function generateStaticParams() {
+  return compareNav.map((c) => ({ slug: c.slug }));
+}
+
+export default async function ComparePage({
+  params,
+}: {
+  params: Promise<{ slug: string }>;
+}) {
+  const { slug } = await params;
+  const comparison = compareNav.find((c) => c.slug === slug);
+  if (!comparison) notFound();
+  try {
+    const Content = (await import(`@/content/compare/${slug}.mdx`)).default;
+    return (
+      <div>
+        <Link
+          href="/compare"
+          className="text-accent-cyan hover:underline text-sm mb-6 block"
+        >
+          &larr; All Comparisons
+        </Link>
+        <Content />
+        <div className="mt-12 p-8 bg-gradient-to-br from-accent-warm/10 to-accent-rose/10 border border-accent-warm/20 rounded-2xl text-center">
+          <h3 className="text-xl font-semibold text-text-primary mb-2">
+            Try BugDrop free
+          </h3>
+          <p className="text-text-subtle mb-4">
+            Add screenshot-powered bug reporting to any site in under a minute.
+          </p>
+          <a
+            href="https://github.com/apps/neonwatty-bugdrop/installations/new"
+            target="_blank"
+            rel="noopener noreferrer"
+            className="inline-flex items-center gap-2 px-6 py-3 rounded-[10px] font-medium bg-gradient-to-br from-accent-warm to-accent-rose text-bg-deep hover:-translate-y-0.5 transition-all duration-300"
+          >
+            Install GitHub App
+          </a>
+        </div>
+      </div>
+    );
+  } catch {
+    notFound();
+  }
+}

src/app/compare/page.tsx

@@ -0,0 +1,30 @@
+import Link from "next/link";
+import { compareNav } from "@/lib/compare-nav";
+
+export const metadata = {
+  title: "Compare — BugDrop",
+  description: "See how BugDrop compares to other feedback tools.",
+};
+
+export default function CompareIndex() {
+  return (
+    <div>
+      <h1 className="text-3xl font-bold text-text-primary mb-2">Compare</h1>
+      <p className="text-text-subtle mb-10">
+        See how BugDrop compares to other feedback tools.
+      </p>
+      <div className="grid grid-cols-[repeat(auto-fit,minmax(280px,1fr))] gap-6">
+        {compareNav.map((c) => (
+          <Link
+            key={c.slug}
+            href={`/compare/${c.slug}`}
+            className="bg-bg-surface border border-border rounded-2xl p-7 transition-all duration-300 hover:-translate-y-1 hover:border-accent-warm hover:shadow-[0_20px_40px_rgba(0,0,0,0.3)] no-underline"
+          >
+            <h2 className="text-lg font-semibold text-text-primary mb-2">{c.title}</h2>
+            <p className="text-sm text-text-subtle leading-relaxed">{c.description}</p>
+          </Link>
+        ))}
+      </div>
+    </div>
+  );
+}

src/app/sitemap.ts

@@ -14,5 +14,9 @@ export default function sitemap(): MetadataRoute.Sitemap {
     { url: `${base}/use-cases/open-source`, lastModified: new Date(), changeFrequency: "monthly", priority: 0.6 },
     { url: `${base}/use-cases/internal-tools`, lastModified: new Date(), changeFrequency: "monthly", priority: 0.6 },
     { url: `${base}/use-cases/client-projects`, lastModified: new Date(), changeFrequency: "monthly", priority: 0.6 },
+    { url: `${base}/compare`, lastModified: new Date(), changeFrequency: "monthly", priority: 0.8 },
+    { url: `${base}/compare/userback`, lastModified: new Date(), changeFrequency: "monthly", priority: 0.7 },
+    { url: `${base}/compare/canny`, lastModified: new Date(), changeFrequency: "monthly", priority: 0.7 },
+    { url: `${base}/compare/sentry-user-feedback`, lastModified: new Date(), changeFrequency: "monthly", priority: 0.7 },
   ];
 }

src/components/nav.tsx

@@ -13,6 +13,9 @@ export function Nav() {
         <Link href="/use-cases" className="text-sm text-text-subtle hover:text-text-primary transition-colors">
           Use Cases
         </Link>
+        <Link href="/compare" className="text-sm text-text-subtle hover:text-text-primary transition-colors">
+          Compare
+        </Link>
         <a
           href="https://github.com/mean-weasel/bugdrop"
           target="_blank"

src/content/compare/canny.mdx

@@ -0,0 +1,59 @@
+# BugDrop vs Canny
+
+BugDrop and Canny are both feedback tools, but they solve fundamentally different problems. BugDrop captures bug reports with screenshots and sends them to GitHub Issues. Canny collects feature requests, organizes them with voting boards, and helps product teams prioritize what to build next. Understanding this distinction is key to choosing the right tool — or deciding to use both.
+
+## What is Canny?
+
+Canny is a feature request and feedback management platform. It provides public-facing boards where users can submit ideas, vote on existing suggestions, and comment on feature requests. Product teams use Canny to understand what their users want most, prioritize their roadmap based on real demand, and communicate progress through a public changelog.
+
+Canny's core workflow is built around voting and prioritization. Users submit feature requests, other users upvote them, and the product team uses the aggregated votes to decide what to build next. Canny integrates with tools like Jira, Linear, and Intercom, and offers a public roadmap view so users can see what is planned, in progress, and shipped. Pricing starts with a free tier for small teams and scales to paid plans for advanced features.
+
+## What is BugDrop?
+
+BugDrop is an open-source bug reporting widget. It captures what users see right now — a broken layout, a rendering error, an incorrect data display — and turns that into a GitHub Issue with a screenshot, annotations, and system information. BugDrop is not designed for feature requests, roadmap planning, or voting. It is designed to catch bugs quickly and route them to the team's existing issue tracker.
+
+BugDrop is MIT licensed, free to use, and requires only a single script tag to install. Reports go directly to GitHub Issues, where development teams already manage their work.
+
+## The Key Difference
+
+Canny answers the question: "What should we build next?"
+BugDrop answers the question: "What is broken right now?"
+
+These are complementary problems. A team might use Canny to collect and prioritize feature requests from their user base while using BugDrop to catch visual bugs on their staging site, documentation, or production application. The tools do not compete — they serve different stages of the product feedback loop.
+
+## Feature Comparison
+
+| Feature | BugDrop | Canny |
+|---|---|---|
+| **Price** | Free / MIT | Free tier + paid plans |
+| **Primary use** | Bug reports with screenshots | Feature requests and voting |
+| **Screenshots** | Yes (with annotations) | No (text-based submissions) |
+| **Voting / roadmap** | No | Yes (core feature) |
+| **GitHub integration** | Native (creates Issues) | Integration available |
+| **Setup complexity** | 1 script tag | Account + board configuration |
+| **User accounts needed** | No | Optional (for voting tracking) |
+
+## When to Choose BugDrop
+
+BugDrop is the right choice when you need to catch and fix bugs efficiently:
+
+- **Catching visual bugs** — when users encounter rendering issues, layout problems, or visual regressions, BugDrop captures exactly what they see with an annotated screenshot. This is the fastest path from "something looks wrong" to a developer understanding and fixing the issue.
+- **GitHub-native workflow** — if your team tracks work in GitHub Issues and PRs, BugDrop feeds reports directly into that workflow with no additional tools or dashboards. Issues include screenshots, system info, and page URLs.
+- **Open source projects** — BugDrop is free and MIT licensed, making it ideal for OSS projects that want to collect bug reports from community users on documentation and demo sites.
+- **Low-friction reporting** — reporters do not need accounts, do not need to navigate a feedback board, and do not need to check if someone already reported the same issue. They click, describe, annotate, and submit.
+- **Staging and preview environments** — embed BugDrop on staging sites during client review or QA passes to collect visual feedback as trackable GitHub Issues.
+
+## When to Choose Canny
+
+Canny is the right choice when you need to understand and prioritize user demand:
+
+- **Feature prioritization** — when you want to know which features your users care about most, Canny's voting system aggregates demand and surfaces the most-requested items.
+- **Public roadmaps** — if transparency about your product direction is important, Canny's roadmap and changelog features let users see what is planned and what has shipped.
+- **User engagement** — Canny creates a community around your product's future direction, where users discuss ideas, refine suggestions, and feel heard.
+- **Cross-tool workflows** — if your team uses Jira, Linear, or another project management tool rather than GitHub Issues, Canny's integrations provide a broader fit.
+
+## Using Both Together
+
+Many teams benefit from using BugDrop and Canny together. Canny collects and prioritizes feature requests through its voting boards, giving the product team clarity on what to build. BugDrop sits on the live application and catches bugs as users encounter them, routing visual reports to GitHub Issues where the engineering team works.
+
+This combination covers both halves of the user feedback loop — proactive feature planning with Canny and reactive bug fixing with BugDrop — without either tool stepping on the other's toes.

src/content/compare/sentry-user-feedback.mdx

@@ -0,0 +1,63 @@
+# BugDrop vs Sentry User Feedback
+
+BugDrop and Sentry's User Feedback widget both collect feedback from users, but they trigger at different moments and serve different purposes. BugDrop lets users proactively report what they see. Sentry captures feedback in response to errors that the application has already detected. Understanding when each tool activates is the key to choosing between them — or using both.
+
+## What is Sentry User Feedback?
+
+Sentry is a production error monitoring platform used by thousands of development teams. When an application throws an unhandled exception, Sentry captures the error, stack trace, breadcrumbs, and user context. Sentry's User Feedback widget extends this by prompting the user to describe what they were doing when the error occurred. The feedback is attached to the error event, giving developers both the technical stack trace and the user's perspective.
+
+Sentry's feedback is error-triggered. The widget appears when the application encounters a JavaScript exception, a failed API call, or another error that Sentry's SDK detects. If the application is working correctly but something looks wrong visually — a misaligned layout, incorrect data, a missing image — Sentry's feedback widget will not activate because there is no error event to trigger it.
+
+Sentry's pricing is based on event volume, with a free tier for small projects and paid plans for higher volumes and advanced features.
+
+## What is BugDrop?
+
+BugDrop is an open-source feedback widget that lets users report bugs at any time, regardless of whether the application has thrown an error. The user clicks a feedback button, describes the issue, and the widget captures an annotated screenshot. The report is submitted as a GitHub Issue with the description, screenshot, system information, and page URL.
+
+BugDrop is user-initiated. It is always available as a button on the page, and the user decides when something looks wrong and worth reporting. This captures a class of issues that automated error monitoring misses entirely — visual bugs, content errors, UX confusion, and design regressions that do not throw exceptions.
+
+## The Key Difference
+
+Sentry User Feedback is reactive — it responds to errors the application has already detected.
+BugDrop is proactive — it lets users report issues the application does not know about.
+
+A CSS bug that causes a button to render off-screen will never trigger a Sentry error. A data display issue where the chart shows the wrong numbers but the API returned a 200 response will not appear in Sentry. A confusing user flow that leads people to the wrong page is invisible to error monitoring. These are the issues BugDrop catches.
+
+Conversely, a JavaScript exception that crashes a feature may not be visually obvious to the user, but Sentry captures it with a full stack trace. BugDrop would only know about it if the user notices something wrong and reports it.
+
+## Feature Comparison
+
+| Feature | BugDrop | Sentry User Feedback |
+|---|---|---|
+| **Price** | Free / MIT | Free tier + usage-based pricing |
+| **Trigger** | User-initiated (always available) | Error-triggered (appears on exceptions) |
+| **Screenshots** | Yes (with annotations) | No |
+| **Error context** | No (visual reports only) | Yes (stack traces, breadcrumbs) |
+| **Setup** | 1 script tag | Sentry SDK integration |
+| **GitHub Issues** | Yes (native) | Via Sentry-GitHub integration |
+| **Stack traces** | No | Yes |
+
+## When to Choose BugDrop
+
+BugDrop is the right choice when you need to capture issues that do not generate errors:
+
+- **Visual bugs** — layout regressions, styling issues, missing images, and rendering problems that look wrong to users but do not throw JavaScript exceptions. BugDrop's screenshot with annotations captures exactly what the user sees.
+- **Content and data errors** — when a chart shows the wrong data, a price is incorrect, or text is truncated, these are issues that only a human can identify. BugDrop gives users a way to flag them.
+- **User-reported UX issues** — confusing flows, misleading button labels, and unclear error messages are not application errors, but they matter. BugDrop captures the user's perspective with visual context.
+- **No error monitoring needed** — for simpler projects, documentation sites, or staging environments where full error monitoring is overkill, BugDrop provides lightweight feedback collection without the overhead of an error monitoring SDK.
+
+## When to Choose Sentry User Feedback
+
+Sentry's feedback widget makes sense when you already use Sentry and want to add user context to error reports:
+
+- **Production error tracking** — Sentry's core value is capturing and triaging production errors with stack traces, release tracking, and performance monitoring. The feedback widget adds the user's description to existing error events.
+- **Error context enrichment** — when you have a stack trace but do not know what the user was trying to do, Sentry's feedback connects the technical error to the user's experience.
+- **Crash reporting workflows** — if your error resolution workflow is built around Sentry's issue grouping, assignment, and alerting, keeping user feedback within the same platform maintains a single source of truth.
+
+## Using Both Together
+
+BugDrop and Sentry User Feedback are complementary tools that cover different parts of the quality spectrum. Sentry catches what the application knows is wrong — exceptions, failed requests, and performance regressions — and enriches those errors with user feedback. BugDrop catches what only users can see — visual bugs, data errors, and UX confusion — and routes those reports to GitHub Issues.
+
+Running both tools together gives your team comprehensive coverage. Sentry handles the automated error detection layer with deep technical context. BugDrop handles the human observation layer with visual context. Together, they ensure that neither machine-detectable errors nor human-observable issues slip through the cracks.
+
+For teams already using Sentry for error monitoring, adding BugDrop takes one script tag and provides the visual bug reporting that Sentry's feedback widget was not designed to cover.