Agent-built apps need expiry dates

SaaStr's latest operating dispatch is a genuine jaw-dropper: about 300 campaigns and ten years of member data migrated off Marketo for roughly $14.28 in model cost, against agency quotes of a year and $100K; a $10,000 app replaced in an hour; three humans running 21-plus production agents while each spends 8 to 12 hours a day building. First-party claims I can't independently verify — but even discounted heavily, the direction is unmistakable, and it produces a wall SaaStr names precisely: when building gets this cheap, the question stops being "can we build this?"

Here is the wall, stated as the arithmetic that will hit every organization that adopts these tools. Lower creation cost raises application count faster than it lowers the obligations each application carries. A $14 app is cheap to create. It is not cheap to secure, patch, support, classify, and eventually retire — those costs are the same whether the app took a year and $100K or an hour and pocket change. Cheap creation × unchanged lifecycle burden = an exploding population of small apps each dragging a full maintenance tail. That is not a productivity miracle if you don't manage it. It is shadow IT with a compounding interest rate.

Picture where this goes in eighteen months without a control: an engineering leader inherits dozens — then hundreds — of agent-built utilities, each of which someone made in an afternoon and forgot. No named owner. No patch path when a dependency gets a CVE. No data classification, so nobody knows which ones touch PII. No usage telemetry, so nobody knows which are still used. And no shutdown trigger, so none of them ever die. Every one is a small, permanent liability, and their number only grows, because creating the next one is still cheaper than auditing the last one.

The fix is a single discipline borrowed from good infrastructure practice: every agent-built app launches with an expiry date. Not a guess at when it dies — a review date, at which the app must produce evidence of continued use and a living owner, or it gets retired automatically. This inverts the default. Today an app created in an hour lives forever by inertia; nobody ever schedules its funeral. With an expiry, permanence must be re-earned on a schedule, which means the graveyard clears itself and only the apps that matter survive their first review. The expiry is the forcing function that converts "cheap to build" back into "accountable to run."

Concretely, three fields at birth and one automated job. At creation, every app records an owner (a human, not a team), a data classification (does it touch anything sensitive), and a review date. A scheduled job then does the unglamorous platform work the SaaStr-style dispatches skip: it inventories every agent-built app, maps dependencies and secrets, and on the review date pings the owner — still using this? still yours? — and retires, with secrets rotated, anything that can't answer. Inventory, dependency mapping, secrets rotation, and retirement automation stop being afterthoughts and become part of the agent platform itself, exactly as they had to for cloud resources a decade ago.

At work, the emerging pattern I now flag on day one of any "let everyone build with agents" rollout: fund the retirement machinery before the creation spree, because the creation spree needs no encouragement and the retirement machinery never gets built after the fact. The team that celebrates a hundred cheap apps and can't name who owns the eleven that touch customer data has not gotten faster. It has accumulated a breach with a delay timer.

When apps cost an hour to build, the scarce discipline is deletion — give every one an owner and an expiry date, or your $14 miracle becomes your unowned attack surface.