Launched on Product Hunt today: the part of shipping an AI-built app nobody automates — the server
A few weeks ago I posted here about the wall people hit after the AI finishes the app: it has to run on a real server, and that's SSH, a reverse proxy, HTTPS, a firewall, Docker, and a 2am outage you can't read.
Server Manager is live on Product Hunt today. You connect it to your own server with your own SSH login and say what you want — "put this app on my domain with HTTPS", "lock down the firewall", "the site's down, find out why" — and the agent does the server-side work. Before anything changes, it shows you the literal command and waits. Read-only checks just run.
Three people here shaped it more than any analytics did:
- nicominetti pushed the "inverse list" — after a check, say what you looked at AND what nobody looked at. Saying what a tool does NOT cover turns out to be the reassuring half.
- madmike said the pain isn't first setup, it's the second deploy — changing a box you'd already declared done, and proving from outside that it still holds.
- Yuki_Code1 took the demo apart on trust framing and was right about who the warning was for.
Where it stands honestly: the agent already re-probes what it touched (curls the port, verifies the cert issued, checks the firewall rule sits ahead of the reject) and it isn't allowed to call something done off a bare exit code. The full "here's what changed and here's what I couldn't check" report that madmike and nicominetti described is designed but not built — it's next if people actually want the core.
Free trial, no card. Tell me where it breaks.
https://www.producthunt.com/products/server-manager?utm_source=other&utm_medium=social
Checked instead of guessing on this one. Supabase does have Audit Logs, who changed what and when, but it's gated. Not available on Free or Pro, only Team plan and up. I'm on Pro, the tier that unlocks things like leaked password checks, and audit logs specifically aren't in reach at that level. So the honest answer is no, not because the capability doesn't exist, but because it sits above where a solo project like mine actually pays. Good prompt, made me go check rather than assume.
Too many automated deployment tools just look for exit code 0 and call it a day, even when Nginx quietly failed to reload or a port is still blocked. Having the agent actually curl the endpoint to verify state before declaring success builds real trust. Great job iterating on early user feedback.
Your two examples are different animals, which is the part that took me a while to see.
A failed nginx reload is catchable from the box: reload is asynchronous, so exit 0 only really means the reload was requested, and it's the curl afterwards that tells you whether the new config is the one actually serving. A blocked port isn't catchable from the box at all — curl against localhost sails straight past the firewall that's blocking everyone else, and the box will cheerfully report itself healthy while nobody can reach it.
So the rule I've ended up with is that the curl has to hit what a visitor hits, the real hostname rather than the loopback — and where even that can't settle it, say so instead of printing a tick.
Thanks for the kind words.
No, not that I've found. Went and checked Supabase's own settings pages for exactly this after your question, there's no changelog or audit trail on the Auth toggles themselves. The closest thing is the project's own event logs, and those cover database queries and API traffic, not dashboard clicks. So a toggle someone flipped three weeks ago really does leave no trace beyond whoever remembers doing it.
I hit this directly, not hypothetically: turned on a captcha-protection toggle by mistake, caught it minutes later when a real signup failed, flipped it back off. If I hadn't been watching the account in real time when it happened, there'd be nothing to reconstruct from, no diff, no commit, no log line. What I actually leaned on instead wasn't a platform feature, it was writing it down myself the second it happened. Which is really just relocating the audit trail into a text file, not closing the gap you're pointing at.
Ran an MSP for two decades, and madmike's point is the real one, the pain isn't first setup, it's proving on day 200 that a box you declared done in January still holds. Config drift is what quietly breaks trust with a client, everything was compliant on the audit and nobody can prove it still is six months later. If that re-probe step becomes a standing job instead of a one-time check, that's what turns this into something people renew, not just a setup wizard they run once.
Day 200 is the right frame, and the part I'd underline is the attribution problem: usually it isn't that the box drifted, it's that nobody can say what moved or when. "It was compliant in January" and "here's what changed since January" are two very different conversations to be having with a client.
The structural reason it's hard is that a probe can only ever tell you what's true right now. Day 200 is a diff, not a state. So the standing version of this needs a durable record of what the tool itself did — and then the interesting output isn't the probe, it's the subtraction. Probe the box, take away everything your own record accounts for, and the remainder is change that arrived some other way: the cron, the unattended upgrade, the person who SSH'd in at 2am and meant to mention it. That remainder is what you'd actually want to hand a client, and nothing I know of produces it today.
On the renew point — I don't sell a subscription and I'm not planning to, but the substance holds either way: what earns a second purchase is still being useful in June, not a wizard that was impressive in January.
A question, since you've got two decades of this: was the evidence mostly for you, or for the client? I can't yet tell whether that report wants to be an internal signal or a thing you export and send to someone who's asking for it.
The vantage point problem is basically the whole history of SEO tooling, which might be a useful outside confirmation that you're building the right thing.
Every crawler that runs from your own machine, with your cookies, on your network, following the sitemap you handed it, will tell you the site is healthy. Googlebot turns up with no cookies from a different network and often gets a materially different site. The classic version is a firewall or WAF rule that allows the office IP and quietly blocks cloud ranges, so your monitoring is green because it is standing inside, and the only crawler that matters is being refused at the door. Same shape as your security group example exactly.
Which is why Search Console gets trusted more than any third party crawler despite being slower and worse in almost every other respect. It is not better instrumented. It is just standing outside and reporting what actually happened to the requester, rather than asking the box how it feels.
So I'd argue the re-probe from your backend isn't the differentiator you're calling it. It's the thing that makes the report mean anything at all, and everything above it is presentation. Manan's line is right, and it cuts your way: a green light that didn't verify anything is worse than no check, because it stops the person looking.
One addition to the report shape. Put a timestamp on "couldn't confirm". Propagation and cache state are exactly the two things where the honest answer is not yet, ask again in ten minutes, and a report that says when it looked is much harder to misread than one that just says unknown.
The SEO parallel lands, and it's the useful kind of outside confirmation — a different industry hitting the same wall from a completely different direction. "Asking the box how it feels" versus "reporting what actually happened to the requester" is going in the spec with your name next to it.
Where I'd push back is the differentiator line, and it's a narrow disagreement. The failure you're describing isn't a check that ran from inside — it's a check that ran from inside and reported as though it hadn't. A crawler that said "healthy, from your network, with your cookies, following the sitemap you handed me" would never have fooled anyone. The lie is the unlabelled vantage, not the vantage.
So I don't think the on-box probes are presentation. Concrete case: on reverse-proxy migrations the agent rehearses the new config on alternate ports and verifies with loopback curls — and it's specifically instructed not to ask the user to open that alt port in their browser, because most cloud providers block non-standard ports inbound, the user would see a timeout, conclude the migration is broken, and abort a change that was working. Two questions kept deliberately apart: is the config correct, and can a stranger reach it. What it can't do today is answer the second one positively. It just declines to pretend it did.
Your argument does move something, though. I'd had the off-box vantage filed as a differentiator, and it's closer to completion than differentiation. The order stands — the honest-scope half needs no infrastructure and shouldn't wait on the half that does — but that framing was wrong and I've changed it.
Taking the timestamp outright — it's cheap, it needs no new infrastructure, and it fixes a real ambiguity. "Unknown" is a dead end; "not yet, as of 14:32" is an instruction. It also makes the line a property of that look rather than a property of the world, which is the honest claim.
One back at you: Search Console is trusted because it stands outside, but also because it is the requester who matters. My vantage would be my datacenter, not the visitor. Is one honest outside vantage enough, or does the trust only really arrive when you're the party that counts?
You're right, and it's a better formulation than mine. The lie is the unlabelled vantage, not the vantage. I'd collapsed "this check can't see X" into "this check is worthless", which is the same error I was accusing the tooling of.
On your question back: no, one outside vantage isn't the same as being the party that counts, and I wouldn't claim it is. But Search Console isn't the visitor either. It's Google reporting on Googlebot. It gets trusted because it happens to be the requester that matters for that particular decision. If you're debugging whether a human in Berlin can complete a checkout, Search Console is useless to you.
So I don't think you need to be the requester. You need to name which requester you're claiming for, and that changes per check. For a TLS cert or a DNS record, any outside vantage is genuinely representative, because the answer doesn't vary much by who asks. For firewall rules, geo routing and CDN behaviour it varies enormously, and one datacenter is a sample of one.
Which suggests the cheap upgrade isn't a better vantage, it's more than one. Two or three regions, where disagreement between them becomes the finding rather than a problem. "Reachable from Frankfurt, timed out from Sao Paulo at 14:32" is more useful than any single verified, and it's the same move as the timestamp: it makes the claim a property of the observation rather than a property of the world.
The alt-port detail is the most interesting thing in your reply though, because it implies a third state you haven't named. Not verified, not couldn't-confirm, but verified and deliberately not shown to you, because checking it yourself would mislead you into aborting a change that was working. I can't think of another tool that says don't check this one yourself and then explains why. That's an unusual amount of trust to ask for, and I'd put it in the report explicitly rather than leave it silent, because the alternative is the user finds the alt port on their own and you never get to give the explanation.
You've named a state I'd been treating as an implementation detail, and you're right that it belongs in the report. There are four, not three: verified, couldn't confirm, not my layer — and this one, which is verified while your own obvious test will disagree.
Where I'd take it further: the answer to "that's a lot of trust to ask" is to not ask for it. The line shouldn't say don't check this yourself. It should hand over the check that isn't misleading, and say when it becomes valid. Something like — verified on 8443 at 14:32; don't test that port from your browser, your provider blocks non-standard ports inbound and you'll get a timeout that means nothing; after cutover 443 will answer, and that's the test that counts. Same explanation, delivered before they go looking rather than after, and it leaves them something to do instead of a request to believe me.
Your per-check point is the one that reorganises the rest. You don't need to be the requester, you need to name which requester you're claiming for — and the class of check decides how much a single vantage buys you. A cert or a DNS record barely varies by who asks, so one honest outside look is genuinely representative. Firewall rules, geo routing and CDN behaviour vary enormously, and one datacenter is a sample of one. Which makes vantage count a per-check property rather than a global setting. Cheaper as well as more honest, since nothing needs three regions to confirm a cert.
And disagreement-as-finding is the right frame. "Reachable from Frankfurt, timed out from São Paulo at 14:32" isn't a broken check, it's the most informative line on the card — the same move as the timestamp, where the claim becomes a property of the observation rather than of the world.
When I've drafted the card I'll put it in this thread rather than in my notes.
clearPainfully relatable. In hospitality I learned that the person who smiles at your demo is rarely the one who signs. Now we only market to the owner — the one who personally feels the 30% commission in their pocket.
The 30% landing in their own pocket is the right test, and I learned the same thing by aiming at the wrong room first.
The people who smile hardest at a server demo are sysadmins and DevOps folks. They find it clever and they'll never buy it, because the work I'm removing is the work they're good at — and a bit proud of. So I stopped posting where they gather. The person who signs is the solo founder who shipped something with AI and now owns a server they never asked for. There's no ops team to hand it to, so the lost Saturday comes out of their own weekend. That's the 30%.
One difference I keep bumping into: your owner is a role you can target. Mine is closer to a moment — the same person is exactly right the week their app has to go live, and the wrong person a fortnight earlier.
How do you actually reach the owner, though? Every hospitality owner I've ever met sits behind a manager.
"isn't allowed to call something done off a bare exit code" is the line that got me, that's the exact same principle from a thread earlier this week about AI checks reporting success while measuring nothing. a green light that didn't actually verify anything is worse than no check at all, because it actively trains people to trust something unverified
the re-probing detail (curls the port, verifies the cert issued, checks the firewall rule ordering) is doing the real work here, most tools would stop at "command executed successfully" and call it done. building something that shows the plan before acting too, phone commands instead of server ops, and the thing I keep relearning is that showing the plan is only half of it, verifying the actual outcome after is the harder, less glamorous half that's easy to skip
the unbuilt "here's what changed and here's what I couldn't check" report is the part I'd actually want most as a user, honestly more than the re-probing itself, since "I couldn't verify this" said honestly is more trustworthy than a silent assumption of success. any sense of timeline on that, or is it waiting on real usage data to know which gaps matter most first
Manan, "a green light that didn't verify anything is worse than no check at all" is better than how I've been saying it, so I'm stealing it. That's the exact failure I built against: a check that comes back clean because it never looked is worse than nothing, because now the person stops looking too.
On your question — no date, and I'd rather tell you why than invent one.
It isn't blocked on design. I have the shape of the report written down: what changed, what I verified from your server, what I verified from outside, what I couldn't confirm, and what isn't my layer at all. Those last two lines are the ones I actually care about. "DNS resolves from where I'm standing, I can't tell you it's propagated everywhere yet" is a more useful sentence than any green check I could print.
What it's blocked on is that today every probe runs on the box, over SSH — and that's the wrong place to stand for about half of what goes wrong. A server's own firewall can be wide open while the cloud provider's security group quietly drops the port. The box tells you it's listening and it's telling the truth; it just can't see the thing that's blocking you. Same with DNS: the box has it cached, so it says fine while the rest of the world hasn't caught up. So v1 is doing the resolve through a public resolver, a TCP connect, and a real HTTPS fetch from our backend — a different network than the user's box — and only then writing the report. That's the actual work. It's weeks, not a quarter, because the checks already exist. They're just standing in the wrong spot.
The honest reason it isn't started: it's a differentiator, not the core. If people don't connect a server and let the agent do real work on it, the world's most honest verification report is a report about nothing. So yes, it's gated on usage — and the signal I'm watching is narrow: do people get through one real change on their own box without me in the room. If this week gives me that, this is what I build next.
One pushback on wanting the report more than the re-probing: I don't think you can have that trade. The report is only as honest as what's under it. Without the re-probe, "verified" is an exit code in a nicer font. The probing is what earns "couldn't confirm" the right to be believed.
What are you building? Approving server changes from a phone is a harder version of this problem — less room to show the plan, and the person is even less likely to be somewhere they can fix it if it goes sideways.
fair correction, and obvious in hindsight, I was treating the report and the verification method as separable when they're not, the report's only as trustworthy as the probing that produced it. wanting "the report" more was really just wanting the honest-uncertainty framing, but that framing has no value without the re-probe actually earning it
the outside-the-box probing insight (SSH-based checks can't see what the cloud provider's security group is doing) is a genuinely sharp diagnosis of why "verified locally" quietly means something different from "actually verified," that's not a minor implementation detail, that's the whole reason a green check can lie truthfully
to answer directly: building StareBrain, natural language commands for Android, phone control instead of servers. you're right that it's a harder version in one specific way, less screen space to show a full plan, and if something goes wrong the person's holding a phone, not sitting at a terminal ready to fix it. but it might also be an easier version in a different way, most of what I'm dealing with is lower-stakes and more reversible (send a text, toggle wifi) than a security group misconfiguration taking a server offline. so maybe not strictly harder, just harder along a different axis, less room to explain, lower cost if something slips through
the "narrow signal you're watching" (one real change completed solo) is a good, honest bar to gate the roadmap on rather than a calendar date, appreciate you laying out the actual reasoning instead of a placeholder timeline
"A green check can lie truthfully" is the distinction exactly. The check isn't lying about what it saw, only about what it stood for.
On easier-along-a-different-axis, I'd push on your own example. A security group misconfiguration is unpleasant, but it's fully recoverable — you put the rule back and the box is where it was. A sent text isn't recoverable at all. There's no unsend on a message someone has already read, and no rollback on the reaction it caused.
So I don't think the axis is stakes, it's recoverability, and phones are full of actions that have none precisely because so many of them touch other people. Toggling wifi is trivially reversible. Sending, deleting, replying, paying, calling: not really. That's the test I gate on, and it's the only one I've found that survives contact with real cases, because "how dangerous does this sound" and "can I put it back" come apart constantly.
Which makes your compression problem sharper than the screen-space framing suggests. If you've got two lines, the thing that has to survive isn't the command, it's the consequence — what you'd lose if this is wrong. On a phone I'd guess that isn't a nicety, it's the only form that fits.
One thing that's genuinely easier on your side: your user is present. Mine starts a change and walks away. Yours is holding the device, in context, at the moment it matters. That's an attention budget I don't have.
Good luck with StareBrain.
Recoverability over stakes is right, and it's going to change how I think about the permission model, not just the confirmation copy. I'd been bucketing actions by category (messaging, calendar, device control) when the real split is reversible vs. not — wifi and a calendar move-with-notice-window sit together, a sent text and a placed call sit together, regardless of which category they're filed under. That's a cleaner line to build the "extra scrutiny" tier around than anything I had.
The consequence-over-command point is the one I'll actually test first, since it's concrete enough to try this week: instead of "Text Mom: running late," something closer to "Mom will see this, can't be unsent." Suspect that's a better filter for whether someone actually reads the confirmation instead of pattern-matching "yep, send button" on autopilot.
And yeah — no argument on the attention-budget difference. I get a captive, present user for maybe four seconds. You're hoping someone remembers to check back on a server they've already mentally moved on from. Different problem wearing the same shape.
Appreciate you working through this out loud, genuinely useful thread.
The key point is that an exit code alone doesn't prove success. For operations work, I'd start the report with the exact probes that passed. Then I'd add a separate "not checked" section that a green status can't hide. The user can decide whether to accept that risk. They can't make a good call based on "deployment complete."
Agreed on the exit code, and on keeping the two lists apart. Where I land slightly differently is the order — I'd put what changed first, then the probes. After an agent has touched your box the first question is "what did you do", not "what did you check". The probe list is the evidence for that claim; on its own it's floating.
The part that took me longest to get right: a probe line only counts if it's specific enough for you to tell me it's wrong. "Firewall configured ✓" is the same green light in a different font. "443 ACCEPT sits ahead of the reject rule" is a claim you can read and say no, you checked the wrong chain. Same with certs — not "HTTPS working" but issued, chain valid, and it's the domain you actually asked for.
On the not-checked section: the problem I had to solve there is that the list is infinite, so it's only useful if it's scoped to what a reasonable person would have assumed was covered by the thing I just did. And it wanted splitting in two, because the halves carry different weight. Couldn't confirm — I tried, it's inconclusive: DNS resolves from where I'm standing, I can't speak for the whole internet. Not my layer — your app's own auth and injection bugs: I'm never going to check that, and you shouldn't sit around waiting for me to.
That second line is the one people keep telling me is the reassuring part, which is not what I expected when I wrote it.
“Isn’t allowed to call something done off a bare exit code” is probably the most important sentence in the whole post. One refinement I’d make for the report you haven’t built yet: reprobing what you changed only proves that the change was applied. It doesn’t prove the property the user actually cares about. A cert being issued, for example, doesn’t mean it’s being served by the right vhost.
For an ops agent, the error costs are also asymmetric. A false “all clear” can be much more damaging than a false alarm, so that should directly shape what the agent is allowed to claim. The inverse list (explicitly showing what nobody checked) is probably the first feature I’d ship. Being upfront about the limits is what makes the rest of the report believable.
Good luck with the launch today.
Agreed on the principle, and it's the rule the checks are already written to: the probe has to be the property, not the mechanism.
The cert case is the cleanest example of it. I don't check that issuance succeeded — that's the mechanism, and it tells you nothing about what a visitor gets. The check is a real curl -I https://<domain> against the hostname, which is the request that actually selects the vhost. If that doesn't come back 2xx/3xx it isn't done, and on the reverse-proxy migrations a failure there rolls the whole change back rather than filing a warning next to a green tick.
Firewalls are the same shape. If Docker is on the box the agent won't touch ufw at all — it works in raw iptables and preserves Docker's own chains, because a textbook-correct ufw rule on a Docker host is exactly your point: it applies cleanly and the property doesn't hold, since Docker writes its rules ahead of it.
The limit I'd put on my own claims is the vantage. Those requests still originate on the server. They exercise the real hostname and the real vhost, but they can't see a cloud security group sitting in front of the box, and they can't tell you DNS looks the same from anywhere else. So where that's the remaining unknown the agent says so and hands you the provider-side step instead of printing a check. Moving those probes somewhere that isn't the box is the first half of the report we're talking about — the half that turns "reachable from here" into "reachable for a stranger".
Your asymmetry point is the one that settles the wording: inconclusive degrades to "couldn't confirm" and never quietly to ✓, and a check that didn't run still has to appear. A missing line reads as green.
And you're right to put the inverse list first. Bonus reason: it needs no new infrastructure — it's derivable from what the agent already knows it didn't do. That's a week, not a build.
Thanks for the launch wish, and for being the second person to land on inverse-list-first independently. That's the signal.
The vantage paragraph is the part I'd quote back at you: "reachable from here" versus "reachable for a stranger" is the cleanest statement of the residual limit I've seen, and saying it in the report instead of papering over it is the whole game. The curl-the-vhost check is exactly the property-not-mechanism rule applied right.
One small correction, only because it's evidence in your favor -> check the timestamps on the inverse list comments (I was about an hour ahead, which means we converged independently rather than echoed). Two people arriving at the same feature from different directions is a better signal than one person being seconded. Ship the week-not-a-build version; I'll be pointing people at it.
Taking the correction, and it is the stronger read. Ordering matters as evidence: seconding someone is agreement, arriving first from a different direction is convergence. Worth adding that it's three rather than two — someone made the same inverse-list argument here weeks ago from the "tell me what nobody looked at" angle, entirely separately.
Concrete outcome, since you did real design work in a comment box for free: I split the spec today. It was one deferred block; it's now two stages. Stage 1 is the honest-scope card and it needs no new infrastructure, so it stops waiting on anything. The off-box vantage is Stage 2 behind it.
Your asymmetry point went in as the wording rules, close to verbatim: inconclusive degrades to "couldn't confirm" and never quietly to a tick, and a check that didn't run still gets its own line, because silence reads as green. That second one is the rule I'd have missed.
When the card format is drafted I'd like to put it in front of you before it ships. You've got the right allergy for it.
Deal, send it over whenever it's drafted. And your three-not-two count actually strengthens the case: three people arriving at the same feature independently means it's load bearing, not a nice to have. Good luck with stage 1.
Load bearing is the right distinction. A nice-to-have would have waited for Stage 2; this one stopped waiting.
When I send it over it'll be the card plus the list of things the card deliberately doesn't claim. That second list is the half I want you to attack — the claims are easy to check, the omissions are where I'll be quietly flattering myself.
Thanks for the thread.
Relate to the "wall after the AI finishes the app" framing, hit a version of it myself building a calorie tracker mostly through Claude. Sidestepped the raw-server side of it entirely by going with Supabase for the backend instead of a VPS, so no SSH/reverse-proxy/Docker layer to babysit, but that also means I've got no real feel for how hard this problem hits people who did go the raw-server route.
The "second deploy on a box you'd already declared done" point from madmike rings true from an adjacent place though: my worst App Store rejections weren't from the first submission, they were from confidently re-submitting a fix I was sure had shipped and finding out something else had quietly broken. The "say what you checked AND what you didn't check" instinct sounds right, that's basically what Apple's own reviewers force you into, a specific claim about what was actually verified, not just "should be fixed now."
Supabase for a calorie tracker is the right call and I'd have made the same one. If a managed backend covers what you're building, there's no prize for running your own box.
Your App Store parallel is better than you're giving it credit for, and it named something I hadn't put words to. Apple hands you an external reviewer — someone who isn't you, isn't on your machine, looking from outside and willing to say no. Nobody does that for a server. You change something, it looks fine from where you're standing, and your only reviewer is whoever hits the site next: you at 2am, or a customer who just quietly leaves. The whole "what I checked and what I didn't" idea is really an attempt to be that reviewer — and specifically one that admits when it couldn't see something instead of stamping approved.
"Confidently re-submitting a fix I was sure had shipped" is the exact failure, too. It's not hard because the state is complicated. It's hard because what you actually need is a diff — what moved since it worked — and looking at the thing fresh can only ever tell you what's true right now.
Genuine question, since you're on the other side of it: does Supabase spare you the second-deploy problem or just relocate it? RLS policies and env vars on a project you'd already declared done seem like they'd carry the same "I was sure that shipped" feeling.
Honestly? Relocates it, doesn't spare you. Real example: I built a calorie tracker on Supabase, and back in August found 7 tables sitting with RLS enabled but zero policies attached, which fail closed (return nothing) rather than fail open, so nothing was ever actually exposed. But the reason it was safe was luck of the exact failure mode, not anyone verifying it. If it had failed open instead, that's the same "I was sure that shipped" gap, just moved from a deploy script to a dashboard toggle nobody thought to double check.
Worse example, same app: I flipped on Supabase's captcha-protection toggle in the Auth settings before the matching client-side code had actually gone out in a live build. It would've silently blocked every real signup and login the moment it saved. Caught it fast, but the toggle and the code it depends on live in two completely different places with no dependency graph connecting them, nothing would've complained if I hadn't checked.
So the honest answer is Supabase moves the second-deploy problem from "did the server restart with the new code" to "do these five settings across three different dashboard pages all still agree with what the client expects." Arguably worse, because a bad deploy at least fails loud, a stale dashboard setting just quietly does the wrong thing until a user hits it.
That's a better answer than the question deserved, and it moves where I think the pain actually lives.
The RLS one is the sharper of the two, because fail-closed isn't only lucky — it's the direction that hides. A fail-open leaks and someone eventually notices. A fail-closed returns nothing, which looks exactly like a user who hasn't added anything yet. So the safe failure is also the one that buys the longest silence, and "safe" and "discovered" end up pulling in opposite directions.
The captcha one is a class I hadn't thought about properly: two halves of a single change living in two systems, neither of which knows the other exists. And the reason it's worse than the server version is almost administrative. A deploy leaves a commit — an author, a timestamp, a diff, something to point at. A dashboard toggle leaves nothing. You can diff a filesystem. You can't diff a settings page you clicked three weeks ago.
Which makes the second-deploy problem platform-independent, and I'd had it filed as a VPS thing. It isn't. It's state that outlives the change that set it, and managed platforms don't remove that, they just make it invisible in a different way — no SSH to blame, and no artifact either.
One back at you: does anything on that side record a dashboard change? An audit line with who flipped what, and when. If not, that's a strange gap for a platform sold on getting you out of ops.
The trust problem feels more interesting than the automation itself here.
Curious whether users are more concerned about what the agent can change, or about what it might miss while telling them everything is fine.
My read is that they aren't competing — they're sequential.
"What can it change" is the loud one, and it's the fear people have before they've used it. It also resolves inside a single interaction: you ask for something, you see the literal command before it runs, and nothing happens until you say go. For the irreversible ones it tells you in plain English what you'd lose, so answering that fear doesn't require you to be able to read shell.
"What might it miss while telling me it's fine" is the one that survives that, and it's harder for a structural reason: it has no moment. A change you didn't want announces itself. A check nobody ran feels exactly like everything being fine — there's no notification for an absence. Which is why the interesting design question isn't how confidently to say done, it's how to make what wasn't checked as visible as what was.
Worth saying the numbers behind that are small — it's from conversations and threads like this one, not a dataset. If you've built anything agentic, I'd like to know which way it went for your users. I'd have guessed the first fear dominates, and it doesn't seem to for long.
Just sent you an email, Igor. Thought it’d be good to continue this conversation there.