How to Integrate Bolt.new with UserTesting

UserTesting requires a publicly accessible URL that panel testers can visit without creating accounts or knowing your internal systems. Before setting up a UserTesting study, deploy your Bolt app to a production hosting environment. Bolt Cloud is the simplest option: click 'Publish' in the top-right corner of the Bolt editor. Your app deploys to a .bolt.host URL with SSL automatically. You can also connect a custom domain in Bolt's Settings. Netlify is the alternative: go to Settings → Applications → Netlify → Connect, then click Publish. Both give you a stable HTTPS URL you can share with UserTesting. For UserTesting sessions, consider whether you want testers to use real functionality or a demo mode. Real functionality requires testers to create accounts, which adds friction and can fail if your auth flow is confusing. A demo mode with pre-filled data and a guest login is often better for testing UI flows. Create a demo user account in your Supabase Auth with a simple password and include the credentials in your UserTesting task instructions. Verify your deployed app is ready for external users: check that all pages load without errors, navigation links work, mobile responsive layout functions correctly, and error messages are user-friendly. UserTesting session recordings that surface technical error messages ('MongooseServerSelectionError') rather than helpful UI messages create noise in your research. Invest 30 minutes testing your own deployment before sending it to UserTesting panelists. Note: Bolt's WebContainer preview URL (the development URL inside Bolt's editor) is not suitable for UserTesting. The preview URL is session-specific, requires Bolt login context, and will not load reliably for external testers. Always use your deployed URL.

1// app/api/demo/reset/route.ts
2import { NextResponse } from 'next/server';
3import { createClient } from '@supabase/supabase-js';
4
5const supabase = createClient(
6  process.env.NEXT_PUBLIC_SUPABASE_URL!,
7  process.env.SUPABASE_SERVICE_ROLE_KEY! // service role to bypass RLS
8);
9
10const DEMO_USER_ID = process.env.DEMO_USER_ID!;
11
12export async function POST() {
13  try {
14    // Delete all demo user's created items
15    await supabase
16      .from('user_projects')
17      .delete()
18      .eq('user_id', DEMO_USER_ID);
19
20    // Reset demo user profile to defaults
21    await supabase
22      .from('profiles')
23      .update({ onboarding_complete: false, settings: {} })
24      .eq('id', DEMO_USER_ID);
25
26    return NextResponse.json({ success: true, message: 'Demo reset complete' });
27  } catch (error: unknown) {
28    const e = error as { message: string };
29    return NextResponse.json({ error: e.message }, { status: 500 });
30  }
31}

While UserTesting provides scheduled deep-dive sessions, continuous in-app feedback collection fills the gaps between research rounds. A Net Promoter Score (NPS) survey is the most efficient single-question feedback mechanism: asking users 'How likely are you to recommend this to a friend?' on a 0-10 scale takes 30 seconds and gives you actionable segmentation data (Detractors 0-6, Passives 7-8, Promoters 9-10). The best time to show an NPS survey is after a user experiences enough of your product to have an informed opinion — typically after 3-5 active sessions, after completing onboarding, or after reaching a key value moment (their first successful export, first project shared, first successful API call). Showing it too early (first visit) collects meaningless data. Display the NPS survey as a modal or slide-up panel to avoid disrupting the current workflow. Use localStorage to ensure it only shows once per user — checking both localStorage and your database prevents it from reappearing after a user clears browser storage. Store responses in Supabase with the user ID, score, comment, app version, and the page/feature they were using when the survey appeared. Review NPS responses weekly in your Supabase dashboard. Create a simple Supabase query: SELECT score, comment, created_at FROM nps_responses ORDER BY created_at DESC LIMIT 50. For qualitative analysis, sort by score and read the comments in each segment — Detractor comments (0-6) tell you what to fix, Promoter comments (9-10) tell you what to amplify in your marketing.

1// app/api/nps/route.ts
2import { NextResponse } from 'next/server';
3import { createRouteHandlerClient } from '@supabase/auth-helpers-nextjs';
4import { cookies } from 'next/headers';
5
6export async function POST(request: Request) {
7  const supabase = createRouteHandlerClient({ cookies });
8  const { data: { user } } = await supabase.auth.getUser();
9
10  if (!user) {
11    return NextResponse.json({ error: 'Unauthorized' }, { status: 401 });
12  }
13
14  const body = await request.json() as { score: number; comment?: string; page_url?: string };
15
16  if (typeof body.score !== 'number' || body.score < 0 || body.score > 10) {
17    return NextResponse.json({ error: 'Score must be 0-10' }, { status: 400 });
18  }
19
20  const { error } = await supabase.from('nps_responses').insert({
21    user_id: user.id,
22    score: body.score,
23    comment: body.comment ?? null,
24    page_url: body.page_url ?? '',
25  });
26
27  if (error) {
28    return NextResponse.json({ error: error.message }, { status: 500 });
29  }
30
31  return NextResponse.json({ success: true });
32}

UserTesting sessions give deep qualitative insight but require users to be available for a scheduled session. A contextual feedback widget that appears after specific user actions captures feedback in the moment — when the user's experience is freshest and most accurate. The most effective contextual feedback trigger points: after an error (the user just hit a bug — ask immediately what they were trying to do), after completing a complex flow (onboarding, checkout, project setup), after the user has been idle for 5+ minutes on a page (they may be stuck), or as an exit intent overlay when the user moves to close the tab. For a simple implementation, create a floating feedback button (a question mark icon in the bottom-right corner) that users can click any time to leave feedback. This respects user autonomy better than popup surveys and consistently captures feedback from the most engaged users — people who are frustrated enough or impressed enough to proactively report their experience. Store feedback with context: the page URL, user ID, timestamp, app version (from environment variables), and the user's session duration. This context transforms raw feedback into actionable insights. 'The export button doesn't work' is useful; 'The export button doesn't work on the /projects/[id]/settings page, reported by a Pro plan user after 18 minutes in the session' is a bug report your engineering team can act on immediately. Note: Bolt's WebContainer cannot receive incoming webhooks, but this feedback form submits to a Next.js API route — an outbound POST that works in both the preview and after deployment.

1// components/FeedbackWidget.tsx (simplified structure)
2'use client';
3
4import { useState } from 'react';
5
6type Sentiment = 'happy' | 'neutral' | 'frustrated';
7
8export function FeedbackWidget() {
9  const [open, setOpen] = useState(false);
10  const [message, setMessage] = useState('');
11  const [sentiment, setSentiment] = useState<Sentiment>('neutral');
12  const [submitted, setSubmitted] = useState(false);
13
14  const submit = async () => {
15    await fetch('/api/feedback', {
16      method: 'POST',
17      headers: { 'Content-Type': 'application/json' },
18      body: JSON.stringify({
19        message,
20        sentiment,
21        page_url: window.location.href,
22      }),
23    });
24    setSubmitted(true);
25    setTimeout(() => {
26      setOpen(false);
27      setSubmitted(false);
28      setMessage('');
29    }, 2000);
30  };
31
32  return (
33    <div style={{ position: 'fixed', bottom: 24, right: 24, zIndex: 1000 }}>
34      {!open && (
35        <button
36          onClick={() => setOpen(true)}
37          style={{ borderRadius: '50%', width: 48, height: 48 }}
38          aria-label="Give feedback"
39        >
40          ��
41        </button>
42      )}
43      {open && (
44        <div style={{ background: 'white', border: '1px solid #e2e8f0', borderRadius: 12, padding: 16, width: 300 }}>
45          {submitted ? (
46            <p>Thank you for your feedback!</p>
47          ) : (
48            <>
49              <textarea
50                value={message}
51                onChange={(e) => setMessage(e.target.value)}
52                placeholder="What's on your mind?"
53                rows={4}
54                style={{ width: '100%', marginBottom: 8 }}
55              />
56              <div style={{ display: 'flex', gap: 8, marginBottom: 12 }}>
57                {(['happy', 'neutral', 'frustrated'] as Sentiment[]).map((s) => (
58                  <button key={s} onClick={() => setSentiment(s)}
59                    style={{ fontWeight: sentiment === s ? 'bold' : 'normal' }}>
60                    {s === 'happy' ? '😊' : s === 'neutral' ? '😐' : '😤'}
61                  </button>
62                ))}
63              </div>
64              <button onClick={submit} disabled={!message.trim()}>Send</button>
65              <button onClick={() => setOpen(false)} style={{ marginLeft: 8 }}>Cancel</button>
66            </>
67          )}
68        </div>
69      )}
70    </div>
71  );
72}

For Bolt developers who want automated session observation without UserTesting's scheduling overhead and per-session costs, FullStory provides the closest equivalent: actual video recordings of user sessions captured automatically in production. Where UserTesting shows you 5-10 recruited users completing prescribed tasks, FullStory shows you thousands of real sessions from actual users doing actual things. The trade-off: UserTesting provides narration (users verbalize what they're thinking), which reveals user mental models and confusion points that silent session replay cannot surface. FullStory shows you what users do; UserTesting shows you why. For a complete UX research program, both are valuable. For early-stage Bolt apps on a budget, FullStory's automatic capture often reveals the same usability issues as UserTesting studies. Adding FullStory to your Bolt app requires the @fullstory/browser npm package and your FullStory Org ID. Install the package, initialize with your org ID in the app entry point, and FullStory begins recording all sessions automatically. The FullStory dashboard provides session search (find sessions where users rage-clicked, hit errors, or spent more than 5 minutes on a specific page) and DX Data (ML-powered frustration signal detection) that mimics some of UserTesting's insight-generation without manual session scheduling. Note: FullStory's browser SDK sends data directly from the user's browser to FullStory's servers over HTTPS, so it works in Bolt's WebContainer during development for initialization testing. Full session recording activates on your deployed production URL.

1// lib/fullstory.ts
2import * as FullStory from '@fullstory/browser';
3
4let initialized = false;
5
6export function initFullStory(orgId: string) {
7  if (initialized || !orgId) return;
8  FullStory.init({
9    orgId,
10    devMode: import.meta.env.DEV,
11  });
12  initialized = true;
13}
14
15export function identifyUser(userId: string, email: string, plan = 'free') {
16  if (!initialized) return;
17  FullStory.identify(userId, {
18    displayName: email,
19    email,
20    plan,
21  });
22}
23
24export function anonymizeUser() {
25  if (!initialized) return;
26  FullStory.anonymize();
27}
28
29// In App.tsx:
30// useEffect(() => {
31//   initFullStory(import.meta.env.VITE_FULLSTORY_ORG_ID);
32// }, []);