DEV Community: Jam.dev

Recording Links: The Nitty Gritty Details Behind Today's Launch

Aidan Nulman — Wed, 04 Jun 2025 19:19:37 +0000

Earlier today we announced Recording Links, the easiest way for Product teams to capture screen recordings, repro steps, and user feedback directly inside their app, without requiring a Chrome extension or install.

To do so, we had to:

Design a simple + attractive recorder UX you’d happily send to your users
Make sure it works reliably and in every major browser vendor
Keep the install process as simple as it can be, and no simpler

As one of the authors on this project I’m clearly biased, but I think the solution we’ve shipped is just shy of magic. And although magicians never reveal their secrets, I write software and have been asked to cook for a minute about our work. So I’ll just tell you: we did it all with <iframe>s.

But before we go too deep: try Recording Links yourself, or check out this demo Ian recorded!

Prior Art

Recording Links builds on Jam’s core extension and more-recent Jam for Customer Support (Intercom) products. Both of these are built on Jam’s core object model and capture stack, which allow us to deliver a consistent debugging experience in our own app and the others we integrate with.

While each of our products have somewhat different feature sets, Jam’s customers expect a few core promises from our products:

Users can easily start, stop, restart, and submit recordings
Events must be captured between start of recording and end of recording
We can’t lose data along the way, lest our users (or worse, yours!) lose trust in us

Fulfilling these promises in the extension can sometimes be a challenge. But, since users’ data is local, it’s at least reasonably straightforward to fulfill our promises.

This was comparatively difficult in our Intercom product. Specifically, that product sends users to a Recorder hosted at recorder.jam.dev, which—due to browser security constraints—uses a websocket to communicate with event capture scripts installed on our users’ sites.

The websocket approach works fine enough, but has room for improvement:

If our socket server is unavailable—e.g. briefly during deploys, or a user is recording while offline—created Jams may be corrupted or missing data; there is no way for the recorder script to recognize this state and inform the user.
Common Internet chaos—e.g. slow connections, out-of-order packets, unexpected user and/or script interactions—requires mitigation, thereby increasing code complexity and ongoing maintenance
It literally doesn’t work in Safari—and may someday not work in other browsers—because it relies on third-party cookies to establish a shared identifier

One of our design goals for Recording Links was to remove this network dependency altogether. The only time we expect to hear from your users is when they’re explicitly submitting a Jam.

State Partitioning

This lofty design goal introduces a classic problem: “how do we communicate between tabs locally?”. Most browser primitives (e.g. localStorage, BroadcastChannels…) are restricted to same-origin communication. Only Safari is so strict (Chrome and Firefox restrict to same-domain), but since same-origin is our lowest-common denominator let’s stick with it.

Our earlier architecture—a Jam-hosted recorder.jam.dev URL—can’t communicate directly with scripts on pages you host, because it’s a different origin. But what if we put an <iframe> on your pages from the same-origin as our recorder? Well, that’s not so simple. Here are @kentcdodds and @ryanflorence discussing the issue in Oct 2023:

All browsers use a technique called “State Partitioning” to prevent cross-site tracking. What this means practically is that recorder.jam.dev frames embedded on example.com belong to a “state partition” keyed by the top-frame’s origin (i.e. example.com:recorder.jam.dev), whereas our top frame is in the top-level partition (i.e. recorder.jam.dev).

We started by exploring how to bring your origin to our contents, e.g. by asking installers to set up a recorder.example.com subdomain and point it to our content. But since Safari is strictly same-origin, we cannot assume that recorder.example.com can natively communicate with example.com. In fact, doing so would fail our expectation of supporting all major browser vendors.

Our next idea was to bring our contents to your origin, by embedding both the Capture and the Recorder scripts onto your pages via iframe. This way, both capture.js and recorder.js scripts would live in the example.com:recorder.jam.dev partition, and could communicate to each other!

The rest of the work was not easy—try building an app that works equally well in embedded vs. non-embedded states, or reliably streaming video content across an iframe boundary in all major desktop browsers—but it was mostly app work, on top of infrastructure we could trust.

Managed Embeds

Having determined our architecture requirements, we also prioritized figuring out exactly how we would distribute our iframes. We had previously considered a few other mechanisms—the CNAME approach of course, and a “proxy recorder” where embedders’ servers fetched and served our content directly—but there were only two meaningful mechanisms in our iframe bucket:

DIRECT EMBED—where embedders directly embed an iframe with a URL we provide:

<html>
  <head>
    <title>Recorder Page</title>
    <!-- YOUR PAGE'S `<head>` -->
  </head>

  <body>
    <iframe src="https://recorder.jam.dev/recorder/PASS-THE-ID"
      sandbox="allow-scripts allow-same-origin allow-popups">
    </iframe>
  </body>
</html>

MANAGED EMBED—where embedders use a script we provide to mount our iframe:

<html>
  <head>
    <!-- on all capture-able pages -->
    <script type="module" src="https://js.jam.dev/capture.js"></script>

    <!-- at least on recorder pages -->
    <script type="module" src="https://js.jam.dev/recorder.js"></script>
  </head>
</html>

We also wanted to make sure that Jams recorded on your pages only get sent to you—you don’t want someone from evil.com to spoof an example.com Recording Link and steal the privileged network and console logs from an unsuspecting user.

To achieve this, we needed to design a domain verification strategy. We considered three options:

Over DNS—configure a TEXT record with a value we expect

Over HTTP—return a response we expect from a configured endpoint

const express = require('express');
const app = express();

app.get("/PROVIDED-URL", (_req, res) => res.send("PROVIDED-BODY"));

In HTML—attest the teams you allow wherever you load the recorder script

<html>
  <head>
      <script type="text/javascript" src="https://js.jam.dev/recorder.js"></script>
    <meta name="jam:team" content="TEAM-ID-COPIED-FROM-SETTINGS" />
    <meta name="jam:team" content="ANOTHER-TEAM-ID-FROM-SETTINGS" />

    <!-- more head content -->
  </head>

  <body>
    <!-- body content -->
  </body>
</html>

Consider the above options with regards to three criteria we’d set out while spec’ing the work:

Prefer copy/paste-able solutions vs. ones that require config

Prefer solutions implementable by lower-authority personnel

Prefer solutions that look familiar and obvious vs. strange and opaque

Managed Embeds w/ In-HTTP Domain Verification is just… cleaner. There’s only one line that requires config, and we don’t have to ask users to update their site code should we need different iframe attributes, for example. Additionally, neither of these require the implementer have permission to edit DNS settings. And everyone recognizes script embeds and meta tags!

As with above, the rest of the work was not easy—coordinating state across multiple frame boundaries is challenging!—but we thought it much more convenient for users and maintainable for us to own this complexity. I’m still impressed we managed to pack such a powerful product into three lines of HTML!

What's Next?

We have ambitious plans for Recording Links: new ways to create them, new ways to consume them, new ways to make them even easier to use. Today, we celebrate how far we’ve come; Recording Links has surpassed many of our expectations internally, and we hope it delivers you not just the value but the wows we’ve been experiencing.

Have you tried Recording Links yet? If not, what are you waiting for? It’s only 3 lines of HTML to get started; I’d order you a coffee while you work, but let’s be real—if you made it this far, by the time the coffee was ready you’d already be done.

Introducing The Valentines Day Debugger – AI debugging hints for your relationship problems

Dani Grant — Fri, 14 Feb 2025 20:19:55 +0000

// Detect dark theme var iframe = document.getElementById('tweet-1890423272875196896-601'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1890423272875196896&theme=dark" }

Now you can capture all the debug details of your relationship problems. Diagnose & fix issues faster, complete with AI hints!

Software engineers are telling us this is saving hours of their time.

Let us give you a tour!

1-click send to friend chat

Instant replay for critical moments

AI helpfully offers suggestions

We're just kidding, but we hope this made you smile! Happy Valentine's Day from your friends at Jam.dev 💜

We built an AI bug reporter with Gemini 2.0

Dani Grant — Thu, 06 Feb 2025 16:04:49 +0000

It’s insane that bug reporting is still done by hand. People are terrible at writing bug reports. That’s how you end up with hours of back-and-forth for a 5 min fix. "What browser?" “Is it still happening?”

But this is a problem you can fix with tools. Humans are inherently error-prone when it comes to reporting bugs, but computers aren’t. Imagine a tool that plugs into devtools and grabs: session recording + network logs + error traces + AI that writes a summary and repro steps.

A few years ago, we built a tool that captures all the information you’d get in a HAR file plus screen recording and packages it into a link for engineers. (Like a screen recorder plus DevTools). It’s called jam.dev and people use it to capture more than half a million bugs each month now (which we are really excited about!)

Today we added an AI inside that analyzes all of the session data and errors/traces in the console and network logs and writes a concise description of the bug and lists out the exact repro steps, complete with timestamps mapped to the screen recording. It’s built with Gemini 2.0 which we used while in experimental mode. We chose Gemini because of Gemini’s native ability to process videos (which other LLMs don’t have).

I’d love for you to try it out and let me know your thoughts. My email is dani@jam.dev and I hope to hear from you.

Try it: jam.dev/ai

Demo: https://x.com/jamdotdev/status/1887523689518014891

I think people are going to have a large role in testing software for a long time (as long as humans are the users, humans need to be testers too), but what doesn’t need to be manually done is collecting debug information and writing it up into a ticket. Like Kasparov and Deep Blue, the strongest collab is human + computer paired together –– humans to their strengths, computers to theirs.

By the way, we’re hiring engineers and working on building AI for debugging, de-duplication and auto-resolution and if these are problems that excite you, we’d love to chat: jam.dev/careers

9 lessons we learned building Jam in 2024

Dani Grant — Thu, 02 Jan 2025 17:36:55 +0000

Thank you for being a part of Jam this year! We crossed 6 million Jams, 170k users, shipped 31 new features and an entirely new Jam for your helpdesk, saved engineers 50+ years of debugging time (!) and got to meet 2,000 of you at a Jam meetup.

Everyone who Jams is a builder trying to make some corner of the world better through software. Y'all are awesome.

So, we wanted to end the year by sharing with you — builder to builder — 9 lessons we learned at Jam this year. And if you feel inspired, I'd love for you to let me know a lesson you learned building your product.

1. Small teams, high ownership

This year we grew from 11 to 20 people, and split from one team into specialized pods. And… small teams with true ownership run faster and do more than I ever thought possible.

2. Quality requires engineering discipline

It's a practice you have to keep. You don't just work on performance "this quarter". It's a mindset and a practice you stick to every day.

3. Getting over our process allergy

When you're small, it's important to be allergic to process. But as you grow, a bit of process is needed so you can do more things than anyone can keep in their head. This year we added just a few templates, checklists and weekly reviews. At first I was resistant, but now can't imagine how else we could manage so many parallel projects going on at any given time.

4 Treat everything as user experience

Even if it's an email, it's still a user experience. It takes longer to craft everything when you think like that. But, you end up shipping things that you're excited for users to experience! And that's super fun.

5. Great dev teams do the boring things well

Investing in the boring things unlocks you to move on to new problems. Docs, testing, deployment, infra. It's really boring to upgrade your servers, but all that investment means we get to go even faster now ("and sleep better" says the currently on-call engineer).

6. 1 + 1 designers = 3 designers

I used to worry that adding a second designer would slow us down, because instead of one person having all the context, they would need to coordinate. But actually, when we grew the design team, we were able to do even more because they had thought partners to think through our hardest design challenges. That was really cool to see.

7. The simple version is better

When in doubt, ship the simplest thing. The live Jam product today started as an internal project called "Simple Jam". The live Jam pricing started as an internal project called "Simple pricing". The simplest version is simply better.

8. Hire people who awe you

Hire people who love what they do. Hire people who care so darn much, you can't help but smile when they share. The joy of building things happens in moments, day to day, week to week. The people you get to build with are everything.

9. Time moves really fast in a startup

A lot of things change in a year. Things grow up quickly. Cherish the moments :)

Now, onto 2025! Excited to continue the Jam journey with all of you. Thanks for being a part of it. Happy new year!

💜, the Jam team:

Startup Lessons We Learned in 2024

Ivanha Paz — Fri, 27 Dec 2024 13:27:44 +0000

Our startup is changing! This year we went from 11 to 20 people, launched a new product (+30 features!), and learned a lot along the way. So we recorded our biggest lessons of the year. We’re excited to share them with you all, hope you enjoy!

What we learned:

0:21 Irtefa, co-founder
1:29 Chris, designer
4:50 Cyrus, engineer
6:54 Tomasz, engineer
7:48 Aidan, engineer
10:05 Ivanha, marketer
11:32 Ian, creator
13:20 Rui, engineer
15:10 Oskar, engineer
16:21 Dani, co-founder

P.S. If you’d like to share what you learned building your product, drop it in the comments, we’d love to know.

Subscribe to Building Jam on YouTube, Spotify, and Apple Podcasts. New episodes drop every Friday at 10AM ET. See you there!

How We Rebuilt Our Extension for Manifest V3

Ivanha Paz — Sun, 01 Dec 2024 20:12:09 +0000

Every week we share the story behind building our startup, Jam. This week, Jam eng, Aidan shares how we handled migration to MV3! Dig into all the technical details with us, and the challenges of doing a complete refactor of our browser extension + rolling it out to 150k users.

We discuss:

0:40 The biggest challenge of the MV3 refactor
4:03 How MV3 changed our product roadmap
4:50 Why getting Jam’s idle states for version updates was harder in MV3
9:56 The capture eng team & the support flows they took over
11:19 Balancing the scope & urgency of MV3 w/ building new features our users want
12:46 Now that we’re on MV3 - what’s next for capture?
17:06 Come work w/ us! New open role for Technical Support & QA!

See Support/QA + more open roles at Jam careers.

Our ex-cloudflare team built a tool that extracts debug data from screen recordings

Dani Grant — Mon, 25 Nov 2024 18:07:26 +0000

Hey DEV Community! 4 years ago, an ex-Cloudflare team and I started building a product — trying to make bug reporting a lot less painful.

Our tool is called Jam and it makes it pretty much impossible to create vague bug reports (like I used to when I was a PM). It's really hard as a non-engineer to send useful debug info!

If you care a lot, you'll take the time to include a screenshot or a screen recording of the bug. But, sometimes the important info is what's right outside the boundaries of the screenshot – or the developer needs to know what happened right before the video? Or needs to know some info like what account you're logged in with, and if there are any errors in the console, and you can't tell that from a screenshot or video.

Debugging is the worst part of engineering - but it's not actually because of the fixing, it's all the back and forth required to reproduce & get to the debugging! This context gap should be filled by tools.

Our goal was to make it really easy for people to log bugs in a format that gives developers all the context they need, right there in the bug report.

We tried 7 different versions of Jam to solve this problem, until we landed on what it is today - a browser extension you click when you want to catch a bug.

It's basically a screen recorder, except Jam auto-captures:

console logs
network requests
repro steps
session & user details
device & OS
backend logs

There's some extra debug tooling in there for websockets and graphql too (we love/hate graphql, but that's besides the point.)

You can see an example of what the captured data looks like here: https://jam.dev/c/96149346-3cb1-439a-b4d0-fed8181ea036

2 years into this version of Jam, our tool is used by over 150,000 people to fix more than 5 million bugs! That's really awesome, but there's so much more to do.

We really want to build something that makes this part of the job suck less. So, I wanted to open up for discussion here and get your feedback.

Jam is free to use forever (we've got a paid plan for companies who need it, but we will always keep a large free plan - after all, we learned to build products at Cloudflare).

I hope you'll check it out and let us know what you think: https://jam.dev

My email is dani@jam.dev, feel free to reach out anytime.

By the way, we're hiring engineers and if making debugging a lot more efficient is a problem that excites you, we'd love to chat: jam.dev/careers

Our Startup Loves These AI Tools (we recorded a 14 min podcast ep. about why).

Ivanha Paz — Fri, 08 Nov 2024 17:09:12 +0000

We’re so excited about AI - not just the AI features we’re building for Jam (can’t wait to show y'all!) but all the great tooling that helps us move faster at our startup. So, today we’re sharing the 13 AI tools we actually use — almost every day — how we use them, and why we love them.

Timestamps:

(00:07) Gemini & OpenAI
(01:02) GLIF
(03:32) GitHub Copilot
(04:33) Promptfoo
(05:20) Wondercraft & Descript
(07:17) OpusClip
(08:51) Grain
(09:51) ChatPRD
(10:34) Perplexity
(11:28) Claude
(11:46) ChatGPT

Episode links:

This Week in JS: https://thisweekinjavascript.com/
Gemini: https://ai.google.dev/
OpenAI: https://openai.com/api/
GitHub Copilot: https://github.com/features/copilot
Promptfoo: https://www.promptfoo.dev/
OpusClip: https://www.opus.pro/
Grain: https://grain.com/
ChatPRD: https://www.chatprd.ai/
Perplexity: https://www.perplexity.ai/
ChatGPT: https://chat.openai.com/
Claude: https://claude.ai/

Subscribe to Building Jam on YouTube, Spotify, and Apple Podcasts.

New episodes drop every Friday at 10AM ET. See you there!

We made a horror movie inspired by spooky prod bugs 🎃

Ivanha Paz — Thu, 31 Oct 2024 17:52:39 +0000

Dim the lights & grab your debugging buddy - it's a Jam Halloween video! 🍿

It’s an extra special Halloween because today we crossed 5 million Jams created! 🤯

So, we made y'all this video based on a real scary movie. Inspired by the spookiest thing out there – real software bugs in production.

Hope you 🎃 it

Happy Halloween! And cheers to 5 million bugs caught with Jam!! We can’t believe it!

New eng ep. on Building Jam! How we're building AI features 🎧

Ivanha Paz — Sat, 05 Oct 2024 01:25:51 +0000

We’re getting ready to ship 3 new AI features! So, today, 2 engineers leading AI development at Jam, Tomasz and Oskar, join the podcast to give us an update.

They did a demo at standup and wow - the future of AI debugging is 🌟

We're so excited for you all to use Jam AI. And to share how we’re making it, how it’s going, and the tools we’re using. Hope you enjoy listening!

We discuss:

The tools we’re using to build Jam AI
Tomasz shares the challenges of non-deterministic software
Jam’s process to build AI: data, validation & a lot of dogfooding
Irtefa’s message to Jam users waiting for more AI features
How we evaluate our prompts
Unexpected LLM prompt hacks we’ve discovered
What’s the experimentation stage of AI development like at Jam?

Subscribe to Building Jam on YouTube, Spotify, and Apple Podcasts.

New episodes drop every Friday at 10AM ET. See you there!

19 Open-Source Utils for Conversion, Formatting + More (no ads, free, client-side)

Ivanha Paz — Tue, 01 Oct 2024 23:28:06 +0000

We got annoyed with having to use those 1990s-looking websites covered in ads anytime we needed to convert data (e.g. PNG to data URI). So we set out to build a set of these tools with a better developer experience.

We started by making the tools we use ourselves. Any time a Jam engineer needed a tool, they'd send it in our #project-dev-utilities Slack channel. Eventually we had 14 tools!

Then we got our first community contribution! Thanks Cassidy Williams for an awesome .env to Netlify.toml converter. And a couple weeks ago, we launched the site so anyone can use the tools, all client-side, free, and open-source.

Since then OSS contributors have added 4 more dev utils 🔥 - so cool. If you'd like to contribute a tool, we will send you a hat and probably a pizza too!

Jam's Dev Utilities: jam.dev/utilities
Source: github.com/jamdotdev

List of all available utilities:

Our site is built with:

Are there any other tools that you wish existed or are there any other tools that you've made for yourself like this? Let us know! We'll be adding new tools regularly, so check back for more.

P.S. We’re hiring engineers and if you like building dev tooling, that’s our Jam and we’d love to chat: jam.dev/careers

We started a podcast to share what it's like at our startup 🎧

Ivanha Paz — Mon, 30 Sep 2024 19:53:25 +0000

For years I’ve wanted a product podcast that feels like friends talking about interesting things. Like all my favorite non-SaaS ones...

Back in April, during a team offsite in Bogotá, we had an idea. As we were single filing through the turnstile, onto the TransMilenio bus platform taking us to our next tinto ☕️ - it clicked 💡

What if we hit record on the conversations we're having each week? Decisions, moments, challenges. No fluff, just the unfiltered reality of Building Jam!

Our hypothesis was simple: our community will enjoy listening & get value from what we learn along the way.

Since we were together in-person, we decided to go for it right away! We recorded our first episode and launched the Building Jam podcast the next day.

For those of you interested in podcasting, I've included the easy (mostly free) stack we've been using at the bottom of this post.

It was a 12 week experiment, by the end we were supposed to make a "go-no-go" decision. We decided to keep going, even though our numbers weren't very high. We actually published our real podcast retro as an episode.

The TL;DR: we think the effort is worth it for those already tuning in, and we love doing it.

So we kicked off Season 2 and today marks week 24 of the podcast 🤯.

Part of the joy of growing a startup is getting to learn from the experts who've done it before - SO many unblocks happen thanks to these convos. For Season 2, we invited leaders from our favorite products (like Cloudflare, WorkOS, Warp, Campsite) to join us on the pod and get their advice on the challenges we're facing.

Here's what I learned!

About building a product devs love:

Design matters - a lot. Dev tools should work, duh! But, it's not just about building something useful anymore, devs want tools that are easy to use, with beautiful UI, and attention to detail.
Product-led engineering is the way. Most of the eng leaders we've gotten to talk to (and from my own experience at Jam) - it's clear that developers are taking a more creative and strategic role in product development. And it starts as early as hiring, with top startups conducting PM style interviews for eng roles.
Developers are not a monolith. Each dev community is its own thing. The vibes are super different depending on programming languages, stack, front-end/back-end, etc.
The best dev advocates make friends. You gotta be yourself, not just your “work self”. Building for builders is my dream job. It’s amazing to talk to people every day who are creating incredible products. But, we all have marketing teams and we all launch new features and we know the game. There are no shortcuts, just a lot of effort into trying to deliver a good experience that matches what your community wants.

About podcasting:

It's harder than it looks because you want to be real and relevant for other people.
You gotta be in it for the long haul.
It's totally worth it.

Jam's Podcasting Stack

Riverside - recording
Transistor - publishing
Descript - editing/transcription
Figma - design

You can subscribe to Building Jam on YouTube, Spotify, and Apple Podcasts.

New episodes drop every Friday at 10AM ET. See you there!