DEV Community: Ivan

The best SaaS video tools in 2026

Ivan — Mon, 12 Oct 2026 17:18:17 +0000

SaaS teams tend to need two kinds of video. There is the short promo, the 15 to 60 second piece that goes on the homepage, in a launch post or in a paid social campaign, and there is the explainer, which is longer and walks someone through what the product does and why it matters. Some tools are good at one and poor at the other, so I have tried to be clear about which is which.

1. Teasr

Teasr makes short promo videos from a website. You paste your URL, it reads your colours, fonts, copy and product images, turns them into a 15 to 60 second motion video and writes an original piece of music for it. Most videos are ready in about 10 minutes, at 1080p and 60 fps, and you ask for changes in plain language.

A few seconds of a video Teasr made from the website of TapNoise, a keyboard sound app.

Best for: SaaS teams that want an on-brand promo for the homepage, a launch or a social campaign without briefing an agency or opening a motion design tool.

Limitation: Teasr is built for promos, not explainers. It does not record your screen, has no voiceover or avatars and is not a general video editor, so it cannot walk someone through a feature step by step. It also depends on your website, so a site with few visuals gives it less to work with.

2. Synthesia

Synthesia generates videos with AI presenters. You write a script, pick an avatar and a voice, and it produces a talking-head video in many languages, which is why it is popular for training, onboarding and internal explainers.

Best for: explainer and onboarding videos that need a presenter, especially when you have to produce them in several languages.

Limitation: an AI presenter in front of a slide is a good fit for training content but tends to feel corporate for a homepage promo, and many viewers can tell it is generated.

3. HeyGen

HeyGen is another AI avatar video platform, with stock and custom avatars, voice cloning and translation, aimed at marketing and sales teams as much as training.

Best for: personalised sales videos, translated versions of existing videos, and explainers with a presenter where you want a custom avatar of someone on your team.

Limitation: like Synthesia, the output centres on a person talking, which is the wrong shape for a short brand promo, and usage is metered in credits, so heavy use needs watching.

4. Descript

Descript is a video and podcast editor where you edit by editing the transcript, with AI tools for removing filler words, cleaning up audio, recording your screen and generating clips.

Best for: founder-led explainer videos and screen-recorded walkthroughs where someone on the team is talking and you want to edit quickly.

Limitation: it makes recorded footage better, but it does not design anything for you, so a polished, animated promo is still on you.

5. Canva

Canva is the design tool most marketing teams already use, and its video editor, templates and AI generation tools mean you can make a promo next to the rest of your social assets.

Best for: teams that already use Canva for brand assets and want to make simple promos and social clips from templates.

Limitation: template-based videos look like templates unless someone with design skill reworks them, and getting animation to feel tied to your product takes time.

6. Animoto

Animoto is a drag-and-drop video maker built around templates, with screen and webcam recording, stock media and a licensed music library.

Best for: small marketing teams that want to assemble promo and social videos from their own clips and photos without learning an editor.

Limitation: the templates lean towards general business and social content, so a software product with UI screenshots can feel squeezed into a format built for photos.

7. Renderforest

Renderforest combines template-based video making with AI video, image and voice generation on a credit system, alongside logo and website tools.

Best for: teams that want a broad set of templates and AI generation models in one subscription and are happy to work within credits.

Limitation: the cheapest plan exports templates at 720p, and with so many models and credit types it takes some time to understand what you are paying for.

8. An agency or freelance motion designer

For a flagship explainer or a brand film, a human team with a scriptwriter, illustrator, animator and voice actor is still the high end.

Best for: funded SaaS companies that need a custom explainer which will sit on the homepage and in sales decks for a year or more.

Limitation: production takes weeks, the cost is far higher than any tool here, and when your product changes the video goes out of date with no quick way to update it.

How to choose

Decide first whether you need a promo or an explainer. For a short promo that looks like your brand, Teasr gets you there fastest when your website is already in good shape, and Canva or Animoto work if you want to assemble one yourself from templates. For an explainer with a person talking, Descript is the best choice when that person is you or a teammate, and Synthesia or HeyGen are worth a look when you would rather use an AI presenter or need many languages. Renderforest sits in between, with lots of templates and generation models in one place. An agency makes sense when the video is a long-term centrepiece and the budget allows it. Many SaaS teams end up with one of each, a short promo for the top of the funnel and a longer explainer for people who are already interested.

Tool	Best for	Starting price
Teasr	On-brand promo from your website in about 10 minutes	€19.50 per 15s video
Synthesia	AI presenter explainers and training in many languages	Free, Starter $18/month yearly
HeyGen	Avatar videos, personalised sales clips, translation	Free, Creator $24/month yearly
Descript	Editing founder-led and screen-recorded explainers	Free, Hobbyist $16/month yearly
Canva	Template promos next to your other brand assets	Free, Pro $144/year
Animoto	Drag-and-drop promos from your own clips	Free, Basic €7/month yearly
Renderforest	Templates plus AI generation on credits	Lite €8/month yearly
Agency or freelancer	Custom flagship explainers	Varies by quote

The best demo video tools in 2026

Ivan — Mon, 12 Oct 2026 17:08:02 +0000

"Demo video" covers a few different things. There is the walkthrough, where you show someone how to do a task step by step. There is the interactive demo, a clickable tour of your product that a visitor can explore on your website without signing up. And there is the short overview, a quick, polished piece that shows what the product is and how it feels before anyone commits to a longer demo. The first two are where screen recorders and interactive demo platforms shine, and the third is where Teasr fits.

1. Teasr

Teasr turns a website URL into a 15 to 60 second motion video. It pulls your colours, fonts, copy and product images from the page, animates them into a short piece in your brand and writes original music for it, and the video is usually ready in about 10 minutes, at 1080p and 60 fps.

A few seconds of a video Teasr made from the website of Stoll Kaffee, a coffee roaster in Zürich.

Best for: a short, polished overview at the top of a page or a social post, the piece that makes someone want to see the full demo.

Limitation: Teasr is not a demo tool in the walkthrough sense. It does not record your screen, there is no voiceover or avatar, it is not an editor, and it works from your website, so it cannot show someone how to complete a task in your app. If that is what you need, use one of the tools below.

2. Screen Studio

Screen Studio is a Mac screen recorder that turns raw recordings into clean product videos, with automatic zoom on clicks, smoothed cursor movement, captions, device frames and layouts for your camera.

Best for: recorded product walkthroughs that need to look polished, such as feature announcements, onboarding videos and tutorials.

Limitation: it only runs on macOS, and while it makes a recording look good, the pacing and the story still depend on how well you plan and record the take.

3. Loom

Loom is the quick way to record your screen and camera and share a link, with transcripts, comments and viewer analytics built in.

Best for: fast, informal demos for a specific person, like a prospect, a customer with a question or a teammate, where speed matters more than polish.

Limitation: Loom videos look like what they are, a person talking over their screen, which is perfect for one-to-one communication but less suited to a demo on your homepage.

4. Arcade

Arcade captures your product as you click through it and turns that into an interactive demo with hotspots and callouts, and it can also produce video versions with AI voiceover.

Best for: clickable demos embedded on a landing page, in docs or in a launch post, where you want visitors to explore at their own pace.

Limitation: the free plan's single published demo and video is too little for most teams, so in practice you are looking at the paid plan.

5. Supademo

Supademo is an interactive demo platform that lets you build guided demos from screenshots or recordings, with AI for personalising text, branching, analytics and, on higher plans, HTML-based demos.

Best for: teams that want to start with interactive demos on a free plan and grow into sales and customer success use cases.

Limitation: the more advanced features, like HTML demos and sandboxes, sit on the much more expensive Business and Growth plans.

6. Storylane

Storylane builds guided interactive tours from screenshots, videos or captured HTML, with lead capture, analytics and AI voiceovers, and it targets both marketing and sales teams.

Best for: B2B SaaS companies that want interactive demos on the website and in sales conversations, with CRM integrations.

Limitation: the jump from Starter to Growth is large, and HTML demos, A/B testing and personalisation tokens all live on Growth or above.

7. Navattic

Navattic is an interactive demo platform aimed at product marketing and sales teams, with HTML capture, AI copilot features, AI avatars on paid plans and deep CRM and sales tool integrations.

Best for: larger SaaS teams that want interactive demos tied into their marketing and sales stack, with account identification and pipeline reporting.

Limitation: with no public prices on the paid plans, it is hard to budget for without a sales conversation, and it is more platform than a small team needs.

8. Descript

Descript records your screen, webcam and microphone and lets you edit the result by editing the transcript, with tools for removing filler words and cleaning up audio.

Best for: longer narrated demos and tutorials where someone is talking throughout and you want to cut mistakes as if you were editing a document.

Limitation: it is an editor first, so screen recordings do not get the automatic zoom and cursor polish of a dedicated tool like Screen Studio without extra work.

How to choose

Start with what the viewer should be able to do afterwards. If they need to learn how to do something in your product, record it, with Screen Studio for polish, Loom for speed or Descript for narrated, editable tutorials. If they should explore the product themselves before talking to you, an interactive demo is the better format, with Arcade and Supademo being the easiest to start with and Storylane and Navattic built for bigger sales teams. If they just need to understand what the product is and feel something about it in under a minute, that is where a short overview from Teasr fits, and it works well at the top of a page with a walkthrough or interactive demo further down. Most teams need two of these, and very few need all of them.

Tool	Best for	Starting price
Teasr	Short, polished product overview from your website	€19.50 per 15s video
Screen Studio	Polished recorded walkthroughs (Mac)	$9/month billed yearly
Loom	Quick one-to-one screen and camera demos	Free, Business $18/user/month
Arcade	Embeddable clickable demos	Free, Growth $42.50/seat/month yearly
Supademo	Interactive demos with a usable free plan	Free, Scale $38/month yearly
Storylane	Interactive demos for B2B marketing and sales	Free, Starter $40/month
Navattic	Interactive demos tied into the sales stack	Free, paid plans on request
Descript	Narrated tutorials edited by transcript	Free, Hobbyist $16/month yearly

The best tools for making launch videos in 2026

Ivan — Mon, 12 Oct 2026 17:03:29 +0000

A launch video has a narrow job. It sits at the top of a Product Hunt page, gets posted on X and LinkedIn on launch day, and lives in the hero of your landing page afterwards. It should be short, it should look like your product and your brand, and it should make someone curious enough to click. That is a different job from a tutorial or a sales demo, so the tools below are chosen for that job.

1. Teasr

Teasr turns a website URL into a 15 to 60 second motion video. You paste your landing page, and it pulls your colours, fonts, headlines and product images, animates them into a short promo and writes original music for it. A video is usually ready in about 10 minutes, at 1080p and 60 fps.

A few seconds of a video Teasr made from the website of toni keramik, a small ceramics studio.

Best for: founders who already have a decent landing page and want a polished, on-brand launch teaser without learning motion design or hiring someone.

Limitation: Teasr works from your website, so if the site is rough or mostly text, the video will be too. It does not record your screen, there are no avatars or voiceover, and it is not a general video editor, so if you want to show a real click-through of your product you will need one of the tools below as well.

2. Screen Studio

Screen Studio is a Mac screen recorder that adds automatic zooms, smooth cursor movement, device frames and captions to whatever you record, so a plain screen capture comes out looking like an edited product video.

Best for: makers who want the launch video to show the product in use, and who are comfortable recording and timing a short walkthrough themselves.

Limitation: it is macOS only, and the result is only as good as the take you record, so you still have to plan the flow and record it cleanly.

3. Jitter

Jitter is a browser-based motion design tool, closer to a lighter Figma for animation than to a video editor. You build scenes from your own designs and animate them on a timeline, with templates to start from.

Best for: designers, or founders who think like one, who want full control over every frame of a short animated launch clip.

Limitation: you are doing the motion design yourself, which takes time and taste, and Jitter does not give you music, so you still need to source a track.

4. Rotato

Rotato is a Mac app for 3D device mockups. You drop in a screenshot or screen recording of your app, place it on a phone, laptop or desktop, and animate the camera around it to export a slick product shot or video.

Best for: mobile app launches and App Store or Product Hunt galleries where a rotating phone with your UI on it is exactly what you want.

Limitation: it is macOS only and it is a mockup tool, so it frames your UI beautifully but does not tell a story or add music; most people cut its exports into a longer video elsewhere.

5. Arcade

Arcade started as a tool for clickable, interactive product demos and now also generates videos with AI voiceover from those captures. For a launch, that means you can embed an interactive walkthrough on your landing page and export a video version for social.

Best for: SaaS launches where you want visitors to try a guided version of the product right on the landing page.

Limitation: the free plan is too tight for a real launch with more than one asset, and an interactive demo is a different thing from a punchy 20 second teaser for a feed.

6. CapCut

CapCut is a free video editor from ByteDance, available on desktop, mobile and the web, with templates, captions, effects and a growing set of AI generation tools.

Best for: founders on a zero budget who are happy to edit their own launch clip, especially vertical clips for X, TikTok or Reels.

Limitation: it is an editor, so you bring the footage, the structure and the brand consistency yourself, and its templates are built for social content rather than for software products.

7. A freelancer or motion design studio

The traditional route is still a good one. A good motion designer will write a script with you, design custom scenes and deliver something none of the tools above will match when it comes to originality.

Best for: funded launches where the video is a central asset that will run in ads and on the homepage for months.

Limitation: it takes weeks rather than minutes, costs a multiple of everything else on this list, and each round of changes goes through another person's calendar, which is hard when your launch date is fixed.

How to choose

Start from what you want people to see. If the point is the brand and the promise, a short motion teaser works best, and Teasr is the quickest way to get one if your landing page already looks good, while Jitter gives you full control if you have the time and design skill. If the point is the product working, record it with Screen Studio, or put a phone or laptop around it with Rotato. If you want visitors to try the product before signing up, an interactive demo from Arcade belongs on your landing page next to whatever video you post on launch day. CapCut is the right answer when the budget is zero and you have an afternoon, and a freelancer or studio is the right answer when the video matters for months and you have both time and money. Many launches end up using two of these together, a short teaser for the feed and a walkthrough for the page.

Tool	Best for	Starting price
Teasr	On-brand launch teaser from your website, about 10 minutes	€19.50 per 15s video
Screen Studio	Polished screen recordings of the product in use (Mac)	$9/month billed yearly
Jitter	Hands-on motion design in the browser	Free, Pro $10/month
Rotato	3D device mockup videos for apps (Mac)	€79 one-time
Arcade	Interactive demo on the landing page	Free, Growth $42.50/seat/month yearly
CapCut	Doing it yourself on a zero budget	Free, see pricing page for paid
Freelancer or studio	Custom, high-stakes launch films	Varies by quote

How to Get Your Brand Recommended by ChatGPT

Ivan — Fri, 23 Jan 2026 23:35:47 +0000

When someone asks ChatGPT "what's the best CRM for small businesses" or "can you recommend a project management tool," the AI provides direct suggestions. If your brand appears in those recommendations, you gain a significant advantage in the consideration process. If you are absent, potential customers may never discover you.

This guide explains how ChatGPT forms recommendations and what you can do to increase your chances of being recommended.

How ChatGPT Decides What to Recommend

ChatGPT does not browse the internet in real-time for most queries. Instead, it draws from patterns learned during training on large amounts of text data. When recommending products or services, ChatGPT references what it learned about brands, their reputations, their features, and how they are discussed across the web.

Several factors influence whether ChatGPT recommends your brand:

Content volume and quality: Brands with substantial, high-quality content explaining what they do and why they are valuable are more likely to be well-represented in training data.

Third-party validation: Reviews, mentions in publications, expert endorsements, and customer testimonials all contribute to how ChatGPT perceives your brand's credibility.

Clear category association: ChatGPT needs to understand what category your brand belongs to and what problems it solves. Ambiguous positioning leads to missed recommendations.

Reputation signals: The overall sentiment of how your brand is discussed online influences whether ChatGPT views you as a recommendable option.

Step 1: Audit Your Current Visibility

Before optimizing, understand where you stand. Ask ChatGPT the questions your potential customers might ask about your product category.

Test queries like:

"What is the best [your category]?"
"Can you recommend a [your product type]?"
"What are the alternatives to [your competitor]?"
"What [product type] should I use for [use case]?"

Document whether your brand appears, where you rank in the recommendation list, how you are described, and which competitors appear instead.

This baseline helps you prioritize efforts and measure progress. For a detailed framework, see our complete AI audit guide.

Step 2: Create Comprehensive Content

ChatGPT learns from content available on the web. If your brand has limited content explaining what you offer, why it matters, and who it helps, ChatGPT has little to reference when forming recommendations.

Develop content that clearly establishes your brand:

Product and service pages that explain exactly what you offer, not just feature lists but the problems you solve and outcomes you enable.

Comparison content that honestly positions your offering relative to alternatives, helping ChatGPT understand where you fit in the market.

Use case content addressing specific scenarios where your product excels, making it easier for ChatGPT to match you with relevant queries.

FAQ content answering common questions about your category and your specific offering.

Thought leadership demonstrating your expertise in your space through guides, analysis, and educational content.

The goal is ensuring that when ChatGPT processes information about your category, your brand is well-represented with clear, accurate, and comprehensive information.

Step 3: Build Third-Party Validation

ChatGPT weighs third-party sources heavily. Self-promotional content on your own website matters, but external validation carries more weight.

Focus on building:

Customer reviews on relevant platforms. Encourage satisfied customers to leave detailed reviews explaining their experience and the value they received.

Media coverage in publications your industry respects. Seek opportunities for features, interviews, or expert commentary.

Expert endorsements from recognized authorities in your space. Analysts, industry experts, and respected practitioners can provide valuable validation.

Case studies and testimonials that document real customer success, preferably with specific metrics and outcomes.

When ChatGPT encounters consistent positive signals about your brand from multiple independent sources, it increases confidence in recommending you.

Step 4: Strengthen Category Association

ChatGPT needs to clearly understand what category your brand belongs to and what specific problems you solve. Weak or ambiguous positioning leads to missed recommendations.

Ensure your brand is clearly associated with:

Your primary category: If you are a project management tool, that association should be unmistakable across your content and mentions.

Specific problems you solve: Beyond category, connect your brand to the particular challenges you address.

Your target audience: Who is your product for? Enterprise teams, small businesses, specific industries?

Key differentiators: What makes you distinct from alternatives in your category?

Consistent messaging across your website, third-party profiles, and external mentions reinforces these associations.

Step 5: Optimize for Related Queries

ChatGPT responds to many different phrasings of similar questions. Consider the various ways potential customers might ask about solutions in your category.

Create content addressing:

Direct category queries: "best [category]" type searches

Problem-based queries: "how do I solve [problem]" where your product is the answer

Comparison queries: "alternative to [competitor]" or "[product A] vs [product B]"

Use case queries: "[category] for [specific situation]"

Feature queries: "[category] with [specific capability]"

Content addressing these different query types increases the chances that ChatGPT connects your brand with relevant questions.

Step 6: Maintain Accuracy and Consistency

ChatGPT can become confused when it encounters contradictory information about your brand. Ensure consistency across all platforms:

Consistent naming: Use the same brand name everywhere, avoiding variations that might not be connected.

Accurate information: Keep product information, pricing, and claims current and accurate across all sources.

Unified positioning: Communicate the same core value proposition across channels.

Inconsistencies in your information can reduce ChatGPT's confidence in recommending you or lead to inaccurate descriptions.

Step 7: Monitor and Adjust

AI recommendations are not static. ChatGPT's responses can shift as models are updated, and your competitive landscape continues evolving.

Establish ongoing monitoring:

Regular testing: Query ChatGPT monthly with your key questions and document changes.

Competitor tracking: Note when competitors appear or disappear from recommendations.

Description accuracy: Monitor how ChatGPT describes your brand and correct inaccuracies through content updates.

Continuous attention allows you to identify and address issues before they become significant problems.

What About ChatGPT's Browsing Features?

Some ChatGPT users have access to browsing capabilities that allow real-time web searches. For these queries, traditional SEO factors become more relevant since ChatGPT actively searches for current information.

Strong search visibility complements AI recommendation optimization. Brands that perform well in both areas capture opportunities regardless of how users interact with ChatGPT.

For more on how traditional SEO and AI optimization work together, see our GEO vs SEO guide.

Common Mistakes to Avoid

Expecting immediate results: ChatGPT's knowledge is based on training data, not real-time information. Changes you make today may take time to influence recommendations.

Focusing only on your website: Third-party validation often matters more than your own content. Balance investment between owned content and external presence.

Ignoring competitors: Understanding what competitors who get recommended are doing differently provides valuable insights for your own strategy.

Generic content: Vague marketing language does not help ChatGPT understand what makes you valuable. Be specific about capabilities, outcomes, and differentiators.

Getting Started

Begin with an audit of your current ChatGPT visibility. Understanding your baseline tells you whether you need foundational work or refinement of existing presence.

If you are absent from recommendations entirely, prioritize comprehensive content development and third-party validation. If you appear but are poorly positioned, focus on strengthening specific weak areas.

The brands establishing ChatGPT recommendation presence now are building advantages that become harder for competitors to overcome as AI assistants become more central to how people discover products and services.

Want to understand how your brand currently performs in AI recommendations? Get a free visibility report to see where you stand and what to prioritize.

Git Isn't Enough for AI Coding: What I Use Instead

Ivan — Fri, 23 Jan 2026 22:59:50 +0000

I've been using Git for over a decade. It's one of the best tools ever made for software development. But after six months of heavy AI-assisted coding, I've had to admit something uncomfortable:

Git's workflow doesn't match how AI coding actually works.

This isn't a criticism of Git. It's an observation about how AI assistants have changed the development loop.

The Problem

Git was designed for deliberate, discrete changes. You work on something, stage it, write a meaningful commit message, and move on. The rhythm is: work → commit → work → commit.

AI coding breaks this rhythm completely.

When I'm iterating with Cursor or Claude Code:

I try three different approaches in ten minutes
The AI modifies files I didn't explicitly ask about
Changes happen faster than I can meaningfully review them
I'm focused on guiding the AI, not thinking about version control

In practice, I end up with long gaps between commits. And those gaps are exactly when AI does something unexpected—deletes files it thinks are "unused," breaks imports, or refactors in a direction I didn't want.

Git protects what I commit. It can't protect what I don't.

What I Tried First

More discipline: "Just commit before every AI operation." This works in theory. In practice, when I'm in flow and iterating quickly, I skip it. The one time I forget is the time Cursor deletes my middleware folder.

Cursor Checkpoints: These are useful but limited. They only cover Composer interactions, don't persist across sessions, and revert everything from a prompt (including manual edits I made after).

VS Code Local History: File-by-file recovery. Tedious when AI changed 20 files.

Git stash: Manual, requires discipline, only one stash at a time.

None of these provided reliable, continuous protection.

What I Use Now

I found a tool called mrq that takes a different approach. Instead of requiring commits, it captures every file change automatically in the background.

npm install -g mrq-cli
mrq watch

That's it. Now every change is recorded—from AI, from manual edits, from anything.

When something breaks:

mrq history          # See recent
snapshotsmrq restore abc123   # Go back to any point

I'm back to exactly where I was, even if I never committed. The mrq docs explain the full workflow, but honestly the basics are just those two commands.

How I Use Both Together

I haven't replaced Git. I use both for different purposes:
Git: Meaningful commits, collaboration, deployment, PR reviews
mrq: Continuous protection during AI iteration

My workflow:

Start session: mrq watch
Work with AI freely, iterate fast
Hit a milestone: git commit -m "Feature complete"
Something broke? mrq restore

Git gives me clean history for collaboration. mrq gives me protection during the messy iteration phase.

When You Need This

If you're doing light AI usage—occasional Copilot suggestions, simple completions—Git alone is probably fine.

If you're doing heavy AI coding—Cursor Composer, Claude Code multi-file edits, agent mode—you need continuous protection. The speed and unpredictability of AI changes creates gaps that Git's commit model doesn't cover.

There's a good breakdown of why git doesn't fit AI workflows that explains this in more detail.

Conclusion

Git remains essential. It's still the backbone of collaboration, deployment, and project history.

But AI coding has exposed a gap between commits where you're unprotected. For me, the solution was adding automatic snapshots to my workflow—not replacing Git, but complementing it.

The developers I know who work confidently with AI have all set up some form of continuous protection. The specific tool matters less than having something that doesn't require discipline to remember.

What do you use for AI coding protection? I'm curious if there are other approaches I haven't tried.

The Best Way to Use Teenage Engineering Manuals

Ivan — Wed, 21 Jan 2026 17:45:19 +0000

If you own a Teenage Engineering device, you've probably tried to use the official PDF manual. The EP-133 manual is 144 pages. The OP-1 manual is 100+ pages. The OP-XY manual is even longer. These are dense technical documents that assume you'll read them cover-to-cover, but in reality you just need quick answers to specific questions.

There's a better way: Teenage Manual - a searchable, conversational interface for all Teenage Engineering device manuals. Instead of scrolling through PDFs, you can ask questions and get direct answers from the official documentation.

What It Is

Teenage Manual is the best way to access Teenage Engineering manuals. It supports 9 devices with full manual access:

EP-133 (KO II) - The sampler
OP-1 - The original portable synth
OP-1 Field - The upgraded version
OP-XY - The latest flagship
EP-1320 - The medieval-themed sampler
EP-40 - The riddim machine
TX-6 - The portable mixer
TP-7 - The field recorder
CM-15 - The modular controller

Each device has its own page with two ways to access the manual: ask questions in a chat interface that knows the manual inside and out, or browse the manual in a structured view organized by category.

How It Works

The AI chat interface is available on each device's ask page - for example, EP-133 ask, OP-1 ask, OP-1 Field ask, OP-XY ask, EP-1320 ask, or EP-40 ask.

The AI uses the full OCR'd manual as context, so it's not making things up - it's giving you answers directly from the official documentation. Ask "how do I copy a pattern?" and it tells you exactly how, with the right button combinations and clear instructions.

You don't need to know the exact terminology. Ask "how do I make it louder?" and the AI understands you're asking about volume or gain. The AI knows which device you're asking about, knows the full context of the manual, and can reference specific sections and button combinations.

Error Codes and Troubleshooting

When your device shows an error code like E.05 or E.10, you need to know what it means and how to fix it. Teenage Manual has dedicated error code pages for devices that have them:

EP-133 error codes - Complete troubleshooting guide for E.01, E.02, E.03, E.05, E.10, E.11, E.12
EP-1320 error codes - Fixes for E.01, E.02, E.03, E.04, E.05
EP-40 error codes - Solutions for E.01, E.02, E.03, E.04, E.05

Each page shows what each error code means, whether it's a hardware issue or something you can fix yourself, and step-by-step instructions for fixing the fixable ones.

Why It's Better Than PDFs

PDF manuals are designed for printing, not for finding information. When you're in the flow making music, you need quick answers, not a 144-page document to scroll through.

With Teenage Manual, you stay in the flow. Ask a question, get an answer, keep making music. No switching apps, no scrolling, no frustration. The manual is always there, always searchable, always ready. No need to download PDFs or remember where you saved them.

The most common questions people ask are things like "How do I make my first beat?" "What does the fader do?" "How do I sync with other devices?" These are basic questions that should be easy to answer. With PDFs, they're not. With Teenage Manual, they are.

Pro Features

The free version gives you full access to all manuals and unlimited questions. Pro features ($5/month) add voice input for when your hands are on the device, saved answers to reference later, YouTube context to use tutorial transcripts as context for questions, and synced chat history across devices.

The voice input is useful when you're working with hardware and your hands are busy.

Real-World Usage

Since launching, there have been 1,000+ users in the first week and 3,500+ questions asked. People are using Teenage Manual instead of Googling everything or scrolling through PDFs.

Check out the wall of love to see what users are saying.

Try It Yourself

If you own a Teenage Engineering device, give it a try. Go to your device's ask page - for example, EP-133 ask, OP-1 ask, OP-XY ask, or EP-1320 ask - and ask a question. Try "How do I make my first beat?" or "What are the tape tricks?" or "How do I sync with other devices?"

You'll get direct answers from the official manual, with proper button references and clear instructions. No scrolling, no guessing, no context switching.

If you're seeing an error code, check the error code pages. For EP-133 errors, EP-1320 errors, or EP-40 errors, you'll find what each code means and how to fix it.

What's Next

I'm planning to open source the manual processing so the community can contribute, add more devices as Teenage Engineering releases new products, improve the manual view with better organization and navigation, and add video tutorials to integrate YouTube tutorials as learning resources.

You can follow the changelog to see what's new.

Conclusion

Teenage Manual is the best way to access Teenage Engineering manuals. It's searchable, conversational, and actually usable. If you own a Teenage Engineering device, give it a try. Check out the pro page to see all the features.

Instead of scrolling through PDFs, you can ask questions and get direct answers from the official documentation. That's what makes it the best way to use Teenage Engineering manuals.

AI Deleted My Code: How to Recover

Ivan — Mon, 22 Dec 2025 14:07:22 +0000

It happens fast. You're iterating with Cursor or Claude Code, things are going well, and then the AI decides your codebase needs "cleaning up." Suddenly, files are gone. Maybe it consolidated what it thought were duplicates. Maybe it removed "unused" code that was actually imported elsewhere. Maybe it just hallucinated that a file shouldn't exist.

If you're reading this, it probably just happened to you. Let's get your code back, and then make sure it never happens again.

First: Don't Close Anything

Your editor likely still has deleted files in memory. Every tab you close is potential recovery lost. Keep everything open while you work through this.

Check Your Editor's Undo History

Start with the obvious. If the deleted file's tab is still open, try Ctrl+Z (or Cmd+Z on Mac) repeatedly. Sometimes the file content is recoverable even after the file itself was deleted from disk.

This doesn't always work, especially for files the AI deleted without opening, but it's worth trying first.

Use Local History

Both VS Code and Cursor maintain a local history of file changes that most developers don't know about. Press Ctrl+Shift+P (or Cmd+Shift+P), type "Local History: Find Entry to Restore", and browse for your deleted files.

This works even for files that were deleted, as long as they were edited at some point. It's saved me more times than I'd like to admit.

Check Your AI Tool's Recovery Features

If you're using Cursor, look for "Checkpoint created" messages in the Composer panel. Each prompt creates a checkpoint you can restore to. Click "Restore" next to the one from before the deletion.

For Claude Code, press Esc twice or type /rewind to open the checkpoint menu. You can restore just the code, just the conversation, or both.

The limitation with these is that they're tied to conversation context. If you've done a lot of work since the deletion, or if the deletion happened through Tab completions rather than Composer, you might not have a useful checkpoint.

Fall Back to Git

If you committed before the AI made its changes, Git is your friend:

git status           # See what's been deleted
git checkout .       # Restore everything to the last commit

If you didn't commit... well, that's the problem, isn't it? Git can only restore what you remembered to save.

When Nothing Works

If none of the above recovered your files, check your system backups. Time Machine on Mac, File History on Windows, or cloud sync services like Dropbox often keep recent versions. It's a long shot, but sometimes it works.

If you've exhausted all options and your code is truly gone, you've learned an expensive lesson about working with AI.

Preventing This Next Time

The fundamental problem is that AI agents are unpredictable. You can write better prompts, you can be more careful about reviewing diffs, but you can't eliminate the risk entirely. AI will occasionally delete things you didn't want deleted.

The solution is having recovery baked in, not bolted on.

Git works, but it requires discipline. You have to commit before every AI interaction, which breaks your flow when you're iterating quickly. And the one time you forget is the time the AI goes haywire.

This is why we built mrq. It watches your project directory and captures every file change automatically. No commits, no decisions, no interruptions. You just run mrq watch and forget about it.

When an AI deletes something:

mrq history        # See recent snapshots
mrq restore abc123 # Go back to any point

You're back to exactly where you were, even if you never committed. Even if the deletion happened three AI interactions ago. Every change is captured, every state is recoverable.

The reality of AI coding is that things break unexpectedly. The question is whether you're prepared when they do.

mrq captures every file change automatically while you code with AI. Set it once, recover instantly when things break.

Introducing Automatic Security Audits for AI

Ivan — Sat, 20 Dec 2025 18:09:47 +0000

AI coding assistants move fast. They can refactor modules, add dependencies, and wire up integrations before you've finished reading the diff. That speed is valuable, but security issues can slip in just as quickly: hardcoded API keys, string-concatenated SQL queries, debug endpoints that never get removed.

So we built something to help catch these issues early.

What It Does

mrq now scans your code changes for common security vulnerabilities automatically. Every snapshot triggers a background analysis looking for:

Hardcoded secrets, API keys, and credentials
SQL injection patterns
XSS vulnerabilities
Exposed sensitive data
Insecure configurations
Debug code that shouldn't ship

Results appear in your dashboard. If something gets flagged, you'll see a warning on that snapshot with details about what was found and where.

Issues are displayed inline with your snapshot history.

Why It Matters

Traditional security scanning happens in CI/CD, often hours after code was written. By then, the context is gone.

With mrq, feedback is immediate. You're still in the middle of your session when an issue gets flagged. You can fix it while everything is fresh.

Limitations

This is experimental. Security analysis is hard, and we're using AI to identify patterns. There will be false positives and false negatives. This is not a replacement for proper security audits, code review, or dedicated scanning tools in your pipeline.

Think of it as an early warning system. A nudge to double-check something before it gets committed.

Availability

Security audits are available on paid plans (Starter, Pro, Team). The feature runs automatically with no configuration needed.

Try it out →

How to Recover AI Coding Mistakes

Ivan — Fri, 19 Dec 2025 23:10:36 +0000

If you've spent any significant time coding with AI assistants, you've probably had that moment where something goes wrong. Maybe the AI overwrote a file you needed, or confidently refactored something in a way that broke half your tests, or went down a rabbit hole that left your codebase in a confusing state.

AI tools are genuinely useful for accelerating development. Their capability to make sweeping changes quickly can occasionally work against you though. Here's how we think about preventing and recovering from these situations.

The Recovery Problem

AI coding assistants can modify code in ways that are hard to track manually. A single prompt might touch a dozen files. The AI doesn't hesitate or ask for confirmation the way a human collaborator might. Changes happen fast, sometimes faster than you can review them.

AI assistants are actually quite capable and reliable for most tasks. The challenge is that their speed and confidence can outpace human review capacity, especially during longer sessions. You need a way to capture state continuously so you can always get back to where you were.

How mrq Handles This

We built mrq specifically for this workflow. It runs in the background while you work with AI assistants and automatically captures snapshots when meaningful changes happen. You don't need to think about version control during your session, just focus on the work.

Getting started is simple:

npm install -g mrq-cli@latest
mrq login
mrq watch --daemon

Once the daemon is running, every significant change to your codebase is captured automatically. You can see your snapshot history anytime:

$ mrq history

Recent Snapshots
────────────────────────────────────────────────────
  10:47:23  abc123  Added OAuth provider config and login route
                    +142 lines, -3 lines across 4 files

  10:43:51  def456  Refactored auth middleware to support JWT
                    +87 lines, -45 lines across 2 files

  10:41:02  ghi789  Fixed token validation edge case
                    +12 lines, -8 lines across 1 file

  10:38:15  jkl012  Initial auth module setup
                    +234 lines across 6 files
────────────────────────────────────────────────────

Each snapshot includes an AI-generated summary describing what changed, so you can quickly scan and find the point you want to return to.

Instant Recovery

When something goes wrong, recovery is a single command:

mrq restore def456

Your current state is automatically backed up before the restore, so if you change your mind, you can get back to where you were. There's no hunting through history or trying to remember when things last worked. You just pick a snapshot and restore.

The dashboard at dashboard.getmrq.com gives you a visual interface for browsing snapshots, comparing changes between any two points, and viewing the actual diffs. This is particularly helpful when you want to understand what the AI changed before deciding whether to restore.

Working Confidently with AI

The bigger benefit is psychological. When you know you can always recover, you're more willing to let the AI try ambitious things. Want to see if it can refactor your entire auth system? Go for it. If it doesn't work out, you're one command away from being back where you started.

This changes how you work with AI assistants. Instead of carefully scoping prompts to minimize risk, you can be more exploratory. Try the aggressive approach first. If it works, great. If not, restore and try something more conservative.

A Note on Git

You might wonder why not just use git for this. Git is excellent for deliberate, discrete commits with meaningful messages for collaboration and code review.

The challenge is that git requires intentional action to capture state. During rapid AI-assisted iteration, stopping to commit breaks your flow. Most developers either skip commits during these sessions (and lose their safety net) or create noisy checkpoint commits that clutter history.

mrq complements git. Use mrq for the messy exploration phase, then commit to git when you're happy with where things landed. You get continuous protection during development without sacrificing a clean git history for collaboration.

Getting Started

mrq is currently in open beta with a free tier that covers most individual developer needs. If you've experienced the frustration of losing AI-assisted work, or find yourself holding back on experiments because recovery feels uncertain, give it a try:

npm install -g mrq-cli@latest
mrq login  
mrq watch

We'd love to hear how it works for your workflow.

Build & Deploy AI-Powered Web Services from a Single Prompt

Ivan — Tue, 16 Jul 2024 17:29:32 +0000

At Shuttle, we've been working on a new tool that we think could change how developers approach AI integration. We're calling it ShuttleAI, and it allows you to build and deploy AI-powered web services from a single prompt.

Here's the TL;DR:

Describe your AI service in plain language

ShuttleAI generates a project spec for you to review

Approve or modify the spec

ShuttleAI creates the project files

You can prompt for changes or deploy

It's that simple. But let's dig into the details.

The Problem: AI Integration is Hard

If you've ever tried to integrate AI into a web service, you know it's not trivial. Here are some common challenges:

Complexity: AI frameworks often require specialized knowledge.
Time: Setting up AI services can take weeks or months.
Infrastructure: Managing AI models needs robust, scalable infrastructure.
Ongoing maintenance: AI services require continuous monitoring and updates.

These barriers can be significant, especially for smaller teams or developers new to the noisy AI space.

How ShuttleAI Works

ShuttleAI aims to simplify this process dramatically. Here's a step-by-step breakdown:

Describe Your Service: You provide a prompt describing the AI service you want to build. For example:

"Build a web service that takes weather forecast data and user profiles as input, then returns personalized weather recommendations."

Review the Spec: ShuttleAI generates a project specification document in markdown. This includes:
- API endpoints
- Data models
- AI model selection
- Infrastructure requirements
You can review and modify this spec as needed.
Generate Project Files: Once you approve the spec, ShuttleAI creates all necessary project files. This includes:
- Backend code (eg. Python with Flask)
- AI model integration code
- Infrastructure in the form of Infrastructure from Code
Iterative Refinement: You can prompt ShuttleAI to make changes at this stage. For example:
```
"Add rate limiting to the API endpoints"
```
ShuttleAI will update the project files accordingly.
Deploy: Once you're satisfied, ShuttleAI compiles and deploys your project on the Shuttle platform.

Use Cases

We're excited to see what developers will build with ShuttleAI. Here are a few ideas we've been thinking about:

Personalized Content Engines: Analyze user behavior and content metadata to provide tailored recommendations.
Intelligent Data Processing: Create services that clean, normalize, and enrich data using AI.
Natural Language Interfaces: Build APIs that can understand and respond to natural language queries.
Predictive Analytics Services: Develop APIs that forecast trends based on historical data.

Beta Testing and Early Access

ShuttleAI is still in development, and we're looking for beta testers. If you're interested in being one of the first to try it out, we're offering early access to the first 100 developers who sign up for our waitlist.

As a beta tester, you'll get:

Early access to ShuttleAI
Direct support from our development team
The opportunity to shape the future of the tool

Click here to sign up for early access!

What's Next?

We're continuously working on improving ShuttleAI. Some features we're exploring for future releases:

Support for more AI models and APIs
Advanced customization options for generated services
A marketplace for sharing and deploying AI service templates

We Want Your Feedback

ShuttleAI is still evolving, and we want to build it in a way that truly serves developers' needs. If you have ideas, questions, or concerns, we want to hear them.

Drop us a line at hello@shuttle.rs or open an issue in our GitHub repo.

Remember, the first 100 signups get early access to the beta. Don't miss out on the chance to shape the future of AI service development!

Click here to sign up for early access!

Rethinking Virtualization for Backends

Ivan — Thu, 27 Oct 2022 20:16:38 +0000

TLDR
Virtual machines and containers have improved backends in a lot of ways, but over time they have also created a lot of problems. We believe it's time to rethink how we use virtualization for backend development.

We're building a backend framework that shifts the scope of virtualization from processes down to service components.

In web applications nowadays, you can sort any component somewhere in a broad spectrum from client-side to server-side.

On the client-side, there's everything that runs on people's devices, most likely a browser or an app. On the server-side, there's everything that runs in the cloud. That includes databases, authentication management, batch jobs, events handling etc.

Each web framework squarely fits somewhere on that line. React, the most popular front-end web framework out there, is wholly client-side. Express, one of the most popular backend web frameworks, is wholly server-side.

Client-side has been historically dominated by JavaScript frameworks. This is not surprising since every client ships a powerful JavaScript engine and that is the best way to make a web page interactive.

On the server-side, things are more fragmented. This is also not surprising: backend services are just plain native processes that use their environment's network stack to respond to requests. And there is a world of different ways to write and run these: literally the history of computing.

As in many other scenarios in software engineering and computer science, this huge free space of options is also the cause of a lot of problems. To understand why, we need to talk about containers.

Containers are a solution and a problem

On its way to settling in its standards, the cloud - epitomized by AWS - has evolved massively over the past decade. My co-founder has written a post on this previously.

Today we, as software engineers, deal with it as it is: the result of incremental changes on top of a status quo. And it is not ideal.

What starts life as physical machines in a data center gets split up into tens, sometimes hundreds, of virtual machines in the AWS console. But VMs are heavy, slow to start and it's difficult to make a lot of them coexist without wasting resources like RAM and storage.

Then came along containers. Building on top of the Linux kernel's namespacing features, they made images smaller and runtimes more efficient than VMs. The genius of it is to move the virtualization layer from the hardware - where the kernel itself runs virtualized - to the software - where only processes run "virtualized". With containers, virtualized processes run natively in the host kernel, like any other. Except that their I/Os are carefully kept segregated from others in the host system. Any bit of compiled code that is executable on the host can be run in a container. And you can run processes in a container without a separate boot sequence and a full-fledged virtualized operating system with its own heavy machinery like a scheduler and dedicated virtualized hardware.

Containers are actually much older than a lot of people realise, going as far as 2008 with LXC in Linux’s case (even more in the case of FreeBSD). Their popularity, however, really took off with the arrival of Docker. The execution of Docker as a platform-as-a-service product was so good it took over software engineering practices for the following decade. And it is still the gold standard today in terms of usage.

Of course, companies were quick to build products on top of containers. They basically pass through the benefits of containers to their paying customers. Heroku is one of the most notable example. And while containers delivered most of us, directly or indirectly, from having to deal with VMs as a unit of deployment, they certainly have their issues. The biggest one being their size.

VMs have to run an entire operating system, containers don't. So they're quite a lot smaller. But container images still have to contain enough userspace to make the things you want to run actually runnable. For the way most people use them in deployments of web apps, this is generally still quite a lot!

The heavier your containers are, the more difficult everything else becomes. They take longer to build, they need more resources to run, they are more expensive to store, etc.

At shuttle we're convinced that a lot of the pains experienced by software engineers in the post-Docker world can be traced back to that very simple statement: containers are often too heavy for the job.

Replacing containers

You're probably thinking: it's nice and optimistic to say containers are too heavy, but what do you replace them with?

Well first, as an open-source company, you avoid making the same mistake Docker made. If you make the scope of virtualization too broad, you will end up with the same result as containers. The root cause behind the heavy weight of containers is that they have been built for too many usecases. They layer virtualization on top of all the I/Os of a native Linux process: their usecase is just about anything that runs.

We’re concerned with the backend services most people write. These are HTTP request/response handlers, with or without state. And for that specific usecase, most projects just end up worse off by handing over backend services as container images to their deployment platform of choice.

So we need to restrict the scope of virtualization to something more specific to web app backends. This is a trade-off of course, like most things in software engineering. By restricting the scope of a tool, you lose the ability to do certain things. But like most of these trade-offs, you usually are better served by erring on the side of simplicity unless you have specific needs that require extra complexity. In other words: use heavy machinery when you actually have a need for it, not before.

Where does that leave us then? We need a new take on virtualization. One that has, perhaps, simplified I/Os and is engineered for backend services. Thankfully, we don't have to invent most of that wheel: let's talk about WASI.

WASM and WASI

If WASM+WASI existed in 2008, we wouldn't have needed to created Docker. That's how important it is. Webassembly on the server is the future of computing. A standardized system interface was the missing link. Let's hope WASI is up to the task! https://t.co/wnXQg4kwa4
— Solomon Hykes (@solomonstre) March 27, 2019

WebAssembly (abbreviated WASM) is an instruction set for extremely lightweight virtual machines. Its most common use is to speed up client-side interactivity. This is made possible as popular browsers have rolled out WASM runtimes a few years back.

WASM is made for fast sandboxing. However, without any extension, it is unable to perform even simple I/O operations like reading data from a file descriptor. This is not a big deal if WASM is used in the browser - we definitely don't want to let browsers freely provide file system access to web apps. But it is a serious limitation if WASM is to be used server-side - how else are you going to serve endpoints without that?

Therefore, the introduction of WASM was followed, a short while later, by WASI - the WebAssembly System Interface. WASI is a standard API to give WASM code the ability to do system-level I/O. This allows WASM code running in a WASI-compliant runtime to do a lot of what a native process can do through syscalls.

The really powerful thing about WASM is that it is a very common compilation target. Major languages (and commonly associated frameworks) now support building WASM as a target, just the same way you build for amd64 or arm. And a lot of standard libraries have added support for WASI-based I/Os.

This is what Docker's founder had to say about WASI, back in 2019. And we agree with them. At the end of the day containers are, really, just I/O-level virtualization. Now, a few years after its initial introduction, WASM runtimes have stabilised their support of WASI. This creates a prime environment to engineer, on top of WASI, a solution to containers' biggest drawbacks.

Changing virtualization for backends

When we launched shuttle for its early alpha, back in March 2022, our purpose was to address the issues people face when building and deploying web app backends. So we created an open-source infrastructure-from-code platform with which you don’t need to write Containerfiles and orchestrate images, starting with support for Rust.

Since then, more than 1.2k people starred the shuttle repo and hundreds joined our discord community. And we've seen more than 2000 deployments and hundreds of users! From which we received a ton of feedback.

What we quickly realized is that while we simplified the process of getting started implementing your own backend and setting up its infrastructure, we completely failed to solve two core problems: long build and deploy times.

Rust has notoriously long build times (this probably has to do with static linking and heavy reliance on compile-time code generation). And while it supports incremental compilation out of the box, in a containerized environment, missing the cache for an image layer means having to rebuild from scratch.

We've found that no matter how much we tweaked our internal caching, too often users had to wait too long for their projects to build and deploy - something that can take minutes in the simplest projects, and closer to half an hour in complex ones. The reason was simple: our execution of our idea for shuttle is built on top of containers. And no matter how much we try to distance containers from our users, their limitations always surface back.

It was time for a complete rethink, so we took a radical view: let's start from the services people are writing, distilling what they need done quickly and easily. And let's make it our mission to optimize the hell out of the entire stack. We thought that if the execution of that idea is done right, it'd let us trim the dependency tree of services our users deploy and slim the runtime that every service ships with.

What we quickly realized is that while we trimmed down the process of getting started implementing your own backend and setting up its infrastructure, we completely failed to solve two core problems: long build and deploy times.

After all, a major culprit of these long build and deploy times in the real world is the large number of heavy dependencies of even simple projects. There's not much you can do about this: most services have a pretty big runtime that includes heavy machinery like an asynchronous executor (e.g. tokio), a web server (e.g. hyper), database drivers (e.g. sqlx) and more. And on every deploy you need to re-build them and hope artifact caches are hit in order to get an incremental build. And it's not just building either, the running time of tests is also impacted by this. The closure of the codebase you're engaging in those tests is very large indeed as it follows that of your dependencies.

This stuff materializes itself everywhere. Just try taking this hello world snippet:

use axum::{Router, routing::get};

async fn get_hello() -> &'static str {
    "You're slow, Heroku!"
}

#[tokio::main]
async fn main() {
    let port = std::env::var("PORT").unwrap();

    let router = Router::new()
        .route("/", get(get_hello))
        .into_make_service();

    hyper::Server::bind(&format!("127.0.0.1:{port}").parse().unwrap())
        .serve(router)
        .await
        .unwrap();
}

and deploy it to Heroku:

To try to address this, we wanted to move all these heavy dependencies to a common runtime across services. So your tokio, hyper, sqlx and co (in the case of Rust), now all belong to a long-lived containerized process running persistently in the cloud. Whereas all your service logic, database and endpoint code build into lightweight WASM modules that are dynamically loaded in-place by this global persistent process. That way "building" means compiling a very lightweight codebase with a small dependency footprint. And "deploying" means calling upon the control plane of that long-lived process to replace service components without rolling out new images, containers or VMs.

This leaves us with a trimmed down user-facing API that still uses familiar objects like PgClients and axum-style routes with guards:

Except that now the virtualization platform in which your services are run is responsible for instantiating these objects and calling these functions.

With this approach, the component of virtualization that you end up deploying on a daily basis is much smaller than traditional VMs and containers. In a way we can say this makes the virtualization layer more adapted to the specific needs of backend services running in the cloud. It's an optimized I/O surface between backend service components that change a lot (e.g. endpoint implementations) and their environing long-lived runtimes that don't (e.g. tokio/hyper/sqlx).

This results in "images" that are effectively up to 100x smaller because of the switch from container images to WASM binaries. And super fast to deploy too, from tens of minutes sometimes to less than a second all the time. All because when things are really incremental, you don't have to build and test a large codebase with its large userspace dependencies on every push. You just need to build and test the code you're writing and the changes you've made.

Our vision for this new way of doing backend development is shuttle-next: a next-generation backend framework with the fastest build, test and deployment times ever.

We believe that scoping down virtualization to the level of service components will eventually become the norm for backend development. In the same way we all think it's often not best to setup and start a VM only to run a single process, we will eventually all think it's misguided to build and start a container only to run a single service.

We are launching shuttle-next as part of our closed beta for shuttle later this month, with the public release coming soon after. If you’re keen to give it a try early, sign up for the beta! We'd love to know what you think!

In the meantime, check out shuttle's GitHub repo and Twitter for updates. If you’d like to support us, please star the repo and/or join the shuttle Discord community!

Create and Deploy a Discord bot in Rust, for free

Ivan — Thu, 15 Sep 2022 13:28:29 +0000

In this post, we will look at a simple way to add custom functionality to a Discord server using a bot written in Rust. We will first register a bot with Discord, then go about how to create a Serenity application that will later run on shuttle. Finally, we will make the bot do something useful, writing some Rust code to get information from an external service.

The full code can be found in this repository.

Registering our bot

Before we start making our bot, we need to register it for Discord. We do that by going to https://discord.com/developers/applications and creating a new application.

The application process is also used for adding functionality to Discord but we will be only using the bot offering. Fill in the basic details and you should get to the following screen:

You want to copy the Application ID and have it handy, because we will use it to add our bot to a test server.

Next, we want to create a bot. You can set its public username here:

You want to click the reset token and copy this value (we will use it in a later step). This value represents the username and password as a single value that Discord uses to authenticate that our server is the one controlling the bot. You want to keep this value secret.

You also want to tick the MESSAGE CONTENT INTENT setting so it can read the commands input.

To add the bot to the server we will test on, we can use the following URL (replace *application_id* in the URL with the ID you copied beforehand):

https://discord.com/oauth2/authorize?client_id=*application_id*&scope=bot&permissions=8

Here, we create it with permissions=8 so that it can do everything on the server. If you are adding to another server, select only the permissions it needs.

We now have a bot on our server:

Oh, they’re offline 😢

Getting a bot online

At this moment, our bot is not running because there is no code. We will have to write it and run it before we can start interacting with it.

Serenity

Serenity is a library for writing Discord bots (and communicating with the Discord API). We can create a new Serenity project which is readily deployable on shuttle with: cargo shuttle init --serenity

If you don’t have shuttle yet, you can install it with cargo install cargo-shuttle. Afterwards, run the following in an empty directory:

cargo shuttle init --serenity

After running it you, should see the following generated in src/lib.rs:

use log::{error, info};
use serenity::async_trait;
use serenity::model::channel::Message;
use serenity::model::gateway::Ready;
use serenity::prelude::*;
use shuttle_service::error::CustomError;
use shuttle_service::SecretStore;
use sqlx::PgPool;

struct Bot;

#[async_trait]
impl EventHandler for Bot {
    async fn message(&self, ctx: Context, msg: Message) {
        if msg.content == "!hello" {
            if let Err(e) = msg.channel_id.say(&ctx.http, "world!").await {
                error!("Error sending message: {:?}", e);
            }
        }
    }

    async fn ready(&self, _: Context, ready: Ready) {
        info!("{} is connected!", ready.user.name);
    }
}

#[shuttle_service::main]
async fn serenity(#[shared::Postgres] pool: PgPool) -> shuttle_service::ShuttleSerenity {
    // Get the discord token set in `Secrets.toml` from the shared Postgres database
    let token = pool
        .get_secret("DISCORD_TOKEN")
        .await
        .map_err(CustomError::new)?;

    // Set gateway intents, which decides what events the bot will be notified about
    let intents = GatewayIntents::GUILD_MESSAGES | GatewayIntents::MESSAGE_CONTENT;

    let client = Client::builder(&token, intents)
        .event_handler(Bot)
        .await
        .expect("Err creating client");

    Ok(client)
}

Building an interaction for our bot

We want to call our bot when chatting in a text channel. Discord enables this with slash commands.

Slash commands can be server-specific (servers are named as guilds in Discords API documentation) or application specific (across all servers the bot is in). For testing, we will only enable it on a single guild/server. This is because the application-wide commands can take an hour to fully register whereas the guild/server specific ones are instant, so we can test the new commands immediately.

You can copy the guild ID by right-clicking here on the server name and click copy ID (you will need developer mode enabled to do this):

Now that we have the information for setup, we can start writing our bot and its commands.

We will first get rid of the async fn message hook as we won’t be using it in this example. In the ready hook we will call set_application_commands with a GuildId to register a command with Discord. Here we register a hello command with a description and no parameters (Discord refers to these as options).

#[async_trait]
impl EventHandler for Bot {
    async fn ready(&self, ctx: Context, ready: Ready) {
        info!("{} is connected!", ready.user.name);

        let guild_id = GuildId(*your guild id*);

        let commands = GuildId::set_application_commands(&guild_id, &ctx.http, |commands| {
            commands.create_application_command(|command| { command.name("hello").description("Say hello") })
        }).await.unwrap();

        info!("{:#?}", commands);
    }
}

Serenity has a bit of a different way of registering commands using a callback. If you are working on a larger command application, poise (which builds on Serenity) might be better suited.

With our command registered, we will now add a hook for when these commands are called using interaction_create.

#[async_trait]
impl EventHandler for Bot {
    async fn ready(&self, ctx: Context, ready: Ready) {
        // ...
    }

    async fn interaction_create(&self, ctx: Context, interaction: Interaction) {
        if let Interaction::ApplicationCommand(command) = interaction {
            let response_content = match command.data.name.as_str() {
                "hello" => "hello".to_owned(),
                command => unreachable!("Unknown command: {}", command),
            };

            let create_interaction_response =
                command.create_interaction_response(&ctx.http, |response| {
                    response
                        .kind(InteractionResponseType::ChannelMessageWithSource)
                        .interaction_response_data(|message| message.content(response_content))
                });

            if let Err(why) = create_interaction_response.await {
                eprintln!("Cannot respond to slash command: {}", why);
            }
        }
    }
}

Trying it out

Now with the code written we can test it locally. Before we do that we have to authenticate the bot with Discord. We do this with the value we got from "Reset Token" on the bot screen in one of the previous steps. To register a secret with shuttle we create a Secrets.toml file with a key value pair. This pair is read by the pool.get_secret("DISCORD_TOKEN") call in the ready hook:

# Secrets.toml
DISCORD_TOKEN="*your discord token*"
DISCORD_GUILD_ID="*the guild we are testing on*"

Currently secrets are stored using shuttle's database Postgres offering (thus why the parameter on main is PgPool). Therefore during local testing you need access to a Postgres database. Shuttle's local runner does this using Docker which will require Docker desktop being locally installed to use the Secrets locally. This is is subject to change in the future so that it doesn't require Docker for local secrets. There is also a known issue with deploying Secrets on Windows so if you have problems consult the Discord.

cargo shuttle run

We should see that our bot now displays as online:

When typing, we should see our command come up with its description:

Our bot should respond with "hello" to our command:

Wow! Let’s make our bot do something a little more useful.

Making the bot do something

There is plenty of free APIs that can be used for getting information on a variety of topics.

For this demo, we are going to build a bot that gives a forecast for a location. I used the AccuWeather API for this demo. If you are following this tutorial 1:1 you can go and register an application to get an access key. If you are using a different API this is still the sort of process you would follow.

To get a forecast using the API requires two requests:

Get a location ID for a named location
Get the forecast at the location ID

The API requires making network requests and it returns a JSON response. We can make the requests with cargo add reqwest -F json and deserialize the results to structures using serde, with cargo add serde. We will then have a function that chains the two requests together and deserializes the forecast to a readable result.

You can skip some of the boilerplate by using direct access on untyped values. But we will opt for the better strongly typed structured approach.

Here we type some of the structures returned by the API and add #[derive(Deserialize)] so they can be decoded from JSON. All the keys are in PascalCase so we use the #[serde(rename_all = "PascalCase")] helper attribute to stay aligned with Rust standards. Some are completely different from the Rust field name so we use #[serde(alias = ...)] on the field to set its matching JSON representation.

// In weather.rs
use serde::Deserialize;

#[derive(Deserialize, Debug)]
#[serde(rename_all = "PascalCase")]
pub struct Location {
    key: String,
    localized_name: String,
    country: Country,
}

impl Display for Location {
    fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
        write!(f, "{}, {}", self.localized_name, self.country.id)
    }
}

#[derive(Deserialize, Debug)]
pub struct Country {
    #[serde(alias = "ID")]
    pub id: String,
}

#[derive(Deserialize, Debug)]
#[serde(rename_all = "PascalCase")]
pub struct Forecast {
    pub headline: Headline,
}

#[derive(Deserialize, Debug)]
pub struct Headline {
    #[serde(alias = "Text")]
    pub overview: String,
}

The above skips a lot of the fields returned by the API, only opting for the ones we will use in this demo. If you wanted to type all the fields you could try the new type from JSON feature in rust-analyzer to avoid having to write as much.

Our location request call also fails if the search we put in returns no places. We will create an intermediate type that represents this case and implements std::error::Error:

// Again in weather.rs
use std::fmt::Display;

#[derive(Debug)]
pub struct CouldNotFindLocation {
    place: String,
}

impl Display for CouldNotFindLocation {
    fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
        write!(f, "Could not find location '{}'", self.place)
    }
}

impl std::error::Error for CouldNotFindLocation {}

Now with all the types written, we create a new async function that, given a place and a client, will return the forecast along with the location:

// Again in weather.rs
pub async fn get_forecast(
    place: &str,
        api_key: &str,
    client: &Client,
) -> Result<(Location, Forecast), Box<dyn std::error::Error>> {
        // Endpoints we will use
    const LOCATION_REQUEST: &str = "http://dataservice.accuweather.com/locations/v1/cities/search";
    const DAY_REQUEST: &str = "http://dataservice.accuweather.com/forecasts/v1/daily/1day/";

        // The URL to call combined with our API_KEY and the place (via the q search parameter)
    let url = format!("{}?apikey={}&q={}", LOCATION_REQUEST, api_key, place);
        // Make the request we will call
    let request = client.get(url).build().unwrap();
        // Execute the request and await a JSON result that will be converted to a
        // vector of locations
    let resp = client
        .execute(request)
        .await?
        .json::<Vec<Location>>()
        .await?;

        // Get the first location. If empty respond with the above declared
        // `CouldNotFindLocation` error type
    let first_location = resp
        .into_iter()
        .next()
        .ok_or_else(|| CouldNotFindLocation {
            place: place.to_owned(),
        })?;

        // Now have the location combine the key/identifier with the URL 
    let url = format!("{}{}?apikey={}", DAY_REQUEST, first_location.key, api_key);

        let request = client.get(url).build().unwrap();
    let forecast = client
        .execute(request)
        .await?
        .json::<Forecast>()
        .await?;

        // Combine the location with the foreact
    Ok((first_location, forecast))
}

Now we have a function to get the weather, given a reqwest client and a place, we can wire that into the bots logic.

Setting up the reqwest client

Our get_forecast requires a reqwest Client and the weather API key. We will add some fields to our bot for holding this data and initialize this in the shuttle_service::main function. Using the secrets feature we can get our weather API key:

// In lib.rs
struct Bot {
    weather_api_key: String,
    client: reqwest::Client,
        discord_guild_id: GuildId,
}

#[shuttle_service::main]
async fn serenity(#[shared::Postgres] pool: PgPool) -> shuttle_service::ShuttleSerenity {
    // Get the discord token set in `Secrets.toml` from the shared Postgres database
    let token = pool
        .get_secret("DISCORD_TOKEN")
        .await
        .map_err(CustomError::new)?;

    let weather_api_key = pool
        .get_secret("WEATHER_API_KEY")
        .await
        .map_err(CustomError::new)?;

        let discord_guild_id = pool
        .get_secret("DISCORD_GUILD_ID")
        .await
        .map_err(CustomError::new)?;

    // Set gateway intents, which decides what events the bot will be notified about
    let intents = GatewayIntents::GUILD_MESSAGES | GatewayIntents::MESSAGE_CONTENT;

    let client = Client::builder(&token, intents)
        .event_handler(Bot {
            weather_api_key,
            client: reqwest::Client::new(),
                        discord_guild_id: GuildId(discord_guild_id.parse().unwrap())
        })
        .await
        .expect("Err creating client");

    Ok(client)
}

Registering a /weather command

We will add our new command with a place option/parameter. Back in the ready hook, we can add an additional command alongside the existing hello command:

let commands = GuildId::set_application_commands(&guild_id, &ctx.http, |commands| {
    commands
        .create_application_command(|command| { command.name("hello").description("Say hello") })
        .create_application_command(|command| {
            command
                .name("weather")
                .description("Display the weather")
                .create_option(|option| {
                    option
                        .name("place")
                        .description("City to lookup forecast")
                        .kind(CommandOptionType::String)
                        .required(true)
                })
        })
}).await.unwrap();

Discord allows us to set the expected type and whether it is required. Here, the place needs to be a string and is required.

Now in the interaction handler, we can add a new branch to the match tree. We pull out the option/argument corresponding to place and extract its value. Because of the restrictions made when setting the option we can assume that it is well-formed (unless Discord sends a bad request) and thus the unwraps here. After we have the arguments of the command we call the get_forecast function and format the results into a string to return.

"weather" => {
    let argument = command
        .data
        .options
        .iter()
        .find(|opt| opt.name == "place")
        .cloned();

    let value = argument.unwrap().value.unwrap();
    let place = value.as_str().unwrap();
    let result = weather::get_forecast(place).await;        

    match result {
        Ok((location, forecast)) => format!(
            "Forecast: {} in {}",
            forecast.headline.overview, location
        ),
        Err(err) => {
            format!("Err: {}", err)
        }
    }
}

Running

Now, we have these additional secrets we are using and we will add them to the Secrets.toml file:

# In Secrets.toml
# Existing secrets:
DISCORD_TOKEN="***"
DISCORD_GUILD_ID="***"
# New secret
WEATHER_API_KEY="***"

With the secrets added, we can run the server:

cargo shuttle run

While typing, we should see our command come up with the options/parameters:

Entering “Paris” as the place we get a result with a forecast:

And entering a location that isn’t registered returns an error, thanks to the error handling we added to the get_forecast function:

Deploying on shuttle

With all of that setup, it is really easy to get your bot hosted and running without having to run your PC 24/7.

Just write:

cargo shuttle deploy

And you are good to go. Easy-pease, right?

You could now take this idea even further:

Use a different API, to create a bot that can return funny facts or return new spaceflights
Maybe you could use one of shuttle's provided databases to remember certain information about a user
Expand on the weather forecast idea by adding more advanced options and follow-ups to command options
Use the localization information to return information in other languages

This blog post is powered by shuttle! If you have any questions, or want to provide feedback, join our Discord server!

Shuttle: The Rust-native, open source, cloud development platform.
Deploying and managing your Rust web apps can be an expensive, anxious and time consuming process.

If you want a batteries included and ops-free experience, try out Shuttle.