Suppose a ten-person team is running a three-day client workshop. They need to collect topics, claim time slots, upload handouts, and track who still has not filled out the form. In the past, nobody would hire an engineer to build a web application for a three-day workflow. Just setting up the repository, database, permissions, and servers would take longer than the event itself. Teams would cobble together a temporary tracker using shared spreadsheets, docs, and forms, then assign someone to chase people in the group chat and reconcile the data by hand.
As the cost of both writing code and hosting deployments has dropped, that cost structure has shifted. Today, you can describe the fields and logic in plain language inside a chat window, get a live web app with a database and login in a few minutes, and drop the link straight into a group chat. Software has gained a disposable software layer. Because the marginal cost of writing code, shipping it, and keeping it running is now close to zero, building a dedicated tool for a single decision or a short-term collaboration has become cheaper than maintaining a spreadsheet by hand. Just as shared online docs replaced the habit of printing out rough drafts to pass around the office, user-generated software is replacing the need to scope and schedule engineering projects for small workflows.
Some might ask whether Tencent Survey plus a shared spreadsheet is already good enough for this kind of workflow. If all you need is a sign-up list, a survey form is fine. What it cannot handle is the coordination after the responses come in: who claimed which time slot, what happens when two people pick the same slot, where handouts get uploaded, who still has not responded, and when to send reminders. Once states multiply, spreadsheets and group chats fall right back into manual reconciliation. A survey collects answers; disposable software takes over the coordination that follows, replacing both the spreadsheet someone has to babysit and the endless back-and-forth in the group chat.
When engineers talk about these products, two doubts usually come up. First, it feels like nobody around them is actually using these site builders. Second, it looks like big tech companies are only jumping in to chase hype rather than serving real demand. Both impressions come from a change in how software is distributed. In everyday collaboration, the person sharing a link does not announce which platform built the site. People open a URL in a WeChat group, fill in their information, and close the tab. The experience feels no different from filling out a Tencent Survey. Nobody filling out a form thinks of themselves as a user of the survey platform, and coworkers clicking into a small tool do not notice the site-building platform underneath. The creator might generate a page only once or twice a month, while all the follow-up interaction happens inside that shared link. This use-and-leave distribution creates the illusion that nobody is using these tools. Disposable software is not a future trend. Among people willing to pay for AI, it is already part of daily work, even if nobody thinks of it as software.
This observation is not new. In November 2025, we wrote Beyond DRY and Disposable Software: the former argued that software deliverables would shift from finished artifacts to generative kernels, and the latter argued that building a dedicated tool for a single decision would become economical. At the time, this read more like an early projection. Tools were scattered across standalone platforms, and nobody could say when or through whose entry point the pattern would go mainstream. A year later, ChatGPT Sites has turned site building into an everyday action inside chat, and Lovable’s subscription revenue has proven that individuals will keep paying for small tools like these. The market is now validating that projection.
Running a conversational site-building platform involves more complex economics than running traditional software. Traditional software usually serves a single buyer persona, whereas conversational site builders face three distinct groups of payers at once: long-tail individual users, enterprise procurement teams, and professional developers. Alongside those three buyers sits a fourth ledger, the platform’s own business model. Put all four ledgers together, and each party is paying for something completely different while refusing to pay for different things.
Long-tail individual users are buying convenience. Their mental benchmark is a shared spreadsheet like Tencent Docs. They do not know where the database lives, do not care how servers are maintained, and expect the platform to fix anything that breaks. They pay for peace of mind, not underlying infrastructure reliability. The moment these users see resource quotas or operational settings, they leave rather than learn. Lovable has reached $400 million in annualized recurring revenue, with roughly 95% coming from monthly subscriptions by individuals and small teams, showing that the long tail is a massive business in its own right. To make the unit economics work on low-priced monthly plans, a platform has to drive down per-user support costs, hide operations, backups, migrations, and quotas completely, and cover both generation and hosting costs within a very small ticket size.
Enterprise procurement teams run a different calculation: they are buying governance. The backend details that annoy individual users are hard compliance gates inside a company: identity authentication, permission isolation, data residency, internal network connectivity, and audit logs. Missing even one of these will sink a security review. Enterprises will sign high-value contracts for that control, but they will not pay extra just for faster code generation, because without a compliance foundation, no front end can go live internally no matter how fast it is generated.
Professional developers are buying an exit right. Where enterprises want the platform to manage the entire environment, developers guard against getting trapped in a black box. Before writing a prompt, they check the exit path: whether they can export the full source code, migrate data cleanly, and plug the project into their existing continuous integration (CI) pipelines and cloud accounts. Developers will pay to avoid lock-in, not for closed hosting. If they see that code or data cannot leave the platform, they walk away before starting.
The fourth ledger is the platform’s own business model. It governs what the platform is willing to guarantee rather than what a customer buys. Selling per-account subscription seats, per-project site quotas, or usage-based compute creates three revenue structures with different tolerances for reliability costs. Seat-based pricing relies on light users to average out heavy ones, quota-based pricing ties revenue to the generation step, and usage-based pricing charges for actual resource consumption. Depending on how it makes money, a platform can afford to shoulder very different levels of reliability guarantees.
When you look at all four ledgers together, it becomes clear why platforms rarely provide production-grade guarantees by default. The reason is not technical; it comes down to who is willing to pay for reliability. Individual users will not pay extra for it, so if a platform bundles full operational guarantees by default, it only inflates its own support costs. Only enterprise customers integrating these tools into formal business workflows are willing to pay for permission governance and reliability assurances. Following the split between individual and enterprise willingness to pay, conversational site builders naturally diverge in product direction.
Over the past four years, disposable software has evolved through four stages. Each generation of products filled a gap left by the previous one, and the engineering trade-offs made to fill that gap spun off a distinct product path. Scoring today’s site builders on a flat feature checklist misses the real storyline. Environment setup and code templates, which used to trip up non-engineers, have sunk into the infrastructure layer as scaffolding has become a commodity, and no longer serve as a moat. What actually separates vendors is how each generation answers three questions of platform state ownership: whose infrastructure runs the code, where the data lives, and who provides visitor identity. Different answers lead to different product paths.
The first stage was document tools, represented by Notion, Airtable, and Google Sheets with scripts attached. Traditional documents could only display text and images without recording state changes or supporting interaction. This generation added read-write state and interactivity, letting non-technical users build small tools, trackers, forms, and simple approval flows. Yet it still demanded engineering thinking: users had to design table schemas, define role permissions, and configure automation rules themselves. Once a workflow grew complex, maintaining tables plus scripts started to look a lot like traditional software development.
To solve that pain point, the second stage moved to chat artifacts, exemplified by the front-end generator v0 and Anthropic’s Claude Artifacts. Users describe what they want in natural language inside a chat box, and the model writes front-end code that renders an interactive web interface right next to the conversation, complete with one-click link sharing. This step bypassed the tedium of designing fields and dragging layout components, using natural language to clear the UI hurdle. However, pure front-end previews introduced a new limitation: the pages had no database behind them, no real user login, and no version history or deployment lifecycle management. Without a backend, these front-end previews could not support multi-user workflows that needed shared, persistent read-write data.
The third stage brought standalone full-stack platforms, led by Bolt.new, Lovable, Replit Agent, and Manus. They closed the gap on persistent data storage and user authentication, with Manus also adding built-in analytics, custom domains, and version rollback. Facing the same backend and data gap, different platforms chose different ways to fill it, splitting into distinct architectural paths.
The first path hides the runtime and storage directly behind the chat platform. For example, ChatGPT Sites partners with infrastructure provider Cloudflare to run generated web apps on Workers, an on-demand serverless compute environment, paired with a lightweight relational database and object storage bound through configuration files. Publishing is split into two steps, saving a candidate version and swapping it in place at the existing URL, so users barely notice any underlying operations.
The second path glues together established backend services. Lovable Cloud builds on the open-source backend platform Supabase, pre-configuring the database, authentication, storage, and edge functions while still allowing users to connect their own self-managed projects. Bolt Cloud includes a built-in relational database and authentication, and also supports connecting to that same open-source backend. Google’s Firebase Studio stays entirely within its own ecosystem, using Gemini to generate applications that wire directly into Google’s hosting and authentication services.
On the identity side, the online coding platform Replit offers Replit Auth, which lets users sign in with their Replit accounts or swap in the third-party identity service Clerk. OpenAI provides Sign in with ChatGPT as an identity layer suited for public sites. It supplies sign-in and sign-out buttons and, after verification, passes the visitor’s name and email to the server in request headers for permission checks. That allows a public site to remain open to signed-out visitors while offering personalized features once someone signs in.
Delivery boundaries also split into two directions. The front-end cloud platform v0 generates Next.js source code for one-click deployment into the user’s own Vercel account, leaving authentication to Clerk or NextAuth rather than hosting identity itself, which makes it easy for engineering teams to take over maintenance. Shenzhen startup YouWare went toward community distribution, using feeds and social mechanics to turn generated web pages into browsable, remixable content.
Standalone full-stack platforms solved databases and login, but they quickly hit a wall in enterprise adoption: they sit outside a company’s existing org chart and daily work entry points, requiring extra database setup or account registration for every internal tool, which makes them hard to weave into everyday workflows. That pushed the industry into a fourth stage, where incumbents that already own the chat entry point and enterprise directory stepped in to absorb full-stack hosting into their own workspaces. Anthropic upgraded chat artifacts into enterprise-hosted applications running on its own infrastructure and connected directly to multiple internal enterprise data sources. OpenAI opened the ChatGPT Sites public beta this July and launched the general enterprise release in the fall, featuring five audience permission tiers, site-level scheduled updates, site plugins that read visitor-authorized data, and private internal network tunnels. Measured by deployed sites disclosed at OpenAI DevDay, the platform now hosts 8 million sites. Meanwhile, the next generation of Manus, a general agent platform, added background execution through paid always-on cloud computers and event triggers, supporting round-the-clock automated tasks triggered by events from email, ad data, calendars, the messaging tool Slack, or collaborative docs in Notion. After less than a year in preview, GitHub Spark stopped accepting new users and new app creation in August 2026. Earlier, traditional website builder Wix acquired Base44 in mid-2025. At this stage, an existing organizational identity graph and always-on background execution have become the real platform moats.
Looking back across these four stages, the diverging product paths map directly onto the four ledgers discussed earlier: individuals want convenience, so they pick fully managed hosting; enterprises need governance, so they pick platform identity, data residency, and internal network access; developers want an exit path, so they pick code ownership; communities want distribution, so they pick social feeds. Once you see that mapping, the criteria for evaluating any specific product become straightforward.
Code generation across foundation models has largely converged, and every vendor can produce an impressive demo in the first minute. Whether a tool is still usable three months later and fits into a team’s workflow no longer depends on that first screen. It depends on who controls three layers: identity, data, and runtime.
First is identity. Tying identity to an enterprise chat workspace or coding platform account makes internal collaboration effortless, but it subjects external visitors to the platform’s rules. For instance, ChatGPT Sites currently lacks access passcodes, email domain restrictions, or link expiration, and unregistered users can only visit fully public sites. Platforms built on Supabase or Clerk let you run your own user system. Second is data. When a platform supports connecting a self-managed database, external tools can read, write, and back up the data directly. In ChatGPT Sites, version rollback restores only the code, not the database or uploaded files, and if a deployment fails, the database may already be partially written. Third is runtime and automation. ChatGPT Sites has two separate gaps here: it has no public publishing or management API, so you cannot embed site creation into an external pipeline the way you can with Manus, and it has no official documentation for exporting a project.
Translating those three layers into a practical selection checklist comes down to asking three questions before you start building. First, who are the visitors? If a dozen coworkers are collaborating internally and the team already pays for an enterprise workspace, built-in hosting is the easiest path, since existing permissions and private network tunnels save most of the approval overhead; if the tool is going to external clients, it should not require a specific vendor’s account. Second, will you need to migrate it later? A three-day workshop tool for collecting topics will be thrown away when the event ends, so platform lock-in costs nothing; if it is an early prototype meant to be handed off to engineers for ongoing iteration, you should start on day one with v0 deployed to your own cloud account, or attach a self-managed database to a standalone platform. Third, do you need always-on background execution? Based on public documentation, site-level always-on or scheduled execution is still uncommon; if your workflow needs to monitor emails around the clock, pull data on a schedule, or trigger automated jobs, verify up front whether the platform supports site-level scheduled tasks, or choose an agent platform that offers a paid always-on environment. Once you clarify who owns these three layers, you can spot the real boundaries of any new product that enters the market.