What \"Publishing\" Should Actually Mean in 2026
There is a small word that most application platforms use without thinking. Deploy. Deploy your app. Deploy to production. Push deploy to go live. The word shows up in the documentation, the dashboard, the welcome emails, the error messages. It is so thoroughly the default that nobody stops to notice it is a choice.
It is also a choice that reveals something about the audience a tool imagines it is talking to. Deploy is not neutral vocabulary. It is a word borrowed from the military — soldiers are deployed — and from infrastructure — servers are deployed. The word brings with it a set of assumptions. There is a system being put into a position. Something is being moved from one environment to another. The framing is mechanical, technical, and implicitly addressed to the person who operates the machinery.
Publish comes from a different lineage. It is the word for what happens when a book leaves the editor's desk and reaches a bookseller. What happens when a newspaper is stacked on a kiosk. What happens when a photograph is put on a wall. The word is older than computing by several centuries. It also brings assumptions with it — an audience, an act of finishing, an expectation that what has been made will be found.
Most of the people building applications today are not engineers. They are small-business owners, operations leads, consultants, educators, service providers. They are not running a server-room. They do not have an environment to deploy to. What they have is something they want to put in front of customers, colleagues, students, or members. They want to publish. And the tools most of them use still insist on the other word.
Why the word matters
Words are not decorative. The verb that a platform uses to describe the act of going live reshapes what the platform encourages people to do.
When a tool talks about deployment, the mental model it promotes is configuration. You are pointing software at an environment. You are picking a region, a tier, a server. Things can fail to deploy. Things can be rolled back. The work looks like the work of running servers, because the language is the language of running servers.
When a tool talks about publishing, the mental model it promotes is the finished thing. You are sending something into the world. You expect it to stay. You expect it to be found. The work looks like the work of making something — because the language is the language of finished objects.
For an engineer operating infrastructure for a living, "deploy" is honest and accurate and no amount of linguistic choice can change the underlying job. For everyone else, the language is a subtle but constant reminder that they are in a place that was not built for them.
Three implications of saying "publish"
If an application platform commits to the word publish rather than deploy, three consequences follow. They are not semantic tricks. They shape the product that gets built.
Permanence
Published things are expected to stay live. When a book is published, the default assumption is that the book continues to exist. A library stocks it. A reader comes back to it. It is not an event that requires a fresh effort every time someone wants to read it.
Deployed things carry a different expectation. A deployment is, by its nature, an event that can be un-done. Infrastructure is rented. Environments are ephemeral. The software industry has many stories of deployments that evaporated because the person maintaining them moved teams, or the cloud bill went unpaid, or a dependency quietly deprecated.
A platform that promises to let you publish an application has implicitly committed to the application staying live after you have moved on to the next thing. A platform that describes the same act as a deployment has implicitly reserved the right to require your ongoing attention. The words are doing work.
Audience
Publishing has an audience. Deploying has an environment. That is the sharpest single contrast between the two.
A book has readers. A newspaper has subscribers. A storefront has customers walking past the window. When a tool invites a user to publish something, it is pointing that user at the people who will find and use the thing. It invites an act of imagination about the user's user.
A deployment has a URL, a DNS record, a load balancer, a server. When a tool invites a user to deploy something, it is pointing that user at the infrastructure. It invites an act of imagination about the machine.
Both framings have their place. One of them, though, is the framing that most of the people using modern application platforms actually live in. They are thinking about the customer, the colleague, the student, the member. The platform that speaks the same language makes their job easier.
Editing
Published things are expected to be editable. A book goes through revisions. A newspaper publishes corrections. A website is continuously rewritten without ceremony. The word publish carries no implication that the author is finished with the thing.
Deployed things, by cultural habit, require a cycle. The cycle has names — release, deploy, rollback, hotfix. The vocabulary is heavy. It implies an operational overhead that a small business does not want to own and often should not have to.
A platform that speaks the language of publishing has to accept the expectation that editing is ordinary and ongoing. Change a field, update a paragraph, adjust a rule — and the change is live, because the thing was published, not deployed. The engineering machinery that makes this true can be as complex as any deployment pipeline. The user should not have to see that machinery. The word sets the expectation.
What this says about the shape of future software
It is tempting to treat this as a debate about vocabulary. It is not. The vocabulary is the surface of a deeper shift that is well underway.
Software used to be built for people who ran servers. That is no longer true of most of the software being built today. Most of the software being built today is aimed at people whose job is not software. The operational metaphor — deploy, environment, server, tier — was never going to work for this audience. It was a hand-me-down from the era when software was something a team of engineers stood up for their company, not something a solo consultant put together on a Tuesday evening.
The tools that are quietly winning the next decade are the ones that do not make their users learn an operational metaphor. They speak the user's own language. They look, from the user's side, more like a publishing tool than a deployment tool. The internal machinery may be as sophisticated as any cloud operations stack — it usually is — but the surface is honest about who is driving.
This is also why the tools that describe themselves with engineering vocabulary, while targeting non-engineering users, tend to run into a specific kind of awkwardness. The vocabulary does not match the user's self-description. Users learn the vocabulary because they have to, but they never feel at home in it. A platform that quietly switches the vocabulary to publish is, among other things, telling the user you are not a temporary visitor in an engineer's world. You are the user this was built for.
Our deliberate choice, and why
At Exepad we made the vocabulary choice deliberately. Every button, every piece of documentation, every welcome email uses the word publish. We do this because the experience we built is a publishing experience. You describe what you want. You review the result. You publish. The thing goes live at a URL, stays live, and can be edited in place. That is the user's mental model and our product tries to honour it.
The word deploy will keep having its place. In engineering contexts, for engineering audiences, it is the accurate word. We use it ourselves, internally, when we are talking about the machinery that makes the publishing experience possible. For everyone else, publish is the more honest one. It describes what they are actually doing.
If you are curious about what the publishing experience looks like in practice, the walkthrough of going from idea to live app in ten minutes is the most direct way to see it, and the piece on the hidden cost of managing eight disconnected subscriptions is a companion essay to this one. The homepage is the shortest path to the tool itself.
