Cursor, which developers use to write code with AI agents, can now take a plain description of a work tool and deliver a finished web app. Its agent builds the app, creates a Postgres database if one is needed, adds a login, and hosts it at an address you choose. It is available on all paid plans that include cloud agents.
The code was never the obstacle
An app that an AI writes for you usually runs only on your own computer, which developers call localhost. For a colleague to use it, someone has to rent a server, set up a database, build a login and keep passwords out of the code. Those four jobs are where most homemade tools died, and they are the jobs Cursor's agent now does. The examples from Cursor's own staff are ordinary ones: event registration, desk seating, account assignments, live sales dashboards and onboarding for new hires.
ChatGPT Sites already gives ChatGPT users the same finish, and it passed 5 million sites in three months. What Cursor adds is the starting point. It works from new or existing code on GitHub or Cursor's own code hosting, so a tool that a sales manager starts can later be picked up by an engineer.
A shift manager at a distributor could describe a dock-booking tool: dispatchers enter each delivery slot, the app keeps the bookings in a database, and a board shows the day's arrivals. Until now that was a shared spreadsheet that people overwrite, or a request to IT that waits in a queue for weeks. Now it is an afternoon of the manager's own time. The decision the agent cannot make for them is who may open it. Team apps are shared only with people who have Cursor accounts, and public links are limited to individual plans, so a tool for suppliers or customers is a different decision from one for colleagues.
The hole only shows to a stranger
The Lovable apps failed in a way their builders could not see. The person who made the app is logged in, so everything works. The gap appears only when someone who is not supposed to be there asks for the data.
Cursor runs fixed rule checks and an AI review of the code when you publish, aimed at common problems like secrets saved in app files and exposed credentials. If a check fails, the agent says what to fix, and nothing goes live until the checks pass and you press publish. Whether those checks also catch a database that strangers can read is the thing to test, because that is the mistake that actually hurt people before.
Visibility matters more than any single check
For a company, I think the admin side matters more. Admins can see every app and every secret on the team, add their own rules to the review, approve a publish the review blocked, and take any app down. A spreadsheet on someone's personal drive never came with that. When staff build tools freely, the larger risk is not one bad app. It is nobody knowing which apps exist, who relies on them, or who built them and has since left.
So the work that grows is owning, not building: a name beside each app, a date to review it, and someone who can switch it off. Cursor gives administrators the switch. Deciding who holds it is the company's job.