We care about using AI in a particular way. It should help support agents write better replies, not substitute for them. The human stays in charge of the conversation, and the model does the unglamorous work of drafting, rephrasing, and suggesting links. There There is in private beta right now, and you can apply for early access at there-there.app.

We're building There There with Laravel and Inertia, and we lean heavily on the latest features Inertia v3 brings. This post is about another one: prefetching on hover.

Using prefetch on hover

In a helpdesk, a support agent flips between views constantly. My open tickets, unassigned, waiting, spam, team views, custom filters. Every switch triggers a fresh page load against a different filter. If each switch blocks on a round-trip, the sidebar starts to feel like dead weight.

Inertia v3 has a built-in prefetching API that covers this neatly. Instead of waiting for the click, we fetch the view's data as soon as the cursor hovers over the link, and keep the result in a short-lived cache so the actual navigation feels instant.

Here's the core of our sidebar view link.

<Link
    href={buildViewUrl(view)}
    prefetch="hover"
    cacheFor="30s"
    preserveState={isOnTickets}
    preserveScroll={isOnTickets}
>
    <Icon className="size-4" />
    <span>{view.label}</span>
</Link>

prefetch="hover" is the whole mechanism. After the cursor sits on the link for 75ms, Inertia fires the underlying request in the background. When the agent actually clicks, the response is already in memory, and the page swaps without a network wait.

cacheFor is where the real tuning happens. The default is 30 seconds. For our ticket views, that's a sweet spot: long enough that flipping back and forth feels free, short enough that the counts don't go visibly stale. You can push it higher for more static lists, or drop it to "0" for views where freshness matters more than speed.

Here it is in action. The cursor hovers, Inertia warms the cache in the background, and the click lands on data that's already there.

One small gotcha is worth flagging. When an agent navigates away from a view, you often want to cancel any in-flight requests so you don't paint stale data. The obvious call is router.cancelAll(), but that also cancels prefetches that are happily warming the cache for views the agent is about to visit.

Inertia v3 lets you scope that. Here's how we cancel the active visit without touching prefetches.

router.cancelAll({ async: false, prefetch: false });

The flags tell Inertia to keep background prefetches and async visits (like an infinite scroll) alive, while cancelling the normal page visit. The agent gets an immediate navigation and the sidebar stays primed for the next move.

In closing

Prefetching on hover is one of those features that costs almost nothing to turn on and changes how the app feels. One prop, a cache duration, and you're done. The cancellation scoping is the one detail worth knowing about, because without it you'll undo your own optimisation the first time you navigate away from a view.

You can read more in the Inertia v3 prefetching guide. And if you'd like to try There There yourself, we're in private beta right now and you can apply for early access at there-there.app.

One thing we care about in particular is using AI to help humans craft better responses, not to replace them. The agent stays in charge of the conversation. The model just helps them reply faster and a little sharper. There There is in private beta right now, and you can apply for early access at there-there.app.

We're building There There with Laravel and Inertia, and we lean heavily on the latest features Inertia v3 brings. In this post I'd like to give one example: optimistic updates.

Using optimistic updates

A support agent toggles a lot of small things in the course of a day. Adding a tag to a ticket, granting a teammate access to a channel, flipping a workflow on or off. Each of those is a single click that triggers a server round-trip.

If the UI waits for that round-trip before showing the change, the app feels sluggish. Not broken, just slow. And in a tool you live in all day, that compounds.

Inertia v3 ships with a first-class optimistic updates API that handles this nicely. Instead of waiting on a response, we immediately update the UI to reflect the change and let Inertia roll it back if the request fails.

Here's how it looks on our member detail page. An admin can toggle whether a teammate belongs to a team. The list of teams comes in as a prop, and we render a switch next to each one.

{teams.map((team) => (
    <div key={team.id}>
        <span>{team.name}</span>
        <Switch
            checked={team.is_member}
            onCheckedChange={() => handleToggleTeam(team)}
        />
    </div>
))}

When the switch is flipped, handleToggleTeam runs.

function handleToggleTeam(team) {
    const optimistic = router.optimistic((props) => ({
        teams: props.teams.map((t) =>
            t.id === team.id ? { ...t, is_member: !t.is_member } : t,
        ),
    }));

    if (team.is_member) {
        optimistic.delete(removeTeamMember.url({
            team: team.ulid,
            user: member.ulid,
        }), { preserveScroll: true });

        return;
    }

    optimistic.post(addTeamMember.url({
        team: team.ulid,
        user: member.ulid,
    }), {}, { preserveScroll: true });
}

The function we pass to router.optimistic receives the current props and returns the keys we want to patch. Inertia applies that patch immediately, so the toggle in the UI flips before the request leaves the browser. When the response comes back, Inertia merges the real server props on top.

I like the chained style here because the same optimistic patch can lead to either a post or a delete. We capture the optimistic builder once and pick the verb after.

Here it is in action. The toggle flips immediately, and the request happens in the background.

For simpler cases there's a second style. You pass optimistic straight as an option to the verb. Here's our workflow toggle:

function handleToggle(workflow) {
    router.patch(workflowToggle.url(workflow.ulid), {}, {
        optimistic: (props) => ({
            workflows: props.workflows.map((w) =>
                w.id === workflow.id ? { ...w, is_enabled: !w.is_enabled } : w,
            ),
        }),
    });
}

Same idea. You describe the patched shape, hand it to Inertia, and let it deal with the rest.

If the server returns a non-2xx response, Inertia reverts the optimistic change automatically. There's no manual restore code to write. Validation errors land where you'd expect, and only the keys you touched in the callback are snapshotted, so unrelated state stays untouched. Concurrent requests each carry their own snapshot, which means a slow request won't undo a faster one that already returned.

In closing

Optimistic updates used to mean keeping a parallel copy of state, reverting it on rejection, and reasoning carefully about race conditions. With Inertia v3, you describe the next state and that's it. The whole interaction is about ten lines.

You can read the official documentation in the Inertia v3 optimistic updates guide. And if you'd like to try There There yourself, we're in private beta right now and you can apply for early access at there-there.app.

Why we built Scotty

Even though services like Laravel Cloud make it possible to never think about servers again, I still prefer deploying to my own servers for some projects. I know my way around them, I can pick whichever server provider I want, and I have full control over the environment.

Tools like Laravel Forge have built-in deploy functionality, and it works well. But I've always preferred running deploy scripts manually from my terminal. I want to see exactly what's happening while it runs, and when something goes wrong, I want to be staring at the output the moment it happens, not clicking through a web UI to find a log.

For years, I used Laravel Envoy for this. It does the job, but I wanted nicer output while tasks are running, and the ability to pause execution mid-deploy. Envoy uses a Blade-based file format, which works fine for us. But not everyone wants to write Blade syntax for their deploy scripts. So Scotty also offers a plain bash format for people who prefer that.

Scotty was built with the help of AI, using the Envoy codebase as a source. Even though Scotty is a rebuild from scratch, in spirit it is a fork of Envoy. Credits to Laravel for providing the foundation. You can read the full acknowledgement in the Scotty repo.

Using Scotty

Defining tasks and deploying

You define your tasks in a Scotty.sh file. It's just plain bash with some annotation comments. Your editor highlights it correctly, you get full shell support out of the box. Here's what that looks like:

#!/usr/bin/env scotty

# @servers remote=deployer@your-server.com

# @task on:remote
deploy() {
    cd /var/www/my-app
    git pull origin main
    php artisan migrate --force
}

Deploy with a single command:

scotty run deploy

Scotty connects to your server, runs each task in order, and shows you what's happening in real time. Each task displays its name, a step counter, elapsed time, and the command currently being executed. When everything finishes, you get a summary table with timing for each step.

These screenshots are from deploying this very blog. You can find the deploy file on GitHub.

If a task fails, its output is shown and execution stops right there so you can investigate.

Writing plain bash instead of Blade

In addition to being able to read Envoy.blade.php files, Scotty introduces a new Scotty.sh format. Every line is real bash. Tasks are just bash functions with a # @task annotation that tells Scotty which server to run them on. Macros group tasks into a sequence. Variables are plain bash variables, available everywhere.

Because it's all valid bash, you can use helper functions, computed values like $(date +%Y%m%d-%H%M%S), and any shell construct you'd normally use. No Blade directives, no PHP @setup blocks, no {{ $variable }} interpolation.

You can also pass variables from the command line. Running scotty run deploy --branch=develop makes $BRANCH available in your tasks. The key is automatically uppercased.

You can list all available tasks and macros with scotty tasks:

Pausing, resuming, and pretending

You can press p at any time during execution to pause after the current task finishes. Press Enter to resume, or Ctrl+C to cancel. This is handy when you want to check something on the server mid-deploy before continuing.

There's also a pretend mode (scotty run deploy --pretend) that shows you exactly which SSH commands would be executed without actually running them. And a summary mode (scotty run deploy --summary) that hides task output and only shows results.

Validating your setup with doctor

Before your first deploy to a new server, you can run scotty doctor to validate your setup. It checks that your file parses correctly, verifies SSH connectivity to each server, and confirms that tools like php, composer, node, and git are available on the remote machine.

Migrating from Envoy

If you're already using Laravel Envoy, Scotty can read your Envoy.blade.php file directly. No changes needed. Just run scotty run deploy and it works. From there, you can gradually migrate to the Scotty.sh format if you want to, or keep using Blade.

If you're new to all of this, the Your first deploy script page in the docs walks you through everything step by step.

In closing

Scotty gives you a clean, modern way to run deploy scripts and other SSH tasks from your terminal. Plain bash, beautiful output, and full control over every step.

You can find the full documentation on our docs site and the source code on GitHub. This is one of the many tools and packages we've created at Spatie. If you want to support our open source work, consider picking up one of our paid products.