DEV Community: Benji Darby

Surviving Vercel's Free Tier: 12 Serverless Functions, Zero Waste

Benji Darby — Thu, 30 Apr 2026 14:11:00 +0000

The Vercel Hobby plan gives you 12 serverless functions. That sounds like plenty until you're six months into building a SaaS and you start counting.

At IssueCapture — a drop-in widget that sends bug reports directly into Jira — we hit this wall faster than expected. Account management, API keys, analytics, Jira OAuth, payments, AI processing, widget submission, system utilities, admin operations. That's already eight distinct domains before you've split anything out.

We're currently sitting at 9 of 12 used. Getting there without burning through the limit required being deliberate about how we structure the API layer.

Why the Limit Bites You

Vercel counts any file in api/ as a serverless function. The instinct is to create a new file for each endpoint — it's clean, it's what every tutorial shows. But on the Hobby plan, that habit will strand you at the ceiling right when your product is getting interesting.

The good news: Vercel only counts top-level api/*.ts files.

Pattern 1: Action-Based Routing

Instead of api/team.ts, api/invites.ts, api/notifications.ts, consolidate into a single endpoint and route by ?action=:

// api/admin.ts
export default async function handler(req, res) {
  const { action } = req.query;

  const user = await getAuthenticatedUser(req);
  if (!user) return res.status(401).json({ error: 'Unauthorized' });

  switch (action) {
    case 'team-members-list':
      return handleListMembers(req, res, user, supabaseAdmin);
    case 'team-members-update-role':
      return handleUpdateMemberRole(req, res, user, supabaseAdmin);
    case 'team-invites-send':
      return handleSendInvite(req, res, user, supabaseAdmin);
    case 'notifications-list':
      return handleListNotifications(req, res, user, supabaseAdmin);
    case 'audit-logs-list':
      return handleListAuditLogs(req, res, user, supabaseAdmin);
    default:
      return res.status(400).json({ error: 'Invalid action' });
  }
}

Our api/admin.ts handles 27 distinct actions — team management, domain allowlisting, compliance exports, audit logs, notification CRUD, Jira field lookups, AI theme generation, user suspension, queued submission management. One file, one slot.

Pattern 2: The `_lib/` Directory

Vercel does not count files in api/_lib/ as serverless functions. This is where you put shared code and handler modules:

api/
  _lib/
    supabase.ts
    sentry.ts
    db-rate-limit.ts
    handlers/
      compliance.ts
      jira-fields.ts
      theme-generator.ts
      ... (17 handler files total)
  admin.ts   ← routes to all of the above
  submit.ts

Handler files are plain TypeScript modules that export functions. They don't register routes, don't deploy independently, don't count toward the limit. The top-level files do the routing.

Pattern 3: `.vercelignore` for Dev-Only Endpoints

Local test endpoints you don't want in production:

# .vercelignore
api/test-emails.ts
api/test-purchase-email.ts

They work locally via vercel dev, never reach production, never consume a slot.

How we organize the client side

On the dashboard, API calls use a consistent pattern:

async function adminAction(action: string, body?: object) {
  const response = await fetch(`/api/admin?action=${action}`, {
    method: body ? 'POST' : 'GET',
    headers: { 'Content-Type': 'application/json' },
    body: body ? JSON.stringify(body) : undefined,
  });
  return response.json();
}

// Usage
const members = await adminAction('team-members-list');
await adminAction('team-invites-send', { email: 'new@member.com', role: 'member' });

One wrapper function, one endpoint, many actions. The abstraction is thin enough that you can see exactly what's happening in the network tab.

The trade-offs

It's less REST-pure. GET /api/admin?action=team-members-list is not as clean as GET /api/team/members. For a public API, that matters. For an internal dashboard API consumed only by your own frontend, it generally doesn't.

Debugging is slightly harder. When everything goes through one endpoint, your Vercel logs show /api/admin for 27 different operations. We add the action name to Sentry breadcrumbs and log context to make this manageable.

Cold starts are shared. One large function has a longer cold start than 27 small ones. In practice, the admin endpoint stays warm because it handles most dashboard traffic.

Latency-sensitive endpoints stay separate. Our widget submission endpoint (api/submit.ts) is its own function because it's public-facing and needs to be as lean as possible. Don't consolidate everything — consolidate the internal stuff.

The math

9 production functions / 12 limit = 3 remaining

Those 9 functions serve:
- 27 admin actions
- 1 public submission endpoint
- 1 Jira OAuth flow
- 1 API key management
- 1 analytics endpoint
- 1 payment webhook
- 1 AI queue processor
- 1 account management
- 1 system utilities

Without action-based routing, we'd need 30+ functions. With it, we're at 9 with room for 3 more.

If you're bootstrapping on Vercel's free tier, the function limit will hit you eventually. Plan for it early. The action-routing pattern is ugly compared to a file-per-route convention, but it works, and it lets you ship a real product without upgrading your plan.

If you're on Vercel Hobby and you've found a way around the function limit that isn't action routing, I'd like to know. There's an argument for middleware-based routing that I haven't fully explored.

What to Include in a Bug Report: Console Errors, Network Logs, and Why Templates Aren't Enough

Benji Darby — Tue, 28 Apr 2026 13:22:00 +0000

It's standup. Someone picks up a ticket. The title says "Login broken." The description says "See screenshot" but there's no screenshot. Priority is marked "High" — which on this project means nothing, because everything is marked High.

The developer spends 20 minutes trying to reproduce, gives up, pings the reporter, waits four hours for a reply: "Oh I think it was in Firefox? Maybe Chrome." The ticket gets deprioritized. The user who reported it loses faith. The cycle repeats.

This isn't a process problem. It's a tooling problem.

Why most bug reports fail

The environment context is missing. "It doesn't work" with no browser, OS, viewport size, or URL. The developer has to guess, and their guess is wrong half the time.

The console had a red error that would have explained everything. The user didn't know to open DevTools. Even if they did, they wouldn't know which error was relevant.

The description is vague. "The page is weird" could mean a CSS misalignment, a broken layout, missing data, or a full crash. Without a screenshot, both sides waste time describing what they're seeing.

By the time the developer reads the ticket, the state that caused the bug is gone. The user's session expired, the cache cleared, the deployment rolled forward. Stale reproduction steps are worse than no steps at all because they send you down the wrong path.

And the bug was probably caused by a failed API call that returned a 403. The user saw "something went wrong." The developer sees nothing in the logs because the client never reported which endpoint failed.

What a good bug report actually contains

Every bug report that doesn't waste time has these:

Summary — one sentence describing the symptom, not the cause
URL — exact page where it happened
Browser and OS — including version
Screenshot — ideally annotated to highlight what's wrong
Console errors — from the session, not just the moment of reporting
Network failures — any 4xx/5xx responses from the page
Steps to reproduce — what the user was doing when it happened
Expected vs actual behavior — what they thought should happen

That's a lot to ask a human to collect manually. Most won't, and you can't blame them.

Why templates don't work

The common answer is "add a bug report template." Jira templates, GitHub issue templates, Google Forms with required fields.

Templates help with structure, but they fail at context. A user filling out "Browser: Chrome" doesn't know their version. They won't open DevTools to copy console errors. They won't check the Network tab. And they'll skip "Steps to reproduce" with "see above" nine times out of ten.

The information that matters most — console errors, network failures, browser version, exact URL — is already available in the browser at the moment the user encounters the bug. The problem is that nobody captures it.

The tooling approach

Instead of asking users to collect technical context, collect it for them.

Capture console errors from page load — not when the report form opens, but when the page loads. The error that caused the bug happened before the user decided to report it. Patch fetch and XMLHttpRequest to log response status codes. A 500 from /api/checkout is worth more than any written description.

Browser metadata (user agent, viewport, URL, timezone) is already available via JavaScript without any user input. Screenshot annotation lets the user capture and draw on their screen — a red circle around "this button does nothing" eliminates 80% of the back-and-forth.

And if the report goes straight to the issue tracker with all context attached, nobody has to copy-paste from a form into a ticket. The ticket is the report.

The checklist

If you're evaluating how to improve bug report quality on your team, here's what to audit:

[ ] Are console errors captured automatically, or does the user have to copy them?
[ ] Are failed network requests included in reports?
[ ] Is the browser/OS/URL captured without user input?
[ ] Can users annotate screenshots within the reporting flow?
[ ] Do reports go directly into your issue tracker, or is there a manual step?
[ ] Is the report captured at the moment of the bug, or after the user navigates away?

If you answered "no" to more than two of these, your bug reports are probably costing your team hours per week in triage and back-and-forth.

Privacy matters

One objection I hear: "We can't capture console errors and network requests — that's sensitive data."

This is valid and important. Any system that captures this data needs:

Domain exclusions — never log requests to payment processors, auth providers
URL sanitization — strip query parameters and path segments that contain IDs or tokens
User consent — the user initiates the report and can see what's being sent
Admin control — the team admin decides what categories of data are captured

Capturing everything and filtering nothing is a privacy violation. Capturing nothing and asking the user to collect it manually is a productivity violation. The middle ground is automated capture with explicit filtering and user visibility.

This is the problem I built IssueCapture to solve — a widget that captures all of this automatically when a user reports a bug, and creates the Jira ticket with full context. But the principles apply regardless of what tool you use. Better bug reports come from better tooling, not better templates.

The teams I've talked to who stopped fighting bug report quality all did the same thing: they stopped relying on the reporter and started capturing the data automatically.

Dynamic Import in Production: How We Kept a Bug Reporting Widget Under 40KB

Benji Darby — Thu, 23 Apr 2026 17:47:00 +0000

Every KB you ship to someone else's site is a KB you didn't ask permission to ship. If a dependency is over 20KB gzipped and used in less than 80% of sessions, it should be lazy-loaded.

When we built IssueCapture — a bug-reporting widget that injects into your customers' production sites — bundle size wasn't a nice-to-have. It was a hard constraint. Nobody gives you a second chance if your widget adds 300KB to their LCP.

Our final numbers: 40KB gzipped for the core widget, 13KB for screenshot capture, 107KB for the annotation canvas. The last two load only when the user explicitly needs them. Here's how we structured that.

The problem with eager imports

import { html2canvas } from 'html2canvas';
import { fabric } from 'fabric';

Both libraries land in your initial bundle whether or not the user ever clicks the annotation tool. Fabric.js alone is 107KB gzipped. The fix is dynamic import().

Dynamic import basics

import() is a function that returns a promise. The browser only fetches the module when execution hits that line.

async function openAnnotationTool() {
  const { fabric } = await import('fabric');
  const canvas = new fabric.Canvas('c');
}

The chunk gets fetched on demand, cached by the browser, and never shipped to users who don't need it.

How we structured it

let screenshotModule = null;
let annotationModule = null;

async function loadScreenshot() {
  if (!screenshotModule) {
    screenshotModule = await import('./screenshot');
  }
  return screenshotModule;
}

async function loadAnnotation() {
  if (!annotationModule) {
    annotationModule = await import('./annotation');
  }
  return annotationModule;
}

Caching the module reference means subsequent calls are synchronous lookups — skipping the await entirely on repeat calls keeps your UI snappy.

Loading states matter

The one place developers get lazy-loading wrong is the loading state. If you fire import() on a button click and show nothing for 500ms, users will click again.

async function handleScreenshotClick() {
  setLoadingState('screenshot');

  try {
    const { captureScreenshot } = await loadScreenshot();
    const imageData = await captureScreenshot(document.body);
    setScreenshotData(imageData);
  } catch (err) {
    setError('Screenshot failed to load');
  } finally {
    setLoadingState(null);
  }
}

The spinner is essential. Users who click and see immediate feedback will wait. Users who click and see nothing will leave.

Preload hints for the likely path

If someone opens the bug report modal, there's a decent chance they'll want a screenshot. Start fetching in the background:

function handleModalOpen() {
  setModalOpen(true);

  import('./screenshot').catch(() => {
    // Silently ignore prefetch failures
  });
}

Or programmatically:

function preloadChunk(src) {
  const link = document.createElement('link');
  link.rel = 'modulepreload';
  link.href = src;
  document.head.appendChild(link);
}

The tradeoff: prefetching consumes bandwidth even if the user never triggers the feature. Use it for high-probability paths only. Screenshot capture is used in roughly 60% of our reports, so the prefetch pays off.

Measuring the actual impact

Lighthouse for LCP and TTI:

npx lighthouse https://example.com \
  --output json \
  --chrome-flags="--headless" \
  | jq '.audits["largest-contentful-paint"].numericValue'

Splitting the screenshot module off the initial bundle improved TTI by roughly 180ms on simulated 4G.

Bundle analyzer (Vite):

import { visualizer } from 'rollup-plugin-visualizer';

export default {
  plugins: [
    visualizer({ open: true, gzip: true })
  ]
};

Look for large modules in your entry chunk — those are candidates for lazy-loading.

When lazy-loading is not the answer

For features that nearly all users need in nearly all sessions, just ship them eagerly. The mental overhead of managing async loading states is real. Only take it on when the size savings are meaningful.

We ship a 40KB widget that can grow to 160KB when fully loaded — but most users never see that 160KB. They see 40KB, and the rest loads invisibly when they need it.

Where this pattern breaks down: if your lazy-loaded chunk is on a CDN with a cold cache and the user is on a flaky mobile connection, the loading state becomes the experience. We haven't solved that cleanly yet.

How to Capture Console Errors and Network Requests in JavaScript

Benji Darby — Tue, 21 Apr 2026 19:42:00 +0000

When a user reports a bug, the information you actually need is already gone. The console error that triggered it fired three page loads ago. The failed network request happened before they even thought to open a ticket.

The fix is to capture this data continuously — from page load, not from the moment the user clicks "report a bug". Here's how to build that from scratch.

Intercepting console.error

The browser's console object is just a plain JavaScript object. Its methods are writable, which means you can swap them out.

const errors = [];
const originalConsoleError = console.error;

console.error = function (...args) {
  errors.push({
    type: 'console.error',
    message: args.map(arg => String(arg)).join(' '),
    timestamp: Date.now(),
  });

  originalConsoleError.apply(console, args);
};

Always store a reference to the original before patching — you'll call through to it so DevTools still works. .apply(console, args) matters because some internal console implementations check that this is the console object.

Catching uncaught errors and promise rejections

Console patches only catch what code explicitly logs. For uncaught exceptions and unhandled promise rejections:

window.addEventListener('error', (event) => {
  errors.push({
    type: 'uncaught_error',
    message: event.message,
    source: event.filename,
    line: event.lineno,
    col: event.colno,
    stack: event.error?.stack ?? null,
    timestamp: Date.now(),
  });
});

window.addEventListener('unhandledrejection', (event) => {
  errors.push({
    type: 'unhandled_rejection',
    message: String(event.reason),
    stack: event.reason?.stack ?? null,
    timestamp: Date.now(),
  });
});

The error event gives you the filename, line number, and column — useful for mapping back to source maps. The unhandledrejection event fires when a Promise rejects and nothing catches it.

Intercepting network requests

fetch

const requests = [];
const originalFetch = window.fetch;

window.fetch = async function (input, init) {
  const url = typeof input === 'string' ? input : input.url;
  const method = init?.method ?? 'GET';
  const startTime = Date.now();

  try {
    const response = await originalFetch.apply(this, arguments);

    requests.push({
      type: 'fetch',
      url,
      method,
      status: response.status,
      duration: Date.now() - startTime,
      timestamp: startTime,
    });

    return response;
  } catch (err) {
    requests.push({
      type: 'fetch',
      url,
      method,
      status: null,
      error: String(err),
      duration: Date.now() - startTime,
      timestamp: startTime,
    });
    throw err;
  }
};

Note the throw err at the end of the catch block. Never silently swallow errors in a wrapper.

XMLHttpRequest

Plenty of libraries still use XHR under the hood. You need to patch both.

const OriginalXHR = window.XMLHttpRequest;

window.XMLHttpRequest = function () {
  const xhr = new OriginalXHR();
  const meta = { url: null, method: null, startTime: null };

  const originalOpen = xhr.open.bind(xhr);
  xhr.open = function (method, url, ...rest) {
    meta.method = method;
    meta.url = url;
    return originalOpen(method, url, ...rest);
  };

  const originalSend = xhr.send.bind(xhr);
  xhr.send = function (...args) {
    meta.startTime = Date.now();

    xhr.addEventListener('loadend', () => {
      requests.push({
        type: 'xhr',
        url: meta.url,
        method: meta.method,
        status: xhr.status,
        duration: Date.now() - meta.startTime,
        timestamp: meta.startTime,
      });
    });

    return originalSend(...args);
  };

  return xhr;
};

Privacy considerations

Raw network logs are a liability. URLs frequently contain sensitive data.

Sanitize URLs

function sanitizeUrl(url) {
  try {
    const parsed = new URL(url);
    parsed.search = '';
    parsed.pathname = parsed.pathname
      .split('/')
      .map(segment => /^[a-f0-9-]{8,}$/i.test(segment) ? '[id]' : segment)
      .join('/');
    return parsed.toString();
  } catch {
    return '[invalid url]';
  }
}

Exclude sensitive domains

const EXCLUDED_DOMAINS = ['stripe.com', 'paypal.com', 'auth0.com'];

function shouldCapture(url) {
  try {
    const hostname = new URL(url).hostname;
    return !EXCLUDED_DOMAINS.some(domain => hostname.endsWith(domain));
  } catch {
    return false;
  }
}

Filter by path pattern

const EXCLUDED_PATTERNS = ['/auth/', '/login', '/password', '/token'];

function isExcludedPath(url) {
  try {
    const { pathname } = new URL(url);
    return EXCLUDED_PATTERNS.some(pattern => pathname.includes(pattern));
  } catch {
    return true;
  }
}

Capture early, filter late

Start capturing from page load. Store everything in memory. When a report is generated, apply your filters before anything leaves the browser.

function getRecentErrors(limitMs = 60_000) {
  const cutoff = Date.now() - limitMs;
  return errors.filter(e => e.timestamp >= cutoff);
}

function getRelevantRequests(limitMs = 60_000) {
  const cutoff = Date.now() - limitMs;
  return requests
    .filter(r => r.timestamp >= cutoff)
    .filter(r => shouldCapture(r.url) && !isExcludedPath(r.url))
    .map(r => ({ ...r, url: sanitizeUrl(r.url) }));
}

This means you never miss an error that happened before the report was triggered, but you also never send data you haven't explicitly decided to include.

A few things to watch for

Memory. If a user leaves a tab open for hours, these arrays will grow. Add a max-size cap or a rolling window.

Third-party script errors. The error event will catch errors from third-party scripts, often with message: "Script error." and no useful stack. This is a browser security feature (CORS). Filter these out by checking event.filename.

Content Security Policy. If your site's CSP blocks inline scripts, make sure your logger is loaded as a proper module.

Sentry, LogRocket, and every other browser monitoring tool does exactly this under the hood. The pieces take an afternoon to build. The value is in running them from page load, before the user knows they need to file a report.

Row-Level Security in Supabase: Multi-Tenant SaaS from Day One

Benji Darby — Thu, 16 Apr 2026 16:00:00 +0000

In a multi-tenant SaaS, one misplaced query can leak another customer's data. Row-Level Security moves that enforcement into the database, where it can't be skipped by a tired developer or a missing middleware.

I went all-in on RLS from the start with IssueCapture. Every table has it. Every query is automatically scoped to the right account. No WHERE account_id = $1 that future-me accidentally omits. We're running around 29 RLS-protected tables in production. Here's how it works and where it'll bite you.

What RLS Actually Does

Row-Level Security is a PostgreSQL feature that lets you attach policies to tables. When RLS is enabled, a SELECT, INSERT, UPDATE, or DELETE only succeeds for rows that pass the policy check.

ALTER TABLE issues ENABLE ROW LEVEL SECURITY;

CREATE POLICY "Users see own issues"
  ON issues FOR SELECT
  USING (user_id = auth.uid());

Supabase builds on top of this with auth.uid() — a function that returns the UUID of the authenticated user from the JWT.

But user-level isolation is the easy case. Most SaaS apps need account-level isolation, where multiple users share data within a tenant.

The team_members Join Pattern

The pattern I use for multi-tenant isolation:

accounts table — one row per tenant
team_members table — many-to-many between auth.users and accounts
Everything else — has an account_id foreign key

CREATE TABLE accounts (
  id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  name text NOT NULL,
  subscription_tier text DEFAULT 'free'
);

CREATE TABLE team_members (
  user_id uuid REFERENCES auth.users(id) ON DELETE CASCADE,
  account_id uuid REFERENCES accounts(id) ON DELETE CASCADE,
  role text DEFAULT 'member',
  PRIMARY KEY (user_id, account_id)
);

CREATE TABLE issues (
  id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  account_id uuid REFERENCES accounts(id) ON DELETE CASCADE,
  title text NOT NULL,
  created_at timestamptz DEFAULT now()
);

Now the RLS policy on issues checks membership:

ALTER TABLE issues ENABLE ROW LEVEL SECURITY;

CREATE POLICY "Team members can view account issues"
  ON issues FOR SELECT
  USING (
    account_id IN (
      SELECT account_id FROM team_members
      WHERE user_id = auth.uid()
    )
  );

This single subquery does the tenant isolation. Any user who is a member of the account can read its issues. Non-members get zero rows — not an error, just nothing.

The `service_role` Key Bypasses All RLS Policies

The service role key bypasses RLS entirely.

Supabase gives you two keys:

anon key — respects RLS, safe to expose in the browser
service_role key — superuser, skips all RLS policies, never expose this

// Browser / user-facing: RLS enforced
const supabase = createClient(url, process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY);

// Server / admin: RLS bypassed — be careful
const supabaseAdmin = createClient(url, process.env.SUPABASE_SERVICE_KEY);

The rule I follow: API routes that handle user requests use the anon key with the user's JWT. Internal jobs and admin operations use the service key explicitly.

The failure mode if you get this wrong is data leakage across tenants. You won't notice in testing because your test user probably has access to everything in your dev database.

Policies on JOINed Tables

Another common pitfall: you write a policy on table A, but your query joins to table B, and table B also has RLS enabled. Each table's policy is checked independently.

SELECT c.* FROM comments c
JOIN issues i ON i.id = c.issue_id
WHERE i.account_id = $1;

If the user doesn't have access to a given issues row, the join will return no matching row for it — the comment becomes invisible even if the comments policy would technically allow it. The query doesn't error, it just returns fewer rows than you expect.

The fix is being explicit about what each table's policies need to allow.

Performance: The Subquery Problem

The account_id IN (SELECT account_id FROM team_members WHERE user_id = auth.uid()) pattern executes that subquery on every row evaluation. For large tables, this can be slow.

Index the foreign keys:

CREATE INDEX ON issues (account_id);
CREATE INDEX ON team_members (user_id);
CREATE INDEX ON team_members (account_id);

Consider a security definer function for complex membership checks:

CREATE OR REPLACE FUNCTION get_accessible_account_ids()
RETURNS SETOF uuid
LANGUAGE sql
SECURITY DEFINER
STABLE
AS $$
  SELECT account_id FROM team_members
  WHERE user_id = auth.uid()
$$;

CREATE POLICY "Team members can view account issues"
  ON issues FOR SELECT
  USING (account_id IN (SELECT get_accessible_account_ids()));

SECURITY DEFINER means the function runs with the permissions of whoever defined it, which lets it bypass RLS on team_members itself. STABLE tells the planner the function won't change the database — this enables caching and better optimization.

Testing RLS Policies

The best way to test a policy is to set the role and JWT claim manually:

BEGIN;

SET LOCAL role = 'authenticated';
SET LOCAL "request.jwt.claims" = '{"sub": "user-uuid-here"}';

SELECT * FROM issues;

ROLLBACK;

It's much more reliable than inferring correctness from application behavior, because application bugs can mask policy bugs.

Why RLS Will Hurt You (and Why You Should Still Use It)

RLS is not free. The policies add overhead to every query, the service key bypass is a footgun, and debugging policy interactions across joined tables takes practice.

But for a multi-tenant SaaS, application-layer filtering is worse. The guarantee that a bug in your API code cannot leak tenant data is worth the overhead. When your database is the last line of defense, it tends to actually hold.

I'm specifically interested in cases where RLS policies on joined tables produced surprising results — rows disappearing from queries for non-obvious reasons. That was our biggest debugging timesink.

Shadow DOM CSS Isolation: How to Embed a Widget Without Breaking the Host Page

Benji Darby — Mon, 13 Apr 2026 23:00:00 +0000

Shadow DOM is the only reliable way to prevent a third-party widget's CSS from colliding with a host page's styles. I learned this building IssueCapture — a bug reporting widget that runs on thousands of different host pages, each with its own CSS, fonts, z-index stacking contexts, and JavaScript globals. It cannot break those pages. It cannot be broken by them.

Here's the full setup, including the parts the docs skip.

Why Shadow DOM?

The naive approach to embedding a third-party widget is dumping your HTML into the host page's DOM and hoping for the best. This works until the host page has a CSS reset that flattens all your styles, or a * { box-sizing: content-box !important; } rule, or a global .modal { display: none; } that someone added in 2019 and nobody wants to touch.

Shadow DOM gives you a genuine encapsulation boundary. Styles from the host page cannot pierce it. Your styles cannot leak out of it. You get an isolated subtree with its own document fragment.

Here's the basic mounting pattern:

const container = document.createElement('div');
container.id = 'my-widget-root';
container.style.position = 'fixed';
container.style.zIndex = '999999';
container.style.top = '0';
container.style.left = '0';
container.style.width = '100vw';
container.style.height = '100vh';
container.style.pointerEvents = 'none'; // pass-through until open
document.body.appendChild(container);

const shadowRoot = container.attachShadow({ mode: 'open' });

The container is a fixed full-viewport div sitting on top of everything. pointerEvents: none means it's invisible to clicks when the widget is closed — the host page behaves normally. When the widget opens, you toggle that to auto.

Preact Over React

React adds about 130KB before you write a single component. That's a hard sell when you're injecting a script into someone else's production site. Every kilobyte you add is a kilobyte their users download.

Preact's core is around 3KB gzipped. It has the same API surface — hooks, context, refs, useEffect, all of it. The only things missing are some legacy React APIs nobody should be using in new code anyway.

IssueCapture's widget ships at around 40KB gzipped for the core UI. Screenshot capture is another 13KB, annotation is 107KB — both lazy-loaded only when the user actually requests them. That's the right tradeoff: pay the cost only when the feature is used.

Injecting Styles into Shadow DOM

This is where most people trip up. You cannot link external stylesheets into a shadow root. <link rel="stylesheet"> tags and @import rules do not work the way you expect inside a shadow DOM. The simplest reliable approach is constructing your CSS as a plain string and injecting it via a <style> element.

const appContainer = document.createElement('div');
appContainer.id = 'my-app';
shadowRoot.appendChild(appContainer);

const styleElement = document.createElement('style');
styleElement.textContent = `
  :host {
    all: initial;
    font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, sans-serif;
  }

  * {
    box-sizing: border-box;
    margin: 0;
    padding: 0;
  }

  #my-app {
    position: relative;
    width: 100%;
    height: 100%;
  }
`;
shadowRoot.appendChild(styleElement);

The :host selector targets the shadow host element. all: initial resets inherited CSS properties so the host page's font, color, and line-height don't bleed in through inheritance, which is one of the few ways the host page can still affect a shadow root.

With Preact, mounting into the shadow root looks identical to mounting into any other DOM node:

import { render } from 'preact';
import { MyWidget } from './MyWidget';

render(<MyWidget />, appContainer);

The Rough Edges

Why `document.activeElement` Lies Inside Shadow DOM

When your modal opens, keyboard focus should stay inside it. The problem is that document.activeElement reflects focus in the main document. When focus moves into your shadow root, document.activeElement points at the shadow host — not the specific element inside the shadow. To find which element inside your shadow has focus, you need shadowRoot.activeElement.

const previousActiveElement = document.activeElement;

const focusableSelectors = [
  'button:not([disabled])',
  'input:not([disabled])',
  'select:not([disabled])',
  'textarea:not([disabled])',
  'a[href]',
].join(', ');

document.addEventListener('keydown', (e) => {
  if (e.key === 'Escape') {
    closeModal();
    return;
  }

  if (e.key === 'Tab') {
    const elements = Array.from(
      modalRef.current.querySelectorAll(focusableSelectors)
    );
    const first = elements[0];
    const last = elements[elements.length - 1];

    if (e.shiftKey && document.activeElement === first) {
      e.preventDefault();
      last.focus();
    } else if (!e.shiftKey && document.activeElement === last) {
      e.preventDefault();
      first.focus();
    }
  }
});

previousActiveElement?.focus(); // restore on close

One subtlety: you attach the keydown listener to document, not to the shadow root. Keyboard events bubble out of shadow DOM into the main document, so this works.

Font Loading

Fonts declared in the host page's CSS are not available inside your shadow root by default. The safest approach: use system font stacks. If you need a specific font, load it at the document level by injecting a <link> tag into the host page's <head> — fonts loaded at the document level are accessible from within shadow roots.

if (!document.getElementById('my-widget-fonts')) {
  const link = document.createElement('link');
  link.id = 'my-widget-fonts';
  link.rel = 'stylesheet';
  link.href = 'https://fonts.googleapis.com/css2?family=Inter:wght@400;500;600&display=swap';
  document.head.appendChild(link);
}

Z-Index Stacking Contexts

Your widget's container sits at z-index: 999999. That sounds like it should win every fight. It often doesn't.

The browser doesn't compare z-index values globally — it compares them within the same stacking context. If a host page element creates a new stacking context (via transform, opacity, filter, will-change, etc.), your widget's container and that element are no longer in the same context.

There is no clean solution. The best you can do:

Attach your container directly to document.body so it's in the root stacking context
Use position: fixed on the container
Document clearly that if a host page uses transform on the <body> element, positioning behavior is undefined

Putting It Together

The full flow:

Append a fixed full-viewport container to document.body with pointerEvents: none
Attach a shadow root to that container
Inject all CSS as plain strings via <style> elements
Mount your Preact app into a <div> inside the shadow root
Manage open/close state by toggling pointerEvents
Handle focus trapping with a keydown listener on document
Accept that z-index is a political problem, not a technical one

The result is a widget that coexists cleanly with any host page. Host page CSS cannot touch your widget. Your widget CSS cannot touch the host page.

IssueCapture uses this architecture to run a bug-reporting modal on thousands of different sites. If you want to see the patterns in context, the widget is at issuecapture.com.

If you've found a clean workaround for the stacking context problem that doesn't require the host page to change their CSS, I'd genuinely like to hear it. I haven't found one.

Jira Issue Collector Alternatives in 2026: What to Use Now That It's Dead

Benji Darby — Thu, 09 Apr 2026 14:57:59 +0000

Atlassian's Issue Collector hasn't been updated in years. It doesn't work with team-managed projects, has no screenshot annotation, no error capture, and the documentation still references Firefox 28. If you've been relying on it to collect bug reports from your website, you've probably noticed it's falling apart.

Here's what actually works in 2026.

What was the Jira Issue Collector?

The Issue Collector was a widget Atlassian provided to embed a bug reporting form on your website. It opened an iframe with a Jira issue creation form. Users filled it out, hit submit, and a ticket appeared in your Jira project.

It was fine for its time, but it had serious limitations:

No screenshot tools — users couldn't capture or annotate what they were seeing
No error capture — no console logs, no network failures, no browser info
iframe-based — cross-origin restrictions meant the widget couldn't access page context
No team-managed project support — only worked with company-managed projects
No AI or automation — every ticket needed manual triage
Broken styling — the iframe often conflicted with host page CSS
No SPA support — didn't handle route changes in React, Angular, or Vue apps

Atlassian hasn't publicly deprecated it, but it's effectively abandoned. No updates, no fixes, no roadmap.

What to look for in a replacement

A modern bug reporting widget should:

Capture context automatically — console errors, network failures, browser info, page URL
Support screenshots — ideally with annotation (draw, crop, highlight)
Isolate from the host page — no CSS conflicts, no broken layouts
Work with team-managed projects — not just company-managed
Handle SPAs — proper lifecycle management for React, Angular, Vue, Next.js
Create detailed Jira tickets — not just a summary field and a description

The alternatives

1. IssueCapture

A drop-in JavaScript widget purpose-built as an Issue Collector replacement. One script tag, creates Jira tickets via OAuth 2.0.

What it does:

Screenshot capture with annotation (crop, draw, highlight)
Console errors captured automatically from page load
Network request monitoring (4xx/5xx failures)
Works with both Jira Software and JSM, including team-managed projects
AI triage, categorization, duplicate detection, sentiment analysis (optional)
Shadow DOM isolation — no CSS conflicts
16 languages
40KB gzipped core, screenshot and annotation lazy-loaded

Pricing: Free tier (10 issues/mo), Starter $29/mo, Team $59/mo (AI features), Business $99/mo

Best for: Teams that want a direct Issue Collector replacement with modern features. Closest thing to a drop-in swap.

Website: issuecapture.com

Disclosure: I built IssueCapture.

2. Marker.io

A visual bug reporting tool that integrates with Jira, Trello, Asana, and other project management tools. Focused on client feedback and QA workflows.

What it does:

Screenshot and screen recording
Annotation tools
Technical metadata capture
Integrates with multiple project management tools (not just Jira)
Guest reporting (no login required)

Pricing: Starts at $39/mo (Starter, 5 seats). Team plan $99/mo (15 seats). Company plan $199/mo (unlimited seats).

Best for: Agencies and teams that use multiple project management tools, not just Jira. Strong if you need client-facing feedback collection across different platforms.

Limitations: Per-seat pricing gets expensive for larger teams. Minimum $39/mo even for small teams.

3. Usersnap

A feedback and bug tracking platform with visual annotation. Used by larger enterprises for customer feedback, QA, and beta testing.

What it does:

Screenshot and screen recording
In-app surveys and feedback forms
Annotation tools
Integrates with Jira, Azure DevOps, and others
Session replay

Pricing: Starts at $39/mo (Startup plan). Business plan $99/mo. Enterprise pricing available.

Best for: Teams that want bug reporting combined with customer feedback surveys. More of a feedback platform than a pure bug reporter.

Limitations: Heavier than a simple bug widget. Can be overkill if you just want bug reports into Jira.

4. BugHerd

A visual feedback tool that pins comments directly on web pages. Originally designed for web agencies collecting client feedback.

What it does:

Point-and-click bug reporting on web pages
Visual pins on page elements
Screenshot capture
Jira integration
Guest access for clients

Pricing: Starts at $41/mo (Standard, 5 members). Premium $66/mo (25 members). Per-seat pricing.

Best for: Web agencies collecting visual feedback from clients during development. The pin-on-page approach works well for design and layout feedback.

Limitations: Per-seat pricing. Less suited for end-user bug reporting on production sites. Jira integration is secondary to their own task board.

5. Instabug

A mobile and web SDK for bug reporting, crash reporting, and user feedback. Originally focused on mobile apps.

What it does:

Bug reporting with screenshots
Crash reporting and performance monitoring
In-app surveys
Session replay
Integrates with Jira and other tools

Pricing: Starts at $249/mo (Growth plan). Enterprise pricing available. 14-day free trial.

Best for: Mobile app teams that also have a web presence. Strong crash reporting and performance monitoring.

Limitations: Expensive. Mobile-first — the web SDK is secondary. Overkill if you just need a Jira bug reporting widget.

6. Jam.dev

A browser extension for bug reporting. Users capture bugs via the extension, and tickets are created in Jira or other tools.

What it does:

Browser extension captures page state
Auto-captures console logs, network requests
Screen recording
Integrates with Jira, Linear, and others

Pricing: Free plan available. Pro starts at $5/user/month.

Best for: Internal teams where everyone can install a browser extension. Good for developer-to-developer bug reporting.

Limitations: Requires extension installation — not suitable for external users or customers reporting bugs. Per-user pricing.

7. Build your own with the Jira REST API

If you don't want a third-party widget, you can create issues directly via the Jira REST API.

POST /rest/api/3/issue

What you get:

Full control over the UI and UX
No third-party dependencies
Direct OAuth 2.0 or API token authentication

What you have to build yourself:

The entire bug reporting UI
Screenshot capture and annotation
Console error and network monitoring
File upload handling
Error handling and retry logic
Multi-project support

Best for: Teams with specific UI requirements that no off-the-shelf widget can meet, and the engineering bandwidth to build and maintain it.

Quick comparison

Feature	IssueCapture	Marker.io	Usersnap	BugHerd	Instabug	Jam.dev
Screenshot annotation	Yes	Yes	Yes	Yes	Yes	Yes
Console error capture	Auto from page load	Limited	No	No	Yes	Yes
Network monitoring	Yes	No	No	No	Yes	Yes
AI triage	Yes	No	No	No	No	No
Team-managed projects	Yes	Yes	Yes	Yes	Yes	Yes
Shadow DOM isolation	Yes	No	No	No	N/A	N/A
Per-seat pricing	No	Yes	Yes	Yes	Yes	Yes
Starting price	Free	$39/mo	$39/mo	$41/mo	$249/mo	Free
JSM support	Yes	Limited	Limited	No	Limited	No

Which one should you pick?

Replacing Issue Collector with minimum fuss: IssueCapture — closest to a drop-in replacement, works with team-managed projects, no per-seat pricing
Agency collecting client feedback: Marker.io or BugHerd — built for that workflow
Enterprise feedback platform: Usersnap — surveys, feedback, and bug reporting combined
Mobile + web: Instabug — if you need crash reporting and performance monitoring too
Internal dev team only: Jam.dev — browser extension is fine when you control the users
Maximum control: Jira REST API — if you have the bandwidth to build and maintain it

The Issue Collector had a good run. These tools are all better.

I replaced Atlassian's Issue Collector with a modern alternative — here's what I built

Benji Darby — Thu, 09 Apr 2026 13:42:30 +0000

Atlassian's Issue Collector hasn't been meaningfully updated since 2014. No screenshot tools, no AI, it doesn't work with team-managed projects, and the docs still reference Firefox 28. If you've ever tried to set it up on a modern stack, you know the pain.

I spent months building a replacement. IssueCapture is a drop-in JavaScript widget that lets website visitors report bugs directly into Jira — with screenshots, console errors, and network data included automatically.

The problem

Bug reports from end users are usually terrible. "It doesn't work" with no context, no steps to reproduce, no browser info. Developers waste hours going back and forth trying to understand what actually happened.

Atlassian's answer to this was the Issue Collector — a widget you embed on your site. But it's been abandoned. No screenshot annotation, no error capture, no AI, no modern framework support. And if your Jira project is team-managed? You can't use it at all.

What I built

One script tag, five minutes to set up:

<script type="module">
  import IssueCapture from 'https://issuecapture.com/widget.js';
  IssueCapture.init({ apiKey: 'your-api-key' });
</script>

The widget gives users a floating button. They click it, describe the bug, and the ticket lands in Jira with full context:

Screenshot + annotation — capture, crop, draw, highlight. Lazy-loaded so it's only +13KB if they actually use it.
Console errors — captured automatically from page load, not just after the widget opens.
Network failures — 4xx/5xx responses caught automatically.
Browser info — URL, user agent, viewport size.

Technical decisions

Shadow DOM isolation. The widget runs inside a Shadow DOM so it can't conflict with the host page's CSS. All styles are plain CSS strings injected into the shadow root — no external stylesheets, no Tailwind, nothing that could leak.

Preact over React. The core widget is ~40KB gzipped. Screenshot capture adds 13KB, annotation adds 107KB — both lazy-loaded only when the user needs them. Keeping it small matters when you're injecting into someone else's site.

Console capture from page load. Most bug reporters only capture errors that happen after the widget opens. That misses the errors that actually caused the problem. IssueCapture hooks into console.error and monitors network requests from the moment the page loads, then includes relevant ones in the report if the dashboard admin has enabled it.

AI is optional. Triage, categorization, duplicate detection, and sentiment analysis run through a queue processor on Gemini 2.5 Flash with an OpenAI fallback. Duplicate matching uses text-embedding-004 + pgvector. But the widget works perfectly fine without any of it — AI features only kick in on paid tiers.

Stack

Widget: Preact + TypeScript + Vite
Dashboard: Next.js 16 (App Router) + Tailwind
Backend: Vercel Serverless Functions + Supabase (PostgreSQL + RLS)
AI: Google Gemini (primary) + OpenAI (fallback)
Jira integration: OAuth 2.0 (no API tokens or passwords)

Supabase handles multi-tenancy through Row Level Security — every query is scoped to the account. pgvector powers the duplicate detection embeddings. Edge Functions serve the widget config so it loads fast.

16 languages supported with lazy-loaded locale files so you only download the one you need.

What I learned

Bug report quality is the real product. The AI features are nice, but the biggest impact is just capturing console errors and network failures automatically. Developers told me that alone cut their "can you send me more details?" messages in half.

Widget size is a feature. Every KB matters when you're asking someone to add your script to their production site. Lazy-loading the heavy parts (screenshot, annotation) was the right call — most bug reports don't include screenshots.

Shadow DOM has rough edges. Focus trapping, font loading, and z-index stacking all behave differently inside a shadow root. If you're building an embeddable widget, budget time for this.

Try it

There's a demo on the homepage: issuecapture.com

Free tier is 10 issues/month, no credit card required. Paid plans start at $29/mo with no per-seat pricing.

If you're on a team that uses Jira and you're tired of garbage bug reports, give it a shot. Happy to answer questions in the comments.

DEV Community: Benji Darby

Surviving Vercel's Free Tier: 12 Serverless Functions, Zero Waste

Why the Limit Bites You

Pattern 1: Action-Based Routing

Pattern 2: The _lib/ Directory

Pattern 3: .vercelignore for Dev-Only Endpoints

How we organize the client side

The trade-offs

The math

What to Include in a Bug Report: Console Errors, Network Logs, and Why Templates Aren't Enough

Why most bug reports fail

What a good bug report actually contains

Why templates don't work

The tooling approach

The checklist

Privacy matters

Dynamic Import in Production: How We Kept a Bug Reporting Widget Under 40KB

The problem with eager imports

Dynamic import basics

How we structured it

Loading states matter

Preload hints for the likely path

Measuring the actual impact

When lazy-loading is not the answer

How to Capture Console Errors and Network Requests in JavaScript

Intercepting console.error

Catching uncaught errors and promise rejections

Intercepting network requests

fetch

XMLHttpRequest

Privacy considerations

Sanitize URLs

Exclude sensitive domains

Filter by path pattern

Capture early, filter late

A few things to watch for

Row-Level Security in Supabase: Multi-Tenant SaaS from Day One

What RLS Actually Does

The team_members Join Pattern

The service_role Key Bypasses All RLS Policies

Policies on JOINed Tables

Performance: The Subquery Problem

Testing RLS Policies

Why RLS Will Hurt You (and Why You Should Still Use It)

Shadow DOM CSS Isolation: How to Embed a Widget Without Breaking the Host Page

Why Shadow DOM?

Preact Over React

Injecting Styles into Shadow DOM

The Rough Edges

Why document.activeElement Lies Inside Shadow DOM

Font Loading

Z-Index Stacking Contexts

Putting It Together

Jira Issue Collector Alternatives in 2026: What to Use Now That It's Dead

What was the Jira Issue Collector?

What to look for in a replacement

The alternatives

1. IssueCapture

2. Marker.io

3. Usersnap

4. BugHerd

5. Instabug

6. Jam.dev

7. Build your own with the Jira REST API

Quick comparison

Which one should you pick?

I replaced Atlassian's Issue Collector with a modern alternative — here's what I built

The problem

What I built

Technical decisions

Stack

What I learned

Try it

Pattern 2: The `_lib/` Directory

Pattern 3: `.vercelignore` for Dev-Only Endpoints

The `service_role` Key Bypasses All RLS Policies

Why `document.activeElement` Lies Inside Shadow DOM