Blog

What Is MCP? The Model Context Protocol Explained for Web Developers

Feb 7, 2026

Brenn Hill

MCP — the Model Context Protocol — is the USB-C of AI tools. It’s a standard that lets AI assistants plug into external data sources and capabilities without custom integrations. If you’ve ever wished your AI coding assistant could see your browser, read your database, or check your CI pipeline, MCP is how that works.

Here’s what MCP means for web developers and why it changes how you build software.

The Problem MCP Solves

AI coding assistants are powerful but blind. They can read your source code, but they can’t see:

The runtime error in your browser console
The 500 response from your API
The layout shift that happens after your component mounts
The WebSocket connection that silently drops
The third-party script that’s loading slowly

Without this context, every debugging session starts with you describing the problem to the AI instead of the AI observing it directly. You become a human copy-paste bridge between your browser and your terminal.

MCP eliminates that bridge.

How MCP Works

MCP is a JSON-RPC 2.0 protocol with a simple contract:

Servers expose tools (functions the AI can call) and resources (data the AI can read)
Clients (AI assistants like Claude Code, Cursor, Windsurf) discover and invoke those tools
Transport is flexible — stdio pipes, HTTP, or any bidirectional channel

A typical MCP server might expose tools like:

observe({what: "errors"})        → returns browser console errors
generate({format: "test"})       → generates a Playwright test
configure({action: "health"})    → returns server status
interact({action: "click", selector: "text=Submit"})  → clicks a button

The AI assistant discovers what tools are available, reads their descriptions, and calls them as needed during a conversation. No custom plugin architecture. No vendor-specific API. Just a protocol.

Why MCP Matters for Web Development

Your AI Can See What You See

Before MCP, debugging with AI looked like this:

You: “I’m getting an error when I submit the form.” AI: “What error? Can you paste the console output?” You: [switches to browser, opens DevTools, copies error, pastes] AI: “Can you also show me the network request?” You: [switches to Network tab, finds request, copies, pastes]

With an MCP server like Gasoline connected:

You: “I’m getting an error when I submit the form.” AI: [calls observe({what: “errors”})] “I can see the TypeError. The API returned a 422 because the email field is missing from the request body. Let me check the form handler…”

The AI skips the back-and-forth and goes straight to diagnosing.

Tool Composition

MCP tools compose naturally. An AI assistant with a browser MCP server and a filesystem MCP server can:

Observe a runtime error in the browser
Read the relevant source file
Edit the code to fix the bug
Refresh the browser
Verify the error is gone

That’s a complete debugging loop without human intervention beyond the initial request.

Works With Any AI Tool

Because MCP is a standard protocol, the same server works with every compatible client:

AI Tool	MCP Support
Claude Code	Built-in
Cursor	Built-in
Windsurf	Built-in
Claude Desktop	Built-in
Zed	Built-in
VS Code + Continue	Plugin

You configure the server once. Every AI tool that speaks MCP can use it.

The MCP Ecosystem

MCP servers exist for many data sources:

Category	Examples
Browser	Gasoline (real-time telemetry, browser control)
Filesystem	Read, write, search files
Databases	PostgreSQL, SQLite, MongoDB
APIs	GitHub, Slack, Jira, Linear
DevOps	Docker, Kubernetes, CI/CD
Search	Brave Search, web fetch

The power comes from combining them. A browser MCP server plus a GitHub MCP server means your AI can observe a bug, fix it, and open a PR — all in one conversation.

What Makes a Good Browser MCP Server

Not all browser MCP servers are equal. The critical capabilities for web development:

Real-Time Observability

The server should capture browser state as it happens — console logs, network errors, exceptions, WebSocket events — not just static snapshots. When you’re debugging a race condition, you need the sequence of events, not a point-in-time dump.

Browser Control

Observation alone isn’t enough. The AI needs to navigate, click, type, and interact with the page. Otherwise it’s reading but not testing. Semantic selectors (text=Submit, label=Email) are more resilient than CSS selectors that break with every redesign.

Artifact Generation

Captured session data should translate into useful outputs: Playwright tests, reproduction scripts, accessibility reports, performance summaries. The AI has the data — let it produce the artifacts.

Security by Design

A browser MCP server sees everything — network traffic, form inputs, cookies. It must:

Strip credentials before storing or transmitting data
Bind to localhost only (no network exposure)
Minimize permissions (no broad host access)
Keep all data on the developer’s machine

Performance Awareness

Web Vitals, resource timing, long tasks, layout shifts — performance data should flow alongside error data. The AI shouldn’t need a separate tool to check if the page is fast.

Getting Started with MCP

If you want to add browser observability to your AI workflow:

1. Install the Extension

git clone https://github.com/brennhill/gasoline-mcp-ai-devtools.git

Load the extension/ folder as an unpacked Chrome extension.

2. Configure Your AI Tool

Add to your MCP config (example for Claude Code’s .mcp.json):

{
  "mcpServers": {
    "gasoline": {
      "command": "npx",
      "args": ["-y", "gasoline-mcp"]
    }
  }
}

3. Start Debugging

Open your app, restart your AI tool, and ask:

“What browser errors do you see?”

The AI calls observe({what: "errors"}), gets the real-time error list, and starts diagnosing. No copy-paste. No screenshots. No description of the problem. The AI sees it directly.

The Bigger Picture

MCP is still early. The protocol is evolving, new servers appear weekly, and AI tools are deepening their integration. But the direction is clear: AI assistants are becoming aware of their environment, not just their context window.

For web developers, this means the feedback loop between writing code and seeing results gets tighter. The AI sees the browser. The AI sees the error. The AI sees the fix work. All in real time.

That’s what MCP enables. And it’s just getting started.

Why AI-Native Software Development Is the Future

Feb 7, 2026

Brenn Hill

Software development is shifting from human-driven to AI-native. Tools built for AI agents — not adapted for them — will define the next era of engineering productivity.

Three Eras of Developer Tools

Era 1: Manual. Developers wrote code in text editors, debugged with print statements, and deployed by copying files to servers. The tools were simple because the human did most of the work.

Era 2: Assisted. IDEs added autocomplete, debuggers added breakpoints, CI systems automated testing. The tools got smarter, but the human was still driving.

Era 3: AI-native. AI agents write code, debug issues, run tests, and deploy changes. The tools are designed for agents as the primary user, with humans supervising and directing.

We’re at the transition between Era 2 and Era 3. Most tools today are Era 2 tools with AI bolted on — an IDE that can call an LLM, a debugger that can explain an error. They work, but they’re limited by interfaces designed for humans.

AI-native tools are different. They’re built from the ground up for machine consumption — structured data instead of visual interfaces, autonomous operation instead of click-by-click interaction, continuous capture instead of on-demand inspection.

What “AI-Native” Means

An AI-native tool is designed with the assumption that its primary user is an AI agent, not a human.

Characteristic	Human-native tool	AI-native tool
Interface	Visual (GUI, dashboard)	Structured (JSON, API)
Data capture	On-demand (open DevTools, look)	Continuous (always capturing)
Query model	Navigate menus, click tabs	Declarative queries with filters
Error context	Stack trace on screen	Error + network + actions + timeline bundled
Interaction	Mouse and keyboard	Semantic selectors and tool calls
Scaling	One human, one screen	One agent, unlimited parallel queries

Chrome DevTools is a human-native tool. It shows data visually, requires clicking through tabs, and captures data only while you’re looking at it. If an error happened before you opened DevTools, it’s gone.

Gasoline is an AI-native tool. It captures everything continuously, stores it in queryable ring buffers, and serves it through structured MCP tool calls. The AI doesn’t need to “look” at the right moment — the data is already there.

Why This Matters Now

AI coding agents are getting better fast. Claude, GPT, Gemini — they can write functions, fix bugs, refactor code, and understand architecture. But they’re bottlenecked by context.

An AI agent that can only see your source code is like a mechanic who can only read the manual. Give them the manual and the ability to hear the engine, see the dashboard, and turn the steering wheel, and they can actually diagnose and fix the problem.

Browser telemetry is that missing context. When an AI can see:

What errors the browser is throwing
What the network requests look like
What the WebSocket messages contain
What the page looks like visually
How the user interacted with the app

…it can go from “I think the bug might be in the auth handler” to “The auth handler returns 200 but with a null user object because the session expired between the WebSocket reconnect and the API call.”

The AI doesn’t guess. It observes, reasons, and acts — because the tools give it the data it needs.

Adapted vs. Native

Most browser debugging tools today are adapted — human-native tools with an MCP wrapper. They take Chrome DevTools Protocol, expose it through MCP, and hope the AI can work with it.

The problem with adaptation:

CDP was designed for DevTools UI. It assumes a human is navigating panels and clicking through tabs. An AI gets a firehose of unfiltered data.
On-demand capture misses context. If the error happened before the AI connected, it’s gone. Human-native tools assume someone is watching.
No semantic structure. CDP returns raw protocol data. The AI has to interpret Chrome-internal formats instead of working with structured, meaningful data.

AI-native tools are designed differently:

Continuous capture. Data is buffered from the moment the page loads. When the AI asks “what errors happened?”, the answer is always there.
Pre-assembled context. Error bundles include the error, the network calls around it, the user actions that triggered it, and the console logs — all correlated and packaged for the AI.
Semantic interaction. Instead of “click the element at position (423, 187)” or “click #root > div > button:nth-child(3)”, the AI says click text=Submit. The tool resolves the selector.
Declarative queries. Instead of “subscribe to the Network domain, enable, wait for requestWillBeSent”, the AI says observe({what: "network_bodies", url: "/api/users", status_min: 400}).

The Development Cycle Accelerates

When tools are AI-native, the development cycle gets shorter at every stage:

Debugging

Before: Developer opens DevTools, reproduces the bug, reads the console, checks the network tab, copies the error into the AI, explains the context, gets a suggestion, tries it, checks again.

After: AI observes the browser continuously, sees the error with full context, identifies the root cause, writes the fix, verifies it works — while the developer reviews the PR.

Testing

Before: Engineer writes Playwright tests, maintains selectors, debugs flaky tests, updates tests when UI changes, runs CI, reads test output.

After: Product manager writes test in natural language. AI executes it against the live app with semantic selectors. Tests break only when product behavior changes.

Demos

Before: Engineer scripts the demo, rehearses, recovers from mistakes, rebuilds for each audience.

After: Anyone writes a natural language demo script. AI drives the browser with narration. Replay anytime.

Monitoring

Before: Set up Datadog/Sentry/LogRocket, configure alerts, read dashboards, correlate events manually.

After: AI continuously observes the browser, catches regressions in real time, correlates errors with network failures and user actions automatically.

What Comes Next

The shift to AI-native development tools is just starting. Here’s what the trajectory looks like:

Now: AI agents use MCP tools to observe and interact with browsers. Humans write prompts and review results.

Next: AI agents chain multiple tools autonomously — observe a bug, write a fix, run the tests, generate a PR summary, request review. The human reviews the outcome, not the process.

Eventually: AI agents maintain entire product surfaces — monitoring production, catching regressions, generating fixes, deploying safely, and escalating only when human judgment is needed.

Each step requires tools that are designed for autonomous operation. Tools that capture data continuously, expose it structurally, and enable interaction programmatically.

Building for the Agent Era

Gasoline was built AI-native from day one. Not “DevTools with an MCP wrapper.” Not “Selenium but the AI types the commands.” A tool designed for agents:

Four tools, not forty. The AI picks the tool and the mode. No sprawling API to navigate.
Continuous capture. Data is always there. The AI never misses context.
Structured output. JSON responses with typed fields. No parsing HTML or reading screenshots to understand data.
Semantic interaction. text=Submit instead of #root > div > button:nth-child(3).
Zero setup. Single binary, no runtime, no configuration. The AI’s environment starts clean.

The future of software development isn’t “humans using AI tools.” It’s “AI agents using AI-native tools, supervised by humans.” The tools you choose now determine whether you’re building for that future or maintaining for the past.

Why Chrome DevTools MCP Isn't Enough

Feb 7, 2026

Brenn Hill

Chrome DevTools MCP was a great first step. But it doesn’t capture WebSockets, can’t handle distributed apps, breaks on advanced frameworks, and slows down the development cycle it was supposed to accelerate.

Credit Where It’s Due

Chrome DevTools MCP proved something important: AI agents are dramatically better when they can see the browser. That insight changed how developers think about AI-assisted development.

But the implementation has fundamental limitations that surface quickly in real-world projects. If you’ve tried using DevTools MCP on anything beyond a simple SPA, you’ve probably hit them.

Problem 1: The Debug Port Kills Your Security

Chrome DevTools MCP requires launching Chrome with --remote-debugging-port. This flag:

Disables Chrome’s security sandboxing. The sandbox is Chrome’s primary defense against malicious websites. Turning it off means any site you visit during development can access more of your system.
Exposes a network port. Port 9222 accepts remote connections. On a shared network (office, coffee shop, conference WiFi), that’s an attack surface.
Breaks your normal browser. You need a special browser launch. Your extensions, bookmarks, and sessions from your regular Chrome instance aren’t there. You’re working in an unfamiliar environment.

Gasoline uses a standard Chrome extension (Manifest V3). No special launch flags. No exposed ports. Your browser stays secure, and you work in your normal environment with your normal sessions.

Problem 2: WebSockets Are Invisible

Modern applications are real-time. Chat apps, collaborative editors, dashboards, notification systems, trading platforms — they all use WebSockets.

Chrome DevTools MCP doesn’t capture WebSocket messages.

That means your AI can’t see:

What the server is pushing to the client
Out-of-order messages causing state corruption
Payload format mismatches (server sends txt, client expects text)
Connection drops and failed reconnections
Authentication token expiration on long-lived connections

With Gasoline:

observe({what: "websocket_status"})    // Active connections
observe({what: "websocket_events"})    // Message stream

Every frame, every direction, every connection — captured automatically and queryable by your AI.

Problem 3: Distributed Applications Break It

Real applications aren’t one tab. They’re:

A customer app that talks to an admin panel that reads from a shared API
A web app that authenticates via an OAuth provider and fetches data from a third-party service
A frontend that sends events to a message queue that triggers a background worker that updates a dashboard

Chrome DevTools MCP gives you one browser tab’s console output. It has no concept of cross-tab workflows, multi-service architectures, or the network calls that tie them together.

Gasoline captures the full picture:

Network bodies show exactly what your app sent and what the API returned
WebSocket events show real-time communication between services
Multi-tab awareness means you can observe activity across tabs
Timeline interleaves all events chronologically, so you see the full distributed flow

When your AI can see that Tab A’s API call returned a stale token, which caused Tab B’s WebSocket to disconnect, which triggered the error the user reported — that’s when debugging gets fast.

Problem 4: It Fails on Constantly Changing UIs

Development moves fast. The UI changes every sprint — new components, renamed classes, restructured layouts. DevTools MCP gives your AI console logs and a DOM snapshot. The AI has to ask you what changed and guess at selectors.

Gasoline’s interact tool uses semantic selectors that adapt:

interact({action: "click", selector: "text=Submit"})
interact({action: "type", selector: "label=Email", text: "user@example.com"})
interact({action: "list_interactive"})  // Discover all elements

When the UI changes, text=Submit still finds the submit button. label=Email still finds the email field. And if the AI is unsure, it calls list_interactive to get a full inventory of every clickable and typeable element on the page.

DevTools MCP can’t interact with the page at all. Gasoline lets the AI click, type, navigate, and verify — the full development cycle in one tool.

Problem 5: It Doesn’t Actually Accelerate Development

The promise of browser MCP tools is faster development cycles. But DevTools MCP only gives the AI some of the data. The developer still has to:

Copy-paste error details the AI can’t see
Describe the visual state (“the button is greyed out”)
Manually check network responses
Explain the WebSocket behavior
Reproduce the issue step by step

You’re still the bottleneck. You’re still shuttling context between the browser and the AI.

Gasoline gives the AI everything:

Data	DevTools MCP	Gasoline
Console errors	Yes	Yes, with deduplication and clustering
Network requests	Partial	Full bodies, filtered by URL/status
WebSocket messages	No	Full capture with filtering
Screenshots	No	Yes
User actions	No	Recorded automatically
Web Vitals	No	LCP, CLS, INP, FCP with regression detection
Accessibility	No	WCAG audits
API schemas	No	Auto-inferred from traffic
Page interaction	No	Click, type, navigate, verify

When the AI has the full picture, it doesn’t need you to be the intermediary. It observes, diagnoses, and fixes — at the speed of API calls, not the speed of copy-paste.

Problem 6: Production Dependencies and Supply Chain Risk

Chrome DevTools MCP and BrowserTools MCP require Node.js and npm packages. That’s:

A runtime dependency (Node.js must be installed)
Package manager overhead (npm/yarn, lock files, version conflicts)
Supply chain exposure (every dependency is a potential vulnerability)

Gasoline is a single Go binary. Zero production dependencies. No node_modules. No supply chain risk.

npx gasoline-mcp  # Downloads single binary, runs it

The Real Problem DevTools MCP Doesn’t Solve

The bottleneck in modern development isn’t “the AI can’t see console errors.” It’s “the AI can’t see enough to work autonomously.”

DevTools MCP gives the AI a partial view — console output and DOM snapshots. That’s better than nothing, but it still leaves the developer as the primary context provider.

Gasoline gives the AI a complete view — errors, network, WebSockets, performance, accessibility, visual state, and browser control. The AI becomes a full participant in the development cycle: observe the bug, understand the context, interact with the app, verify the fix.

That’s the difference between “AI that helps you debug” and “AI that debugs.”

Side-by-Side Summary

	Chrome DevTools MCP	Gasoline MCP
Setup	`--remote-debugging-port` flag	Standard extension
Security	Sandbox disabled	Full sandbox preserved
Console errors	Yes	Yes + dedup + clustering + bundles
Network bodies	No	Full request/response capture
WebSocket	No	Full capture and filtering
Browser control	No	Click, type, navigate, verify
Screenshots	No	Yes
Web Vitals	No	LCP, CLS, INP, FCP
Accessibility	No	WCAG audits + SARIF export
Test generation	No	Playwright tests from sessions
Multi-client	Single connection	Unlimited concurrent clients
Dependencies	Node.js + npm	Zero (single Go binary)
Privacy	Local	Local, 127.0.0.1 only
Overhead	~5ms per intercept	< 0.1ms per intercept

Chrome DevTools MCP was the right idea at the right time. Gasoline is what comes next.

Why Gasoline Is Written in Go

Feb 7, 2026

Brenn Hill

Go was chosen for Gasoline’s MCP server because it compiles to a single binary, has zero runtime dependencies, and doesn’t rot. Here’s why that matters for a developer tool you depend on daily.

The Code Rot Problem

You clone a Node.js project from last year. You run npm install. It fails. A dependency broke. You update it. Now another dependency is incompatible. You spend an hour fixing a project that worked perfectly 12 months ago.

This is code rot — software that degrades not because its logic changed, but because the ecosystem around it shifted.

In the JavaScript ecosystem, code rot is constant. The average npm package has 79 transitive dependencies. Each one is a ticking clock — an author who might yank the package, a breaking change in a minor version, a deprecated API, a CVE that forces an urgent update.

Gasoline doesn’t have this problem. It has zero production dependencies.

What Zero Dependencies Means

Gasoline’s Go server imports nothing outside the Go standard library. No HTTP frameworks. No logging libraries. No JSON-RPC packages. No ORMs.

import (
    "encoding/json"
    "fmt"
    "net/http"
    "os"
    "sync"
)

That’s it. Everything Gasoline does — HTTP serving, JSON-RPC 2.0, ring buffers, cursor pagination, file persistence, rate limiting, multi-client bridging — is built on Go’s standard library.

What this means in practice:

No go.sum file to audit. There are no third-party dependencies to check for vulnerabilities.
No supply chain attacks. You can’t compromise what doesn’t exist.
No version conflicts. No “package X requires Y v2 but Z requires Y v1.”
No breaking updates. Go’s compatibility guarantee means code written for Go 1.21 compiles on Go 1.25.

Single Binary Distribution

go build produces a single executable. No runtime required. No interpreter. No virtual machine.

When you run npx gasoline-mcp, it downloads a pre-compiled binary for your platform and runs it. There’s no:

npm install (no node_modules)
pip install (no Python environment)
go install (no Go toolchain needed)
.jar files (no JVM)

One binary. It runs. That’s the deployment story.

Compare this to tools built on Node.js:

	Node.js MCP Server	Gasoline (Go)
Runtime required	Node.js 18+	None
Package manager	npm/yarn/pnpm	None
Dependencies	Dozens to hundreds	Zero
Install time	10-60 seconds	< 2 seconds (binary download)
Disk footprint	50-200 MB (node_modules)	~15 MB (single binary)
Cold start	500ms-2s (require/import resolution)	300-400ms
CVE exposure	Every dependency	Go stdlib only

Go’s Compatibility Guarantee

Go has a forward compatibility guarantee: code written for Go 1.x compiles on all future 1.x versions. This guarantee has held since Go 1.0 in 2012.

In practice, this means:

Code written today compiles in 5 years without changes
No “upgrade to the latest framework version” treadmill
No deprecation warnings that become errors in the next release
No migration guides to follow every 18 months

For a developer tool that people depend on daily, this stability is a feature, not a constraint.

Performance That Comes Free

Go compiles to native machine code. There’s no interpreter overhead, no JIT warmup, no garbage collection pauses that matter at Gasoline’s scale.

Gasoline’s performance targets:

Metric	Target	Why Go helps
Console intercept overhead	< 0.1ms	No runtime startup per request
HTTP endpoint latency	< 0.5ms	`net/http` is battle-tested and fast
Cold start	< 600ms	Static binary, no dependency resolution
Concurrent clients	500+	Goroutines are cheap (~2KB stack each)
Memory under load	Predictable	Ring buffers with fixed capacity

Go’s concurrency model (goroutines + channels) makes the multi-client bridge pattern trivial. Each MCP client gets its own goroutine. The ring buffers are protected by sync.RWMutex. No thread pool configuration, no async/await complexity, no callback hell.

Why Not Node.js?

Node.js is great for web applications. But for a local system tool like an MCP server, it has drawbacks:

Dependency sprawl. Even a simple HTTP server pulls in Express or Fastify, which pull in dozens of sub-dependencies. Each one needs maintenance.

Runtime requirement. Users need Node.js installed. Version mismatches cause issues. Some users have Node 16, some have 22, and the behaviors differ.

Startup overhead. Node.js resolves and loads modules at startup. For a CLI tool that needs to be ready in milliseconds, this adds latency.

Single-threaded concurrency. Node.js uses an event loop. Under load (500 concurrent MCP clients), this becomes a bottleneck. Go’s goroutines scale to thousands of concurrent operations without additional complexity.

Why Not Rust?

Rust would also work well for Gasoline — single binary, no runtime, excellent performance. The tradeoff is development speed.

Go’s simpler type system and garbage collector mean faster iteration. For a product that ships features weekly and maintains a 140-test suite, developer velocity matters more than squeezing the last nanosecond out of a buffer read.

Go is fast enough. And “fast enough with faster development” beats “fastest possible with slower development” for a tool that’s still rapidly evolving.

The Bottom Line

Go gives Gasoline:

Zero dependencies — nothing to break, nothing to patch, nothing to audit
Single binary — download and run, no runtime required
Stability — compiles the same way in 5 years
Performance — native code, goroutine concurrency, predictable memory
Fast development — simple language, fast compilation, easy concurrency

The language choice is a product decision, not just a technical one. When your tool has zero dependencies, it doesn’t rot. When it’s a single binary, it installs in seconds. When it’s stable, users trust it.

That trust compounds over time. And time is the one dependency you can’t pin to a version.

Why Gasoline Saves Hours on Product Demos

Feb 7, 2026

Brenn Hill

Product demos eat time — scripting, rehearsing, recovering from mistakes. Gasoline turns demos into repeatable, AI-driven presentations you write once and run forever.

Where the Time Goes

A product demo looks like 15 minutes of clicking. Behind it is hours of preparation:

Scripting: Deciding the flow, what to show, what to skip, what order
Data setup: Creating demo accounts, populating sample data, resetting state
Rehearsal: Practicing the flow so you hit every screen without fumbling
Slide sync: Bouncing between slides and the live app, losing flow each time
Recovery planning: What to do when the API times out mid-demo, when the spinner won’t stop, when you click the wrong thing

And then you do it again next week for a different audience, with slightly different emphasis, and the whole prep cycle repeats.

What Changes with Gasoline

The demo becomes a text file. You write the flow in natural language — what to click, what to type, what narration to show. The AI drives the browser. You talk to the audience.

Preparation drops from hours to minutes. Write the script once. Adjust a few lines for different audiences. Run it.

Rehearsal is instant. Run the script, watch it execute, tweak a line, run it again. No manual clicking through 30 screens to test one change.

Recovery is automatic. If the AI clicks something and a spinner appears, it waits. If an error pops up, it can observe the page and adapt. It’s not a rigid recording — it’s an intelligent agent.

The Math

Here’s a conservative estimate for a recurring weekly demo:

Activity	Manual (per week)	Gasoline (first time)	Gasoline (repeat)
Script/plan the flow	30 min	15 min	0 min
Set up demo data	20 min	20 min	2 min (load state)
Rehearse	45 min	10 min (run + tweak)	0 min
Deliver the demo	15 min	15 min	15 min
Recover from mistakes	10 min avg	0 min	0 min
Total	2 hours	1 hour	17 minutes

After the first run, each repeat costs you 17 minutes — the demo itself. Everything else is automated.

Over a quarter of weekly demos, that’s 24 hours saved. Over a year, close to 100 hours.

Five Specific Time Savings

1. No More Alt-Tabbing

Subtitles appear directly on the page — like closed captions for your demo. The audience watches one screen. You don’t bounce between slides and the app. You don’t lose them at the transition.

2. No More Typos on Stage

The AI types perfectly every time. No mistyped email addresses, no “let me just clear that and try again” moments. Every form fill is precise.

3. No More Wrong Clicks

The AI uses semantic selectors — it clicks text=Create Project, not “the blue button that I think is third from the left.” It clicks the right thing every time, even if the layout shifted since your last rehearsal.

4. No More State Reset Pain

Save a checkpoint before the demo. Reset to it between runs. No manually deleting test data, no “let me just refresh and log in again.”

Save state as "demo-ready" -> Run demo -> Load state "demo-ready" -> Run again

5. No More Audience-Specific Rework

Different audience? Edit the script:

For executives: Skip the technical details, emphasize the business metrics
For engineers: Show the API calls, the WebSocket traffic, the performance data
For prospects: Focus on the happy path, add more narration

Same product. Same demo infrastructure. Different scripts. Swap a few lines instead of re-planning from scratch.

What a Gasoline Demo Looks Like in Practice

You sit in the meeting. You share your screen. Your AI tool is open. You say:

“I’m going to show you Acme’s project management platform. My AI assistant will drive the demo while I walk you through what you’re seeing.”

You hit enter on the script. The browser navigates, fills forms, clicks buttons. Subtitles appear at the bottom explaining each step. You narrate over the top, adding context the subtitles don’t cover.

If someone asks “Can you go back to the timeline view?” — you tell the AI, it navigates back. No fumbling.

If someone asks “What happens if you enter an invalid date?” — you tell the AI, it tries it, and everyone sees what happens. Live, unscripted, confident.

The demo feels polished because it is polished. The mechanical parts are automated. The human parts — your storytelling, your answers, your energy — are where you focus.

The Bottom Line

Demos are high-leverage moments — a 15-minute demo can close a deal, align a team, or greenlight a project. But the prep cost means most teams under-invest in demo quality.

Gasoline makes demo quality cheap. Write it once, run it perfectly every time, adapt it in minutes. Spend your time on the story, not the choreography.