Glide Stopped Pretending the Drag-and-Drop Editor Is the Future: GlideOS Is Now the Whole Product

Glide has spent the last decade teaching non-developers to drag components onto a canvas and call it an app. That version of the product is now being retired. The company has rebuilt itself around GlideOS, an AI builder that turns a spreadsheet, a document, or a plain-English prompt into a working internal app, and it is pointing every new signup at that product. The drag-and-drop editor that made Glide famous still exists, but it is no longer the future. It is the past, and Glide is treating it that way.

This matters because Glide is not a startup gambling on a pivot. It is one of the most successful spreadsheet-to-app tools in the world, with a huge base of operators who learned to build precisely because the editor was forgiving. When Glide decides the editor is done, the rest of the no-code category should pay attention.

What actually changed

GlideOS launched in beta in early June, then got its full launch event at the start of August. The pitch is simple: upload a spreadsheet or describe what you want, and GlideOS generates screens, sample data, and the bones of an app in minutes. Every change after that happens through chat. You tell the agent to add a field, change a workflow, or restyle a screen, and it does it.

It is aimed squarely at internal business apps rather than consumer apps, which is a telling narrowing of ambition. GlideOS also absorbs the unglamorous work that used to sit outside the editor: hosting, authentication, and security come out of the box, and you can invite colleagues to build alongside you in the same team instead of passing screenshots back and forth.

Here is the part that matters for the headline. GlideOS has no visual editor. You can click an element to target it, but you change it by describing what you want in plain English, not by dragging it around. That is a deliberate break from the tool's own history, and it mirrors what vibe-coding tools like Bolt and Lovable have been doing on the coding side. Glide just dragged that model into the no-code mainstream.

Has Glide actually killed the drag-and-drop editor?

Not with a single announcement, no. If you go looking for a blog post titled "We are shutting down the visual editor," you will not find one. What you will find is a company that has stopped pretending the two products are equals.

Glide's pricing page now leads with the GlideOS rate card, metered in credits: Free, then $25 a month for 100 credits, $50 for 250, and $125 for a team plan with per-member credits. The classic flat plans (Explorer, Maker, Business) still live in the help centre, but new signups are funnelled to GlideOS. As one careful pricing breakdown put it, this is a company mid-migration to usage-based billing, with its marketing pointing forward while its documentation still serves the customers it has not yet moved.

For a builder on the old editor, the honest read is this: the visual editor is in maintenance, not in development. Glide has said existing Classic apps are unaffected for now, but "unaffected" is not the same as "invested in."

The credit meter is the real story

The editor change is the headline, but the billing change is what will actually hit you. GlideOS runs on a credit meter, and credits do not roll over.

A credit is not a dollar and not a seat. It is an abstraction that burns at a rate you can only observe after the fact. Build an app from a spreadsheet, and it costs credits. Ask the agent to restructure your data, more credits. Publish, invite users, let the app run, and the meter keeps turning. One GlideOS user in the community forum reported chewing through 50 credits in a couple of hours of iteration, which on the $50 plan is the entire monthly allowance. Another reported a redesign costing a couple of dollars in credits when they fed it through a design tool first.

That unpredictability is new for Glide customers. The old model was flat and boring: a monthly fee, a seat count, a predictable bill. The new model is metered, which means a heavy build month can cost real money you did not plan for. The rate card tells you the allowance, not the bill. If that makes you nervous, plan for it like any metered cost: build a prototype on the cheap tier, watch how many credits a representative build eats, then commit to a paid tier with headroom. The people who get burned are the ones who sign up for the sticker price and start iterating.

What this signals for the no-code category

Glide is the canary. For a decade, the pitch of no-code was "you can build it yourself, visually." The editor was the product. GlideOS says the editor is no longer the product; the agent is.

That is a different kind of democratisation. The visual editor democratised how you build. The agent democratises what you can describe. A lot of people who bounced off drag-and-drop because it was fiddly will take to GlideOS because it is conversational. And a lot of people who loved the fine control of the editor will hate that control being taken away.

The uncomfortable truth is that both reactions are right. Chat-driven building is faster for most people and worse for the power user who knew exactly where to click. No-code vendors are betting the faster route wins more customers than the finer one loses, and on the evidence of the last twelve months, that is a bet worth making.

Should your ops team migrate or leave?

If you run a team on Glide today, the decision mostly comes down to what you are building, not how attached you are to the old editor.

If your app is stable, used by a defined group, and you rarely change it, stay on Classic for now. It still works, and there is no reason to move a settled app onto a credit meter you cannot forecast.

If you are building something new, start in GlideOS. The new features, the new pricing, and the company's energy are all there, and building net-new on a legacy editor is a bet against Glide's own roadmap.

If your app is complex, with heavy workflow logic and pixel-level design you cannot describe in a sentence, start planning an exit. Not because GlideOS is bad, but because a tool that only takes instructions in chat is a poor fit for an app you built specifically to have fine control over.

The takeaway

Glide did not wait for the no-code category to reach consensus. It made the call: the drag-and-drop editor is not how the next decade of software gets built, and it is willing to leave behind the very thing that made it successful to prove it.

For builders, the lesson is simpler than it sounds. Learn to describe what you want in plain English, because that is now the interface. The people who can articulate a requirement clearly will out-build the people who can click precisely. And if you are still on the old editor, budget for the migration now, before Glide sets the date for you.