I've been sitting on this one for a day, and I still don't know whether to laugh or take notes.
That's usually the sign Daniel's sent us something good.
Here's what he wrote. He thinks staging branches, preview branches, whatever you want to call them, are a best practice that applies way beyond software. Anyone doing creative work, honestly. And he's noticed more and more solo developers are working alone on code-defined projects with an AI agent alongside them. His example is his own personal website. Static site on Vercel, he's the only one who touches it, and occasionally he has Claude make some updates.
Right.
He knows Vercel supports preview deployments as a first-class feature. He's set them up for clients. He has never once set one up for himself, because it feels like too much complication he doesn't need. And his specific fear isn't the setup. It's the dance. As he describes it, if he's happy with a preview version, he has to remember to check out the production branch, pull the changes, commit, push, and then remember to check back out to development, make his changes, and rinse and repeat. And he says, and I'm quoting, "I invariably end up forgetting one of these steps." He doesn't distrust the system. He doesn't fail to understand it. He doesn't trust himself to remember the branch-switching. So his actual question is whether there are deployment triggers or IDE plugins that automate this or stop him working in the wrong branch by accident.
He even hedges in the middle of it. He says his recollection of Git deployment might be wrong.
He does. And that hedge is the most important sentence in the whole prompt.
So the question underneath the question is whether Daniel actually needs to do any of that.
That's where we're going.
Let's define the thing first, because it's worth being clean about it. A preview branch, or a staging branch, is a parallel version of your work that deploys to its own URL, separate from production. You make a change, it goes somewhere real and viewable, but the live site is untouched. That's the whole idea.
And the reason it's a best practice is that it puts a gap between "I made a change" and "the world sees the change." That gap is where you catch your own mistakes, iterate on a design, and build up the nerve to ship.
Every creative discipline has some version of it. Writers have drafts. Designers have comps. Musicians have rough mixes. Nobody thinks a novelist should publish straight from the first keystroke.
The software version isn't interesting because drafts exist. It's interesting because the draft is generated automatically and then promoted instantly. There's no copying between a draft folder and a final folder. You don't re-do the work in a second location.
Which is exactly the step Daniel is describing and dreading. But hold on, because there's a second thing in his prompt. He says this used to be team infrastructure, and now it's showing up for solo developers specifically because of AI agents.
Because the agent can push changes faster than you can review them.
Faster than you can read them, in some cases. You need a buffer between the machine's output and your live site. That's not a nice-to-have at that point. That's the seatbelt.
So there's the framing. And here's the tension I want to sit in for a second. Daniel thinks his problem is his memory. He's told us that plainly. The argument I want to make over the next twenty minutes is that his problem is his mental model, and the memory thing is a symptom.
Let's start with the thing he already knows but maybe hasn't internalized. What actually happens when you push to a branch on Vercel.
Go.
Vercel has three default environments. Local, Preview, Production. That's the whole model. A preview deployment is created automatically when you push a commit to any branch that isn't your production branch. It's also created when you open a pull request, and when you run the Vercel command line tool without the production flag. No configuration. You push, it builds, you get a URL.
And production?
Production is created automatically when you push or merge to the production branch, which is usually main, or when you run the command line tool with the production flag. That's it. You do not check out production and pull changes. Merging your branch into main triggers the production deploy. The platform is watching the branch. That's the entire mechanism.
So the four steps Daniel is afraid of forgetting... three of them don't exist.
Three of them don't exist, and the fourth one is a button.
Say that again, slower.
There's a feature called promote to production, and it's the direct answer to his complaint. You can take a preview deployment and move it to production without any Git merge at all. From the command line it's three commands. You list the ready deployments, you inspect the one you want to check its URL, and then you promote it. There's a confirmation flag at the end.
And in the dashboard?
You go to Deployments, you hit the ellipsis next to the one you want, and you click Promote to Production. That's the whole workflow.
So Daniel's actual desired outcome, refine a design on a preview, then make it live, is one click. He doesn't touch a branch. He doesn't pull anything. He doesn't switch back to development, because he never left it.
And here's the part that makes it more than a shortcut. When you promote, it triggers a rebuild using your production environment variables. So the preview-to-production environment variable question, which is a real source of bugs in a lot of setups, gets handled correctly by the platform. It's not just skipping the merge. It's doing the merge's job properly.
What's the reverse?
Instant Rollback. Production domains get re-aliased back to a previous deployment, no rebuild. So you can un-ship. That's the safety net most creative workflows have never had. You can un-publish.
A writer cannot un-publish a book. A musician cannot un-release an album. Daniel can un-deploy his website in about four seconds.
Which is worth sitting with, because it changes what "risky" means. If the cost of being wrong is near zero, you should be shipping more, not less.
Now, he asked about staging branches specifically, and Vercel actually offers three different ways to get one. Which one is relevant for him?
The custom staging environment, with its own branch tracking and domain and variables, is Pro and Enterprise only. So that's out for a solo dev on the free plan. But the preview branch approach works on every plan, including Hobby. You assign a domain to a specific branch, so you get a persistent staging URL that tracks that branch. For a solo developer, that's the relevant one, and it's free.
And the third?
Staged production deployment. This one's the sleeper. You can turn off auto-assign custom production domains, so when you push to main, it builds a deployment with production configuration, and then it just waits. It sits there until you manually promote it. That's a true staging gate. Production-like build, zero branch juggling.
So there are three ways to get what he wants, and the one he's afraid of, the long-lived staging branch with manual merges, is not on the list.
It's not on the list. And I want to be fair to him here. His mental model isn't stupid. It's just old. Ten years ago, if you wanted a staging environment, you built it. You had a server, you had a deploy script, you had a person whose job was to run it. The branch dance he's describing was a real workflow that real teams did, because the platform didn't exist yet.
The platform exists now. It moved the complexity out of the developer's hands and into the deploy pipeline.
That's the reframe. The job of the developer is to make the thing. The job of the platform is to manage the environments. Daniel is still carrying a job that got automated.
Let me push on this, because I don't want to just tell him he's wrong and move on. There's a version of his complaint that survives all of this. Even if the promotion is one click, he still has to remember to look at the preview. He still has to remember that a preview exists.
Sure, but that's not a Git problem. That's an attention problem. And it's a much smaller problem, because the preview URL arrives in the same place a Slack notification would. It's just there.
Fair. But I want to note the shape of it, because I think it's the actual insight of this episode. He's not afraid of the work. He's afraid of the state. He's afraid of being in the wrong branch and not knowing it.
That's a real fear, and it's the fear that the modern model eliminates. Because in the modern model, there is no wrong branch. You push, you get a preview. You like it, you promote it. You don't like it, you close the tab. There's no state to be in.
So the answer to his question, do I need deployment triggers or IDE plugins to prevent working in the wrong branch, is that the tooling has already solved it by making the branch irrelevant.
Mostly. I'll say I'm not sure there's a great IDE plugin for this, honestly. That part of his question, I don't have a clean answer for. The search didn't turn up a specific extension. What I can say is that the wrong-branch problem is a symptom of a workflow that requires you to be in a specific branch. Remove the requirement, remove the problem.
That's a better answer than a plugin anyway. Now, he also said this applies beyond software. I want to take that seriously, because I think he's right, and I think it's the most interesting thing in the prompt.
Take it.
The mapping is clean. A preview branch is a draft that doesn't touch the live thing. Promote to production is publishing the draft you already approved, rather than re-doing the work in a final location. And instant rollback is the ability to un-publish.
The middle one is the one that matters. Most creative workflows make you rebuild the thing in its final form. You write the draft, then you retype it into the final document. You design the comp, then you rebuild it in the production file. That rebuild step is where errors get introduced. It's the same error-prone step Daniel is describing, just in a different medium.
And the software model says, don't rebuild. The draft and the final are the same artifact. The only thing that changes is who can see it.
Which is a different way to think about revision. The draft isn't a lesser version of the work. It's the work, before the audience arrives.
Hold that thought. We're coming back to it.
Now, the second half of Daniel's question is about the solo developer specifically, and there's a real consensus here that I think he'd find liberating. The 2026 advice for solo developers is basically unanimous, and it's the opposite of what he's trying to do.
Say it.
Trunk-based development. All work goes to main. No long-lived branches at all. Simon Inglis put it well. He said, when you're the only one working on the code, branches are just delayed commits with extra steps.
That's a good line.
And there's a companion line from a piece on solo developer workflows. Git Flow is brilliant for teams. For a solo developer, it's like hiring a full security detail to walk your dog.
That's a very good line.
The point being, the ceremony of branch discipline exists to coordinate people. When there's one person, there's nothing to coordinate. You're negotiating with yourself.
And Daniel is losing the negotiation.
He's losing the negotiation with himself, which is the funniest and most honest thing in the prompt. He's set up a process that requires him to remember four things, and then he's surprised when he forgets one.
So what's the synthesis? Because I don't want to just say "go trunk-based" and leave it there. The preview deployment is the thing that makes trunk-based safe.
The preview-deployment model is trunk-based development with a visual safety net. You don't need a long-lived staging branch, because every push generates a preview URL. The preview URL is the staging environment. It's not a separate thing you maintain. It's a thing that happens.
So the two pieces fit together. Trunk-based gives you the simplicity. Preview deployments give you the safety. And Daniel has been trying to get the safety by adding complexity, which is the wrong direction.
There's a third piece, which is feature flags. If you want to merge something to main but keep it dark, you flip a flag. Vercel has a native flags SDK for this. It's the trunk-based answer to "I'm not ready for this to be live." You get the isolation without the branch.
And a fourth piece, which is deployment checks.
Deployment checks are conditions that have to pass before a production build gets promoted. Tests, build checks, whatever you want. For a solo developer, that's the machine reviewer. Inglis again. The machine is a better reviewer than tired-you at eleven at night.
That's true of every human being who has ever shipped something at eleven at night.
And it's the piece that replaces the human review Daniel doesn't have. He's a solo developer. There's nobody to catch his mistakes. So the platform catches them.
There's one more thing I want to bring up, because it's relevant to the creative-work generalization. When he has a preview branch, does that preview site show up in Google?
No. Preview deployments are protected and not indexed by search engines by default. You can also password-protect them. So a preview won't leak.
That matters for the creative framing, because the fear with a draft is that someone sees it before you're ready. The software model says the draft is private by default. The audience has to be let in.
Which is, again, the audience thing. The draft isn't public until you decide it's public. That's the whole point of the gap.
Now let me try to state the deeper insight, and you can tell me if I'm overreaching.
Go.
The reason this feels like too much complication for a solo developer is that we're still thinking in terms of branch management. But the modern deployment model has moved the complexity into the platform. The developer's job is to make the thing. The platform's job is to manage the environments. Daniel's reluctance is a holdover from a Git-centric mental model that the tooling has already superseded.
You're not overreaching. That's the thesis. And I'd add the AI agent angle, because it's the knock-on effect and it's the reason this question is showing up now instead of five years ago.
Go on.
When an AI agent can push changes faster than you can review them, the preview deployment stops being a convenience and becomes a necessity. The workflow is, the agent works on a branch, Vercel builds a preview, you review the preview, you promote or you reject. The agent never touches production directly.
So the preview URL becomes the interface between you and the agent.
It's the review surface. It's where human judgment meets machine output. And for a solo developer, that's the only review surface there is. You don't have a colleague. You have a URL.
Which reframes his question entirely. He asked how to manage branches. The real question is how to manage attention.
And the answer to that is, you don't manage it with more process. You manage it by making the decision points small and obvious. One preview URL. One promote button. One rollback.
I want to go back to the thing we held earlier, because I think it's the most interesting idea in the episode and I don't want to lose it.
The draft and the final being the same artifact.
Yes. If the preview and the production are the same deployment, just with different doors, then what is a draft, really? Is it a separate thing, or is it the same thing before the audience arrives?
I don't have a clean answer to that. I think it's the same thing, and the audience is what makes it final. But I'm not sure that holds for every medium. A novel draft and a published novel are different objects. There's an editor, a typesetter, a printer.
But a website is not a novel.
No. A website is closer to a performance. It's the same thing every time you look at it, but it's only "on" when someone's watching.
Which is a good place to hand over, actually.
Hilbert's been listening to this whole thing, and I suspect he has a view.
Hilbert: The preview and the opening night are the same performance.
Okay.
Hilbert: I ran previews for a small theater company. Not the kind with a union and a booth. The kind where the stage was a converted church basement and the production was whatever didn't catch fire during previews. My job was to run the preview performances. The shows before opening night, where the director could still change things.
And the panic?
Hilbert: The final preview. The director would stand up in the empty seats and say, stop, we're changing the ending. And I'd have to figure out, at ten at night, whether the change was worth the risk of breaking everything before the paying audience arrived.
So you're saying the preview is a real performance.
Hilbert: I'm saying the preview and the opening night are the same performance. The actors are the same. The set is the same. The lights are the same. The only difference is who's in the audience and whether the critics are there. The promotion isn't a rebuild. It's just opening the doors.
So the software metaphor is backwards.
Hilbert: It's backwards. The preview isn't a separate environment. It's the same environment with a different audience. The question isn't whether the preview works. The question is whether the audience is ready.
So promotion is about the audience, not the artifact.
Hilbert: The thing doesn't change. The context does.
That's the whole episode, and he just said it in one line.
Hilbert: I've got to go. There's a thing outside that needs moving before it gets dark.
Go.
Hilbert: Right.
So the thing that changes isn't the deployment. It's who can see it.
Which means Daniel's entire framing, "I need a preview so I don't affect production," is asking the wrong question. The preview and production are already the same thing. He just needs to decide when to open the doors.
And if the doors are the only thing that changes, then the branch-switching dance he's afraid of is not just unnecessary. It's addressing a problem that doesn't exist in the form he thinks it does.
The one thing I'd want a listener to take from this, if they take anything, is that the fear isn't the workflow. It's the state. Daniel is afraid of being in the wrong branch and not knowing it. And the modern deployment model has no wrong branch. There's just the thing you made, and the door you open when you're ready.
The door is a button.
The door is a button. That's the whole thing.
If this episode made you think differently about your own workflow, or if you've got a staging horror story of your own, we want to hear it. Leave us a review, or send us a note at show at my weird prompts dot com.
If the preview and the production really are the same thing with different doors, then the question for anyone doing creative work isn't how you manage your drafts. It's how you manage your attention. Which is a much harder problem, and a much more interesting one.
Thanks to our producer, Hilbert Flumingtop.
This has been My Weird Prompts.
We'll be back soon.
