Ricky Perez is the Director of Support at Appcues - a platform that helps product teams deliver better user onboarding and in-app experiences.

We spoke to Ricky about how AI is reshaping customer support, why he believes every support team should get more technical, and how AI can turn support into a proactive partner to engineering.

Here are the highlights!

Support should get more technical

Ricky’s north star is simple: the less non-engineering work you put in front of engineering, the faster the hard problems get fixed.

“Can we free up bandwidth from our engineering team so they have to worry about zero support issues?”

For him, that means making support more self-sufficient. Teams need to have the ability to debug, identify misconfigurations, and even fix small bugs on their own.  

An autonomous support team gives engineers their time back: to focus on harder technical problems and ship new features. 

But that’s not the only benefit of having a technical support team. When certain issues do need to be handed off to the engineering team, these handoffs become way more efficient.   

When a customer reports “my flow isn’t working,” the support team already knows which flow, which settings, and which users are affected - complete with session replay and event logs.

That context means support can hand engineers a near-ready diagnosis: bug vs. misconfiguration vs. feature request. Engineering spends less time reproducing issues, and support spends less time waiting.

Where AI helps today

According to Ricky, there are three high-impact areas where AI already adds value:

1. Summarization: Long ticket threads can overwhelm new responders. A first-pass AI summary helps humans see what’s happening faster.
2. Triage. AI can identify which tickets belong to support, engineering, or product - cutting down on misrouted issues.
3. Deflection. Thoughtful, context-aware auto-replies that handle the top 20% of common requests let the team focus on deeper investigations.

What AI shouldn’t do, Ricky argues, is replace humans in escalations. “If a customer is angry or stuck, they want to be heard.” AI can route and prep the case, but escalations still require a level of patience and empathy that only a human can provide. 

AI helps support teams be proactive instead of reactive

Ricky believes the real promise of AI is stopping tickets before they’re created.

Appcues recently launched Captain, an in-app insights agent that surfaces configuration issues and product usage patterns. The long-term goal is to have Captain flag broken or unseen experiences before a user ever files a ticket.

In Ricky’s words: “Stop the spark before it becomes a fire.”

By combining in-product telemetry with AI alerts, the team can turn support from a reactive function into a proactive one that prevents frustration rather than just resolving it.

Ricky’s hiring philosophy: empathy first, tech second

AI is lowering the barrier to entry for technical work. Tools like ChatGPT, Claude, and Lovable make it easier for anyone in support to learn CSS, SQL, or API debugging.

That’s why Ricky hires first for empathy and curiosity, not credential: “If you pass the vibe check, we can teach you the tech.”

The mix he’s after: emotionally intelligent communicators who love solving puzzles, and are comfortable using AI to learn new technical skills on the job.

Actionable takeaways for support leaders

• Level up technical depth. Teach team members basic debugging and log analysis; create a “support engineering” path. It's easier than ever before. 
• Choose AI-capable tooling. Your help desk is now a platform for automation - pick one that supports experimentation.
• Automate the first mile. Summaries, triage, and deflection save time, but humans handle escalations.
• Go proactive. Use product telemetry and AI alerts to fix misconfigurations before tickets are submitted.
• Package context for engineering. Auto-generate reproduction steps and clear categorization (bug, config, feature) and save your engineers’ time. 
• Hire for curiosity. AI closes the skills gap, but empathy and problem-solving still win.

Support is evolving fast: from a reactive function to a technical, proactive partner that keeps engineering focused and customers happy. Ricky’s approach to this shift aligns with many other support leaders we’ve spoken to for this series: hire curious and empathetic humans, and use AI to empower them.

We had such a great time jamming with Ricky! We’ve been having similar conversations with support and engineering leaders at orgs like Monday.com, Intercom, and Productboard to unpack how they actually build with AI. You can find previous episodes on YouTube.

Here are the highlights from our conversation.

AI as a co-pilot, not a replacement

Vanta’s engineers use AI across multiple parts of the dev cycle - from test generation to writing RFCs and postmortems. But Iccha believes AI’s value today is in augmentation, not automation. 

Tools that do code generation can be a hit or miss. Real-world codebases have years of patterns baked in - and AI tools aren’t yet thinking about how a team wants to uplevel or evolve those patterns.

Instead of expecting AI to replace code gen, Iccha’s team treats it as a thought partner: helping them brainstorm, debug, and document faster. The near-term impact is felt in speed and clarity, not yet in fully automated coding.

Where AI drives real velocity gains: testing and communication

When we asked Iccha which part of the dev cycle AI is most helpful for, she mentioned testing and communication.

We use a third-party vendor to generate unit tests for older parts of our codebase to improve test coverage - and AI’s been great for that.

ChatGPT is also a great brainstorming partner. I can start with a few bullets, and it helps me flesh things out or spot gaps.

By focusing AI on repetitive, but essential tasks - like test generation and documentation - the team compounds small efficiency wins without compromising quality.

How AI has changed Vanta’s hiring process and priorities

AI is changing how Vanta hires and evaluates engineers. Given how fast the rate of change is, Iccha thinks engineering leaders should almost disregard whether a candidate knows the latest frameworks, and focus on how open they are to learning and experimenting.

The biggest thing I’m looking for in new hires is how willing they are to adopt and try new tools. Growth mindset has become more important than ever.

There are people who say, every new tool is a distraction. I need more open-mindedness. Let's try it, and if it doesn’t work, fine.

According to Iccha, the best engineers are curious enough to explore, but disciplined enough to not chase every shiny object.

Vanta has also changed their interview process to align with the times, given that every engineer now has AI copilots at their disposal. 

We’re discussing how to make our interviews reflect the real world - where engineers have access to AI tools. The idea is to let candidates use Cursor or Copilot during interviews and evaluate how they leverage them.

The company is also exploring ways to prioritize code review over code generation. 

Code review becomes a more important skill than ever with AI code generation.

As more code is written by machines, human judgment: deciding what’s good, safe, and maintainable becomes the differentiator.

AI helps engineering leaders get close to the codebase again

AI has brought engineering leaders like Iccha closer to the codebase by freeing up their time and taking care of mundane, repetitive tasks. 

“Cursor empowered me to be closer to the code and more self-sufficient. Over my winter break, I built a TypeScript program to analyze incident postmortems with LLMs - something I’d normally ask an engineer to do.”

AI gives leaders hands-on visibility into problems they’d otherwise have to delegate. That creates tighter feedback loops between management and execution.

Velocity depends on seniority

According to Iccha, AI’s impact varies based on experience level. Iccha thinks AI makes senior engineers faster, and could actually make junior engineers slower. 

The more senior the engineer, the more innovative they are about how to leverage AI to unblock themselves. For junior engineers, sometimes the opposite happens - they don’t yet know what ‘done’ or ‘good’ looks like, and so AI can actually slow them down.

She also mentioned how senior engineers in her team lead by example, documenting AI workflows, sharing prompt libraries, and mentoring juniors on how to verify rather than blindly trust AI output.

Takeaways for engineering leaders:

• Start narrow: Deploy AI where the ROI is obvious. In Vanta’s case, this was testing and documentation.
• Hire for curiosity: Growth mindset is a better predictor of success than AI tool fluency (which is bound to shift over time)
• Redesign interviews: Test for fundamental technical acumen, but also let candidates use AI and evaluate how they prompt and review. 
• Invest in review culture: Great engineers spend more time auditing code than writing it. This will become increasingly critical as machines write most of our code. 

Vanta’s approach shows what it looks like to integrate AI into an org with a strong engineering culture. Done right, AI can help engineering teams become thoughtful, fast, and self-sufficient.

We had a great time jamming with Iccha, and hope her playbook helps leaders in their organizations.

You can watch our full conversation with Iccha on YouTube. You can also check out previous conversations with product and engineering leaders at Intercom, Monday.com, Vercel, and more.

Monday.com is one of the world’s largest productivity suites, used by teams at orgs like McDonald’s, Coca-Cola, Canva, and 60% of the Fortune 500. In the last year, they’ve gone all-in on AI, shipping three major new products, including Sidekick, their new assistant that helps teams go beyond managing work to actually getting work done. 

We spoke to Or Fridman, AI Group PM at Monday.com, to learn how his team builds with AI.

Here are the highlights!

Co-create with users (while avoiding scope creep)

When Or’s team set out to add AI features to Monday.com, they ran iterative experiments that combined two approaches:

• Nail one job. Build a narrow feature that solves a concrete problem really well (like updating items on a board).
• Leave room for discovery. Give users a blank canvas to explore new use cases, then fold the most valuable behaviors back into the product.

The result was a product that has evolved with user needs, based on real usage - instead of adding AI for the sake of AI.  

Building AI products is different

Traditional features are deterministic: inputs and outputs are defined in advance, and every user action maps to a predictable result. In contrast, AI features are non-deterministic. The same prompt can return different outputs, which means PMs have to design for variability.

At Monday.com, that forced the team to rethink the PRD. Instead of a user story that says “when the user clicks X, show Y,” they had to spell out questions like:

• What does “good” look like? If a user asks about sprint performance, should the assistant return a paragraph summary, a bulleted list, or a chart of metrics? Each choice implies different UX affordances and evaluation criteria.
• What controls keep users in the loop? Do they get a regenerate button, the ability to edit outputs inline, or an explicit undo path if the system makes a change?
• How to establish trust? Should results be paired with citations back to the source data? When should the model hedge or ask for clarification instead of answering confidently?

The basics of product still apply but the scope of the spec is larger. AI PRDs look less like feature tickets and more like data-product specifications: defining the model’s inputs, the expected shape of outputs, the evaluation metrics, and the safety mechanisms around them.

PMs are no longer just shipping features, they’re shaping probabilistic systems.

Compressing feedback loops

AI gives product teams a way to significantly speed up product feedback loops. At Monday.com, PMs use AI-assisted tools to brainstorm, prototype, and even “vibe-code” mockups. Instead of the old linear flow - PM writes a PRD, designer mocks it up in Figma, engineer codes - those steps all blur together. A PM can draft a rough flow in minutes, vibe code a working prototype, test it with users, and refine it alongside design and engineering.

In a world where model capabilities evolve every few weeks, that speed is essential. 

What skills do they look for in PMs? 

The fundamentals of a good PM haven’t changed: be user-focused, strategic, collaborative. But Or adds one more requirement: adaptability. AI evolves weekly, not yearly. The best PMs are the ones who can keep pace, experiment, and fold new capabilities into the product without losing sight of user value.

We asked him if companies should hire PMs who specialize in AI, and Or’s answer was clear: better to hire strong product thinkers who can learn AI than hire for a narrow set of tools that may change in six months.

Looking five years out

Or expects Monday.com to evolve from being the place where teams manage work to the place where they also execute it. He also sees interaction modalities shifting: chat, questions, voice, and images will replace clicks and menus as the primary interface for work.

For a marketing manager, that could mean not just planning campaigns inside Monday, but generating assets and running them end-to-end without leaving the platform.

Actionable takeaways for builders

1. Co-create with users (without losing focus). Involve users early to discover how they want to use AI, but anchor the product around a single, well-defined workflow.
2. Account for non-determinism in PRDs. Define inputs, expected output shapes, trust mechanisms, and evaluation criteria upfront.
3. Compress feedback loops. Use AI internally to turn ideas into prototypes quickly so users can guide what’s worth building.
4. Hire for adaptability. Prioritize PMs who can learn fast over PMs who happen to know the current thing. 
5. Design for new interfaces. Natural language, chat, voice, and images are becoming the default ways users interact with software.

We had such a great time jamming with Or! We’ve been having similar convos with product and engineering leaders at top orgs (like Intercom, Honeycomb, and Vercel) to unpack how they actually build with AI. You can find previous episodes on YouTube.

Was really easy to do, here's how you can make your own app screen animations using AI:

Step 1 – I started by exporting a Figma frame of the app.

Step 2 – I uploaded the Figma frame to Claude, and told it what I was trying to accomplish and asked for a prompt.

Step 3 – I uploaded that frame + prompt to Veo3 Flow's Frame to Video tool.

Step 4 – Done! Light Mode, on! 🔆

Here's the prompt used (thanks Claude). It's a little cringe when you read it as a human but it worked well for AI!:

```
Create a premium iOS app launch animation that transforms these product stills into a cinematic reveal. The animation should be elegant with sophisticated 3D camera work and lighting.

Visual Treatment:
Phones float weightlessly in 3D space with gentle rotation and subtle parallax depth
Dramatic lighting shifts from soft ambient to focused spotlighting on key moments
Premium materials: subtle reflections on glass, soft drop shadows, elegant glows around active elements
Smooth easing curves throughout (ease-in-out, no linear motion)

Camera & Movement:
Graceful orbital camera movement around the interfaces
Shallow depth of field that guides focus
Cinematic framing with negative space
Seamless transition between the two app states

Constraints:
DO NOT add new UI elements - only animate existing interface components
Maintain authentic app functionality and visual hierarchy

Tone:
Sophisticated, premium, worthy of a keynote reveal.

```

Pavel Malyshev leads global customer support at Productboard - a product management platform used by orgs like Autodesk, Zoom, and Salesforce. 

We were especially excited for this conversation because Productboard’s approach mirrors a trend we’ve been watching closely: AI is pulling engineering and support closer together.

At Productboard, support and engineering operate as one system. Pavel shared how his team uses AI to shorten resolution times, streamline escalations, and surface the right context so engineers can fix issues faster.

Here are the highlights from our conversation.

Resolution times are what ultimately matter 

Many companies obsess over deflection rates as the north star for support success. Pavel thinks that approach is wrong. Customers don’t care about deflection rates. They care about how quickly their problems are resolved. 

Deflections don’t necessarily mean you get the best customer experience. Resolutions do.

Everything Pavel and his team do is oriented towards reducing resolution times and interaction counts. To that end, they use AI to triage issues better and escalate them smarter. 

The faster an issue reaches the right engineer with the right context, the faster it gets solved. That’s where AI is making the biggest impact: shortening time-to-resolution by reducing back-and-forth interactions.

His advice to support leaders: Don’t over-index on deflections. Track resolution times and interaction counts. If AI can cut a four-message ticket down to one or two, that’s the metric that matters.

Closing the gap between support and engineering 

At Productboard, support and engineering are tightly linked: both measured by product outcomes.

When a ticket comes in, Pavel’s team uses AI to enrich it with technical context, so engineers can get straight to fixing the problem instead of diagnosing it.

AI helps surface patterns, context, and even hints from the code itself, giving engineers the clarity they need to resolve issues faster (and freeing support from endless back-and-forth).

The golden age of DIY 

Off-the-shelf solutions like Intercom’s Fin have been useful for async replies, but Pavel thinks DIY is where the real leverage is. His team is constantly experimenting with Zapier, Make, and n8n to craft lightweight internal automations.

Whether it’s QA checks, sentiment analysis, or custom copilots, the ability to stitch together tools means teams don’t have to rely on other companies to ship features that are hyper-specific to their workflow. 

Pavel recommended starting small. Pick a single pain point (like analytics or QA) and automate with low-code tools before scaling up.

Support tickets as product feedback loops 

Support is a goldmine of customer feedback, but most orgs only analyze a fraction of their tickets. Pavel sees AI as a way to unlock the full potential of support tickets.

By running tickets through LLMs, his team can generate trend reports, voice-of-customer insights, and targeted product feedback. These insights help the product team prioritize, and give support a louder voice in the product development loop.

Even a simple pipeline that summarizes themes from 1,000 tickets can give PMs more insight than quarterly customer interviews.

How support jobs are evolving with AI

There’s a lot of noise online about AI completely replacing support roles. Pavel disagrees. Instead, he sees two paths emerging:

1. Human support becomes white-glove: support roles evolve into CSM-like roles, delivering white-glove experiences and uncovering “aha moments” for customers.
2. AI orchestration: ops-driven roles where support reps design, tune, and oversee the automations powering support at scale.

Either way, the baseline skill set is changing. Critical thinking, analytics, and the ability to “speak AI” will soon matter more than fast typing or handling simple tickets.

The Bigger Picture

What Pavel sees at Productboard is a glimpse of where customer support is headed:

• Resolution quality > deflection rates
• Increased collaboration between support and engineering
• DIY AI ops as a competitive advantage
• Feedback loops powered by LLMs
• New roles focused on orchestration and strategy

The core truth remains: customers don’t care how many tickets you deflected. They care how quickly and accurately their problem gets solved. 

AI isn’t replacing support, it’s redefining what great support looks like.

We had a great time jamming with Pavel! We’ve been having similar conversations with product and engineering leaders at top engineering orgs (like Vercel, Wix, Intercom, etc) to unpack how they actually build with AI. You can find previous episodes on YouTube. 

As a part of our AI Speedrun series, we asked her how her team at Honeycomb builds with AI. Below is a recap of the highlights from our conversation.

AI means experimenting more 

We asked Charity where AI is actually accelerating engineering. For her team, especially on front-end and design, it’s in the ideation phase.

The ideation phase, when you're throwing away a lot of code anyway, has gotten a lot faster.

Before, someone might spend a whole week going down one path just to realize it doesn’t work. Now, they can do that in an afternoon. Honeycomb’s engineering velocity has improved because they’re spending more time on the right things.

But how do you know it's the right thing? You ship it to prod.

At Honeycomb, production is the ultimate source of truth. AI helps get features into users’ hands faster. And if it doesn’t land in prod, it doesn’t count.

Great engineers are great communicators

AI has changed a lot at Honeycomb, but one thing it hasn’t changed is how they hire. Many orgs are focusing on specific AI oriented skills, but the team at Honeycomb is sticking to what they’ve always prioritized: communication.

We've always indexed heavily on communication skills. That’s never been more true than with AI.

During technical interviews, engineers get the usual take-home assignment, but then they also have to explain their decisions, trade-offs they made, and their overall thought process behind the code. According to Charity, engineers who can articulate clearly are engineers who can actually leverage AI meaningfully.

The future of software: disposable vs. indispensable

Charity thinks software will fall into two distinct types:

1. Disposable software: quick experiments vibe-coded rapidly and discarded just as easily.
2. Indispensable software: critical infrastructure that has to be reliable, with robust observability and maintenance. 

There is a future where both these categories exist in parallel. AI has enabled disposable software - fast, experimental, low-risk tools - but indispensable software will still reign, especially in domains where there's small room for error: logistics, healthcare, etc. This category of software will always require skilled engineers and SREs to ensure reliability and safety.

There's always going to be a place for cynics in the engineering world—those who ask, ‘What's going to happen when this crashes into reality?’

The future of engineering tools

Builders will increasingly rely on one integrated environment, likely agent-driven IDEs via MCPs or some other protocol that keeps them in flow state and reduces context-switching.

There’s a lot of noise online around when this might actually happen and what engineering orgs should do about it, but Charity doesn’t care about the hype. She’s just focused on setting up the right workflows, instead of obsessing over standalone interfaces. If her team has the right workflows in place, they can plug in to any future agentic protocol or platform fairly quickly. 

The most important surface for engineers is their workflow. If you focus there, you'll be fine.

We had a blast jamming with Charity! Check out similar conversations with product and engineering leaders at top engineering orgs (like Vercel, Wix, Intercom, etc) to unpack how they actually build with AI. Full episodes on YouTube. 

Intercom is a customer support software used by orgs like Microsoft, Anthropic, Perplexity, Vanta, and Clay. Every month, they serve over 600M end-users! The Intercom team has spent a lot of time thinking deeply about AI’s impact on customer support. They were one of the first movers in the space when they launched Fin: their AI customer service agent, earlier this year. 

We spoke to Intercom’s CTO Darragh Curran to find out how his team actually uses AI. 

Here are the highlights!

AI as a product, not a plugin

Intercom has been shipping AI features for years, but the step change with modern LLMs unlocked a completely new set of possibilities. Instead of bolting AI onto workflows, they built the infrastructure to test, measure, and iterate - hundreds of A/B tests, all compounding over time.

That’s how Fin’s resolution rate grew from ~26% to over 50%, often improving a percentage point each month. The process goes beyond just swapping in new models. It focussed on treating AI like a product surface to conduct experiments. 

Measuring engineering velocity 

We asked Darragh if AI has made their engineering team faster. Darragh was candid here: he said coding feels easier, but bottlenecks have moved elsewhere. Specifically decision-making, wait times, review loops. So they measure what matters:

• PR throughput per engineer.
• Feedback wait times (tests, reviews, deploys). If someone waits six hours for a review while another waits 30 seconds, they investigate.
• % of code changes co-authored by AI. Today, ~1–2% of changes are fully written by AI; a much larger share is AI-assisted. 

In short, AI can help increase velocity only if you know where the bottlenecks really are.

Intercom’s internal dev tools team 

Inside Intercom, there’s a team dedicated to making AI the default developer environment. They run autonomous jobs that remove dead code, clean up stale flags, and file PRs: tedious but important jobs no human wants to prioritize.

Over time, these automations evolve into repo-wide refactors and eventually bigger lifts like framework swaps. Think of it as an AI dev-tools startup inside the company, proving safety with narrow scopes before expanding to higher-stakes jobs.

“There’s valuable work AI can do that humans will never prioritize - even though it compounds.”

Creating a shared repository of AI engineering best-practices 

Some engineers intuitively use AI tools; others need a practical framework to upskill. Darragh expects the team average to rise a full point on their internal “impact scale” just by evenly distributing know-how, even if the tools stay static. 

They proactively standardize prompts, document repeatable wins, and review diffs as a team so these patterns spread.

“If you’re not using these tools, you’re probably underperforming - and you’ll get left behind.”

Choosing metrics that matter

Intercom rejects “feel-good” dashboards. They use behavior-shaping metrics:

• Resolution rate (for agents like Fin), constrained by accuracy.
• PR throughput, review latency, deploy cadence (for engineering).
• AI contribution share (to set expectations and track adoption).

Set thresholds that trigger action (e.g., review waits > 2 hours = auto-escalation). Make them visible so teams self-correct.

He thinks teams should publish a weekly metrics memo that documents resolution rate changes, top latency offenders by team, percentage of AI-assisted changes, and experiments that moved the needle.

Accuracy over spectacle

Intercom’s biggest lesson with Fin was: correctness beats cleverness. Customers don’t care if an agent sounds smart. They just want to have their problem resolved quickly. Yes, the magical moments AI can create for the customer matter, but every UX win at Intercom is paired with a truth metric: hallucination rate, retrieval coverage, source accuracy.

When a change boosted deflection but hurt accuracy, they rolled it back. A customer’s trust is harder to earn than it is to lose.

Takeaways for builders

• Build the engine, not the demo. An A/B infrastructure, guardrail metrics, and repo-wide automation paths matter more than the flashy first win. 
• Fix the queues. If AI doesn’t move velocity, your bottleneck is in reviews, tests, deploys, or prioritization.
• Automate the grunt-work. Start with dead code and flag cleanup; graduate to refactors. The compounding ROI is real.
• Codify usage. Make AI-first environments default and share patterns until the average rises.

These principles have led to steady, compounding improvements in both customer trust and developer productivity.

We had a great time jamming with Darragh! We’ve been having similar conversations with product and engineering leaders at top engineering orgs (like Vercel, Wix, Vanta, etc) to unpack how they actually build with AI. You can find previous episodes on YouTube. 

We worked with customers to measure how quickly high priority tickets were fixed if a Jam was attached vs one where no Jam was attached. They found tickets with a Jam attached were fixed 12 hours faster. This makes sense–– without a Jam, engineers have to manually investigate issues from scratch and wait for back-and-forth communications to gather necessary debug info.

One company found that after deploying Jam, bugs were fixed in a single day instead of 4-5 days. which led to a reduction of 88% bugs reported. In addition, they required 84% fewer troubleshooting calls, instead relying on a Jam – saving both their customers and their engineers from more meetings in the day.

But what does this mean in dollars and cents? First, we’ve found that each Jam saves a minimum of 35 minutes of engineering investigation time. This is actually quite conservative based on our data, but we wanted to err on the side of caution. We then assumed each developer handles roughly three bugs per week.

Taking a mid-level engineer's salary in the US ($175k) and factoring in benefits and taxes ($225k total), we arrived at about $1.80 per minute of engineering time. This means each Jam saves approximately $63 in engineering time (35 minutes × $1.80).

For a single engineer over a year, this adds up to $9,072 in savings, only accounting for direct engineering time saved. We’ve also found it saves companies around $3,000 per PM based on how quickly they can triage & communicate these issues. We haven't calculated in the revenue impact of reduced customer churn from having fewer longstanding issues, or the revenue impact of being able to deliver more new features, though certainly operational efficiency and product quality directly correlate to customer revenue beyond time saved.

Just purely in engineering costs, Jam saves companies $9,000+ per engineer per year. Let's say you have a workforce of 50 engineers, that's a total saving of deploying Jam of $453,600. You can use this ROI calculator to measure the savings you can reliably expect by deploying Jam in your own organization.

If you’re interested in learning more about how other enterprises are using Jam wall to wall, saving their teams $1M for every 110 engineers on their team, you can book a demo.

Thanks for being a part of Jam. We’re really excited about making it a lot faster to develop software because that’s how the future can arrive sooner for everyone. Appreciate you being on the journey with us to make engineering a lot more productive, one Jam at a time.

We built video annotations with tldraw! It’s a new feature we’re launching next week, and we’re really excited for all of you Jamming to try it. So today, Jam engineers: Max, Aidan, and Rui get into the technical details of implementing the tldraw library - so you can draw stuff while recording your screen.

Excited to show you what we built!

0:37 Why implementing annotations was so different than the blur tool
2:55 How Max discovered we already had a tldraw license
4:25 Why we love tldraw: React-SVG dual architecture & more details
8:55 Demo of video annotations & why it’s different than Jam’s screenshot feature
11:29 Why we ultimately decided to use tldraw for video too (it looks so nice!)
12:52 Our biggest takeaway for building w/ 3rd party libraries

Episode links:
- Try tldraw
- Check out the episode about Jam's new blur tool

We’re getting ready to release Jam’s newest feature, the blur tool! We can’t wait for you all to try it, so this week on Building Jam we’re showing you everything. Figma walkthrough, staging demo, and all the unexpected twists and turns of blurring what’s in your browser — as you’re recording!

1:08 A lil blur tool demo
2:26 Figuring out an extra setting w/o cluttering our extension
5:27 Selecting, clicking + more design details in Figma
6:35 Why not make the selector a strawberry?
8:30 Why we decided against per-team access (more free blur)
13:14 The biggest eng challenge? Everything but the core feature!

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

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

We just had our first company hackathon! It was so much fun to get together & build stuff IRL! From AI agents to help you fix bugs & test fixes to silly buttons that break websites, we’re excited to show you what it was like.

We hope you enjoy.

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

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