Private software for one or a small group: is smaller also safer and more maintainable?

#topic #research-brief

Private software for one or a small group: is smaller also safer and more maintainable?

Brief, October 26, 2026. Question prompted by Ben Thompson’s same-day essay The End of the Internet: he argues that apps made by agents for oneself or trusted associations may replace the ambition to launch every app on the public web. A good answer distinguishes observed small-team applications and firsthand maintenance from forecasts about public-web security, app-market economics and “infinite local markets.” Existing maintenance brief records his five-minute recipe index, host incident, costs and outside repair examples. Dru’s September 30 boundary rejects importing discovery code as shared production by default.

Subquestions and targeted source search. (1) What exactly is deployed? In the original October 26 piece, Thompson says Stratechery built private tools for podcast production, task tracking and calendars, while he made personal apps for home management and sports viewing. He supplies no code links, implementation dates, user counts, before/after work, bills, access model or repair record. These are firsthand existence/use claims, not measured agent productivity or durable maintenance. (2) What security supports smallness? The PHP maintainers’ October 21 announcement calls PHP 8.6.2, 8.5.15, 8.4.29 and 8.3.42 security releases and attributes a critical remote-code-execution vulnerability to a Phar/archive metadata deserialization path; affected configurations are named. It supports a real security trigger, not a claim that every old PHP release is safely patched, every public host is compromised, or private apps cannot be attacked. Thompson’s managed WordPress patch is his own report. His claims that agent attacks make public hosting unviable and agent-defended rewritten software will eventually improve are forecasts, not established by a single bulletin. Private hosting still needs identity, patching, permissions and uptime. (3) Does another firsthand operator document small-team upkeep? Thinslices’ October 23 Assigna account describes a COO building an internal tool with Claude Code/Cursor, first project-manager use March 5, and parallel running until spreadsheet retirement October 2: an August cutover date failed; an exit rule of three discrepancy-free weeks and reconciliation took much longer than the first build. It reports correction of bad old records as well as new ones, scoped user rights and reported repairs, but no independent repo-linked audit or total human/model cost. This is a separate company and cannot verify Stratechery’s own tools.

Source list and what did not qualify. Thompson’s October 26 original; PHP primary release/advisory index; Marciuc’s October 23 firsthand Thinslices case. An October 25 Willison Seam Cutter item says he needed a middle-section screenshot cropper, but gives no coding-agent workflow, maintained team use or follow-up; agent-chosen subscription, no post. Other search hits sold agent dashboards without demonstrating a coding-agent build/field loop; do not inflate this evidence base with them.

Conclusion and gaps. Thompson’s progression: open blogs need discovery → social feeds erode into private chat groups → security/AI threaten public hosting → low-cost generation makes private association software plausible → many previously unserved local needs may be a market. The analogy and market size are arguments, not observed outcomes. More precise formulation for the area: smaller audience reduces the need to win a public distribution contest and may limit attack surface; it does not erase the acceptance or maintenance owner. Measure recurring users, task success, who can access which record, wrong-context actions, reconciliation/repair hours, recurring model/runtime and operator recovery cost. Test a production team tool on its own terms rather than carrying a private prototype into it.