A few weeks ago Jessica Wachtel wrote in The New Stack that the default question in boardrooms is shifting from “what should we buy?” to “can we just build this?”1 She wasn’t speaking rhetorically. Her piece documents engineers and product managers using Claude Code to build bespoke tools that nobody was going to ship as SaaS: a content workflow at PointFive, a product-management dashboard at Livesport, the exact shape of automation that used to require a team of three and six months. Taylor Houck at PointFive summarized it with a line that probably deserves to be the quote of the year: “I gave Claude the AWS credentials, and it did all the deployment for me.”
David Hsu at Retool has been making a version of this argument since before LLMs made it cheap: that the build-versus-buy decision isn’t about capability, it’s about cost. The argument has finally caught up to reality. Internal tools that used to be economically unviable are now viable. Personal tools that only one person needed are now viable. Tools that a team shares but nobody would sell are viable. The barrier was cost of construction; AI coding tools moved that barrier.
The trend is real. I don’t need to re-argue it; the evidence is in the pieces being built. But every tool that gets built has to run somewhere and talk to something, and that layer, reachability, is the part the conversation hasn’t caught up to yet. Wachtel’s piece waves at it in passing (“Claude even deployed the application”) and moves on. It’s the kind of glossing that happens when a problem feels solved because the demo worked. Reachability isn’t solved. It’s just not where the conversation is looking.
So: here is the argument. Personal software is real. The reachability layer underneath it is under-served. The under-serving has a specific shape, and the fix has three specific design commitments. I’ll make the case and then briefly mention what we’re building at Airdress, which is one attempt at it.
Where personal software actually lives#
There are two parallel conversations about personal software in 2026, and both are doing good work.
The practitioner lineage is Wachtel’s piece and its kin: commercial, case-study-driven, AI-coding-tool-centric. David Hsu’s Retool blog is a canonical precursor. Ondrej Machart’s “Lessons From 13 Claude Code Projects That Changed My Product Manager Role”2 is one more example. The framing is economic: bespoke software is newly affordable, therefore it will proliferate.
The researcher lineage runs further back and further sideways. Ink & Switch’s “Malleable Software” essay from June 20253 is the current flagship, a direct descendant of their 2019 “Local-First Software” essay,4 and explicitly modeled on it. Geoffrey Litt’s 2023 “Malleable software in the age of LLMs”5 is the bridge piece between the 2019 vision and the LLM era. Simon Willison amplified and extended the argument6 in 2025. The framing is about user agency: the wall between end-user and programmer is dissolving, therefore software can finally become yours.
Both framings are circling the same phenomenon. They don’t cross-cite much (the lineages live in different publications, with different authors, and apparently different reading lists), but the underlying observation is the same: people are now building software for themselves. What one lineage calls cost-collapse the other calls agency. The thing getting built is the same thing.
Neither lineage says much about where that software runs, because that’s the part that’s supposed to be solved.
Some personal software does run on AWS Lambda. Wachtel’s examples do. For a webhook-triggered workflow that processes a CMS event or dispatches an email, Lambda is a good answer. Some personal software runs on the user’s own hardware: a local RAG tool over their Obsidian vault, an MCP server backing their IDE, an agent that triages email, a Home Assistant instance talking to a dozen local sensors. Some spans both: a cloud-fronted webhook receiver that hands work to a local GPU for the actual LLM inference, because running a 70-billion-parameter model on Lambda isn’t going to happen. The deployment shape isn’t one thing. That’s the point. Personal software lives wherever it needs to live, and the needs vary.
The reachability layer doesn’t care about any of that — except that it has to work across all of it.
What reachability actually means for personal software#
If you build a tool, you probably want it to talk to something. A webhook receiver needs a stable URL that external senders can find today, tomorrow, and next month, with HTTPS that doesn’t break when a caller’s TLS validation gets stricter. An MCP server needs persistent HTTPS connections that survive the half-hour mark, because MCP clients reconnect on errors and assume the endpoint stays put. A tool-call handler needs to accept callbacks from wherever the agent originated: Claude Desktop on your laptop, a cloud-hosted agent on someone else’s Kubernetes, or another instance of the same tool running on your second device.
Reachability is just the property that all of those callers can reach the right handler. Written down like this, it sounds trivial.
It isn’t trivial, because personal software by definition doesn’t look like a SaaS deployment. There’s no load balancer with a DNS entry pointing at a fleet of homogeneous replicas behind a web application firewall. There might be one box. There might be two boxes, one of which sleeps when you close the laptop. There might be a box at home and a Lambda that fronts it and a GitHub webhook sender that doesn’t know either exists. The caller is often a SaaS service that retries once, or not at all; if your one box is down, the event might be gone. The hosting patterns written for 12-factor SaaS apps don’t map onto this directly, because personal software isn’t a 12-factor SaaS app. Calling it one is forcing a shape onto it that it doesn’t have.
Where the current options each solve part of it#
ngrok is the fastest way to get a public URL pointed at localhost that has ever existed. For a demo, a workshop, or a single-dev prototype, it’s still the right answer. Its free tier has tightened. As of April 2026, the bandwidth cap is 1 GB/month, and the interstitial warning page breaks programmatic callers that don’t know to set the skip header. The pricing also scales badly for teams. Those are shape problems, not quality problems.
Cloudflare Tunnel is the best free option for a single agent box with a stable uplink. The DNS integration is clean, the documentation is among the best in the industry, and the Zero Trust identity model is genuinely useful when it fits the team. Its architectural model is one connector group per hostname, which is fine for one machine and is the thing you outgrow when your agent runs across two. “Multiple cloudflared processes” is not the same as “multiple agent nodes”; the tunnel terminates at the same hostname with the same backend expectation, and the failover story personal software actually needs isn’t this one.
Tailscale Funnel is the cleanest UX in this space. One command, public URL, done. It works only on ports 443, 8443, and 10000 (by design, not configuration), and every caller is either another Tailscale device or goes through one exposing node at a time. For a Tailscale-native team whose callers are mostly inside the tailnet, that’s an unbeatable experience. For anyone else, the port restriction and the single-node exposure narrow the use cases.
Self-hosted tools like bore, inlets, and frp trade control for operational cost. They’re great if you’re the kind of developer who already runs Prometheus as a hobby. They’re a lot if you aren’t. And most of them don’t solve failover at all; that’s a separate architecture problem you put on top, usually with a load balancer and some health-check glue.
Each of these is the right answer for a specific shape. Where they fall short isn’t quality — it’s that personal software creates shapes none of them were designed for, and particularly the multi-device shape. A tool that runs on your GPU tower during the day and hands off to your laptop when you travel. A webhook receiver that fronts a Lambda for the easy cases and a local handler for the streaming ones. A personal software stack that moves between deployment shapes as the use case evolves, without rewiring the URL or re-pointing the DNS every time something changes.
That’s the gap. None of the current options were designed for a world where the thing behind the URL is not a fleet.
When personal software reaches commercial scale#
In early 2024, Sam Altman told Alexis Ohanian that his tech-CEO group chat had a betting pool on the first year there would be a one-person billion-dollar company: “unimaginable without AI and now will happen.”7 At Anthropic’s Code with Claude conference in May 2025, Dario Amodei answered a question about when such a company would appear with “2026,” at 70-80% confidence.8 In April 2026, the New York Times published a profile by Erin Griffith of Matthew Gallagher, a founder in Los Angeles who built Medvi (a GLP-1 telehealth startup) from $20,000 and a stack of AI tools into a two-person operation on track for $1.8 billion in revenue.9 The piece positioned Medvi as the first example of what Altman had predicted.
Then the story complicated.
Six weeks before the NYT profile ran, the FDA had already sent Medvi a warning letter for misbranding compounded drugs. A class-action lawsuit was filed in California alleging the company benefited from affiliate spam. Techdirt ran a piece titled “The New York Times Got Played By A Telehealth Scam And Called It The Future Of AI.”10 Commentators noted that the before-and-after customer photos on Medvi’s site appeared to be AI-generated deepfakes. The NYT itself later appended a correction to the profile:
After this article was published, many readers noted that Medvi was facing legal and regulatory actions for its business practices. Our piece should have included that information to give readers a fuller picture of the scrutiny that the company was facing. We have updated the article to note a warning letter from the F.D.A. and a pending class action lawsuit accusing Medvi of violating California’s anti-spam law.
Whatever Medvi turns out to be, it’s not a clean proof point. The trend Altman and Amodei described is real. AI coding tools are collapsing the labor cost of bespoke software construction faster than most people expected. But the first canonical example is contested, and the next examples are coming regardless.
What the Medvi complication actually shows is the shape of the new failure modes. When you collapse a $401M operation to two humans plus a constellation of AI agents, the single-point-of-failure surface gets bigger, not smaller. Regulatory compliance, customer-service authenticity, content integrity, infrastructure uptime — all of these become the founder’s problem without the institutional scaffolding a 200-person company has. You don’t get to hire a compliance team, a QA team, and an SRE on-call rotation. You are those functions, and so is every agent you’re renting.
Infrastructure reliability is just one of those problems. It’s the one this piece can say something useful about. It’s also the one nobody writing about the one-person company story is engaging with. Every piece I read frames the trend as labor-cost collapse and moves on. The layer underneath is uncovered territory.
What the Mac Mini shortage tells us#
The one-person billion-dollar company is the commercial endpoint of personal software. The consumer endpoint is already here, and the leading indicator is Mac Mini inventory.
In spring 2026, Apple’s $599 Mac Mini sold out across China. Apple Store shipping times stretched past a month. At Huaqiangbei, the Shenzhen electronics bazaar, multiple booths completely depleted inventory, and the base-config secondhand markup hit 500 yuan. The driver was an open-source project called OpenClaw11: a personal AI agent that connects to any LLM backend, runs on your own machine, and messages you via WhatsApp, Telegram, Slack, or iMessage. The project passed 214,000 GitHub stars in early 2026, and Nvidia’s Jensen Huang told CNBC in March that it is “definitely the next ChatGPT”.12 Chinese users coined 养龙虾, “raising a lobster,” for the ritual of setting one up. Tencent ran install parties at their offices. Retirees set them up for side projects.
Why Mac Minis specifically? The ARPU newsletter puts it sharpest: “That is what the Mac Mini represents: a $599 air gap. A cheap, physical sandbox where an agent can browse, click, hallucinate, or corrupt data.”13 Nobody wants to give an autonomous agent root on their primary machine. A Meta researcher’s OpenClaw famously deleted her emails despite explicit instructions to confirm first. So buyers shell out for a dedicated box: always-on, low power, physically isolated. Personal software on personal hardware, in the most literal form that phrase has ever taken.
ARPU’s deeper point is that this buying pattern changes what valuable AI even looks like. “The commoditization of the brain in real-time,” with the LLM reduced to a replaceable engine inside a machine the user owns. That’s a product-strategy argument. Underneath it is the infrastructure argument this piece has been making. Once the agent lives on your Mac Mini, the next problem is how it stays reachable: when the Mini reboots, when you travel and need the agent to keep handling webhooks, when your parents’ Mini is the fallback, when Telegram needs to reach you and your primary box is offline. That layer doesn’t exist yet. Not because people aren’t buying the hardware.
Three commitments for the layer personal software needs#
If I’m arguing reachability is under-served, I owe you a specific claim about what the under-serving looks like. Three things the layer should do, none of which is currently table stakes:
Open protocol. The reachability layer needs to outlive any single vendor, because personal software’s whole premise is user agency. A closed protocol underneath personal software recreates exactly what personal software is trying to escape. WireGuard is the obvious answer: audited, portable, broadly understood. The alternative is a bespoke protocol defined by one company and operated by one company; that’s a fine choice for a SaaS product, but it’s the wrong foundation for infrastructure you expect people to trust with their personal tools. At solo-founder scale this is also a continuity property: a fifty-person company can absorb a vendor deprecation by assigning engineers to the migration. A two-person company cannot.
Provider-independent. Users should keep DNS where they want it. Users should keep identity where they want it. The reachability layer should not require adopting a new DNS provider, a new identity provider, or a new app-platform account. It should plug into what’s already there. Every time I read a vendor’s setup guide that begins with “first, move your domain to us,” I close the tab. The user wanting to reach their own software across their own hardware should not be the moment they’re asked to transfer their nameservers. At solo-founder scale it also means no single provider outage can take the whole company offline. When you are the only human in the incident channel, a dependency needs to fail over automatically or not fail at all.
Failover by default. Personal software that carries real responsibility (driving workflows, receiving payment events, mediating between agents and services) can’t fail silently when one device sleeps. A single-device setup is fine for a hobby. It’s a bad default for anything that has to be there tomorrow. And the question is load-bearing: failover across devices (and therefore across network paths and deployment shapes) is what lets personal software span cloud and local at all. Without failover, “multi-device personal software” collapses back to “pick one device and cross your fingers.” That’s not a failure of engineering; it’s what happens when the reachability layer was designed for single-box developer tools and people started using it for real work. At solo-founder commercial scale the stakes are sharper still: it’s the difference between “revenue event” and “customer notices briefly.” Failover at the infrastructure layer is the cheapest substitute for the things traditional companies buy with payroll: an on-call rotation, an SRE team, a second person who happens to be awake when you aren’t.
None of these commitments is radical. But none of them is built into the current options. Each of them is an afterthought, a premium tier, or a separate product you bolt on.
What this might look like#
I don’t want this piece to turn into a product tour, so I’ll keep this concrete and short.
A reachability layer with those three commitments looks roughly like this:
One public hostname. Three possible handlers behind it, across three different deployment shapes. The relay health-checks them and routes traffic to whichever is healthy. Your DNS stays with your DNS provider. Your identity stays with your identity provider. The protocol underneath is WireGuard. When the GPU box reboots, traffic continues; when the Lambda dispatcher has a bad deploy, the laptop takes over; when your laptop sleeps, Lambda handles the fast paths until the laptop wakes up. The caller on the public internet never sees the handover.
This isn’t a speculative architecture. It’s roughly what we’re building at Airdress, which is in private beta as of April 2026. End-to-end failover isn’t working cleanly across every configuration yet. That’s the honest current state. But the shape is the point, and the shape is what I think the current conversation about personal software is skipping.
What this architecture enables, once it’s reliable, is the class of personal software that isn’t being built today because nobody wants to debug hosting. A personal agent you can actually trust with calendar management, because it doesn’t go silent when the laptop sleeps. A homelab tool that federates with a cloud-hosted tool. A bespoke workflow that runs mostly on Lambda but falls back to local compute when the cloud region has an outage. That set of tools is the second half of the personal-software story. The first half is “we can build it cheaply now.”
What I’m not saying#
Before someone writes a rebuttal, a few things this piece is explicitly not claiming.
I’m not saying AWS Lambda is wrong. It’s right for exactly the workflows Wachtel describes: webhook-triggered, stateless, cloud-native. I use it myself for things that fit that shape, and I’ll keep using it.
I’m not saying every personal tool needs failover. Plenty are fine single-device, and plenty will always live entirely in the cloud with no local component at all. Failover matters when the tool matters. Not every tool matters equally; that’s why failover should be a built-in capability, not a required feature.
I’m not saying Cloudflare Tunnel, Tailscale Funnel, and ngrok are bad. They’re good at the shapes they were designed for. The critique here isn’t quality; it’s that personal software creates shapes they weren’t designed for, and building something for the new shapes is a different problem than improving the existing tools.
I’m not saying the personal-software conversation is uninformed. The people writing about this (practitioner and researcher both) are sharper than the infrastructure people they’re implicitly leaving to solve the next layer. I’m writing this from the other side, the infrastructure side that has to catch up.
I’m not saying Medvi is the template for what comes next. The Medvi story is still unfolding and several of its details have complications the initial NYT profile didn’t cover. Treat Medvi as a data point about the trend’s arrival, not as an endorsement of the business. The infrastructure argument here doesn’t depend on Medvi specifically being a good company; it depends on the pattern (more one-person or two-person businesses running at commercial scale), which is coming either way.
What I am saying: reachability is a first-class requirement for personal software, it spans deployment shapes from Lambda to homelab, and the layer that provides it should be open, provider-independent, and failover-capable by default. That’s a more specific claim than the conversation is making right now, and making it specific is how infrastructure actually gets built.
An invitation#
If you’re writing about personal software from either lineage (the Wachtel side or the Ink & Switch side), I’d love to read a piece on reachability from your angle. If you think I’m wrong about the three commitments, I’d love to read that one more. The thing Ink & Switch did right with the Local-First Software essay in 2019 was stake a claim specific enough that people could respond to it; I hope this piece works the same way. Respond by writing more, or by building something, or by pointing to prior art I missed. That almost certainly exists, because the internet is large and I have read a small fraction of it.
Airdress is in private beta. If you’re running personal software that has to stay reachable across devices, and the three commitments above match what you’d want from the layer underneath, join the waitlist. If you’re just writing about this space, I’d love to read what you publish regardless of whether the waitlist is relevant.
Footnotes#
-
Jessica Wachtel, April 15, 2026, The New Stack — Claude Code and the Rise of Personal Software. The piece that anchored this one. ↩
-
Ondrej Machart — Lessons From 13 Claude Code Projects That Changed My Product Manager Role. ↩
-
Ink & Switch, June 2025 — Malleable Software. Current flagship of the researcher lineage. ↩
-
Ink & Switch, 2019 — Local-First Software. The foundational essay both strands trace back to. ↩
-
Geoffrey Litt, March 2023 — Malleable software in the age of LLMs. Bridge piece between the 2019 vision and the LLM era. ↩
-
Simon Willison, June 2025 — Malleable software. Amplification and commentary. ↩
-
Sam Altman’s “betting pool” quote, via Fortune, February 4, 2024 — Silicon Valley’s one-person unicorn myth. ↩
-
Dario Amodei at Anthropic’s Code with Claude conference, May 2025, via Inc. — Dario Amodei predicts the first billion-dollar solopreneur by 2026. ↩
-
Erin Griffith, The New York Times, April 2, 2026 — the Medvi profile (a Techmeme index helps locate it if you don’t subscribe). Read the original with its subsequent correction. ↩
-
Techdirt’s pushback on the NYT profile; and The Nation’s longer critique of the “high agency” framing. ↩
-
OpenClaw — Wikipedia. Project overview, origin, and timeline. ↩
-
Jensen Huang (Nvidia), CNBC, March 17, 2026 — “OpenClaw is definitely the next ChatGPT”. ↩
-
ARPU newsletter — OpenClaw and the Mac Mini shortage. Source of the “$599 air gap” and “commoditization of the brain in real-time” framings. ↩