Cursor shipped something last week that I think matters more than its fairly modest announcement suggests. You can now build live web apps in Cursor and share them by link: a cloud agent scaffolds the app, provisions a Postgres database if it needs one, puts it behind the company’s sign-in and hosts it. Publishing runs security checks (exposed secrets and the likes), and team admins can review, approve or unpublish anything. Their own line about it is the one that stuck with me: “most apps and tools that users build never make it off of localhost”.

Look at the examples Cursor gives of what their own staff built with it: ops tools for event registration and desk seating, onboarding and training experiences, live pipeline dashboards for the sales team, portals for managing engineering services. Read that list again and tell me it doesn’t look like a chunk of a typical company’s SaaS bill.

Localhost Was the Real Moat

Here’s the thing: for the last couple of years, building a small internal tool with AI has been easy. Running it has not. Somebody had to find a server, set up a database, wire in single sign-on, worry about secrets, and then keep the thing alive. That “last mile” is exactly why a team that wanted a simple desk booking tool ended up paying for a per-seat SaaS product with forty features they’d never use. The SaaS vendor’s real moat was never the software; it was the hosting, the login screen and the fact that nobody in-house wanted to be on call for it.

Tools like this one chip away at that moat from the bottom. When “build it and put it behind our SSO” is a prompt and a publish button, the maths of buy versus build changes, even more so for the small, specific tools where the off-the-shelf product never quite fitted your process anyway.

Where I Think This Goes

I believe SaaS products get replaced by in-house tools wherever the pricing is high. Not the hard stuff (nobody sane is rewriting their payments platform over a weekend), but the long tail of per-seat products that do one simple job and charge for every head in the building. And per-seat pricing is already in trouble for a separate reason: when one person runs ten agents, charging per human makes no sense whatsoever. Put the two together and a lot of renewals next year are going to be uncomfortable conversations (for the vendors, mostly 🙂).

Don’t get me wrong, this isn’t a free lunch. Every internal tool is software someone has to own. I keep seeing companies end up with a graveyard of half-finished internal apps, each built by someone who has since left, each holding some data nobody can find. AI makes building faster; it doesn’t make maintenance disappear. If anything, it makes the graveyard grow faster too.

What I’d Tell a CTO on Monday

So here’s how I’d approach it. First of all, pull the list of SaaS subscriptions and sort them by cost per actual user, not cost per seat. The expensive, lightly used, single-purpose ones are your candidates. Secondly, set some house rules before the flood starts: every internal app has a named owner, a repo, a review step, and a “delete me” date if nobody uses it. Cursor’s admin controls help, but governance is a habit you build, whatever the tool offers. And last but not least, pick one tool and actually replace it, end to end, so your team learns what the real cost of ownership looks like before anyone gets carried away.

As a side note, this is also a quiet but big step for my favourite argument: that the factory matters more than the code. The code for a desk booking app was never the hard part. The pipeline that gets it safely from a prompt to a live, secured URL is the hard part, and that’s what Cursor just productised.

Bottom line: the next time a vendor sends you a price rise for a tool your team uses twice a week, you’ll have a genuine alternative. I suspect a lot of vendors haven’t priced that in yet.