Table of contents
We keep calling it the wrong thing
If you’re in Ops, RevOps, Finance, or IT, you don’t need “a hosting strategy” for every internal tool.
You need a safe way to get a small app into teammates’ hands quickly; with access control, an owner, and a URL people can find later.
That need is becoming the default:
Gartner predicts that by 2027, 75% of employees will acquire, modify, or create technology outside of IT’s oversight.[1]
When someone says “we need to host this internal tool,” what they usually mean is:
- “My teammates need to use it.”
- “I need my team to access it (without me manually sending files every time).”
- “It should work for the right people, and not for everyone else.”
- “If it breaks, we can fix it quickly.”
But “hosting” is the word we inherited from building public web apps and it drags a whole infrastructure-shaped mental model into a problem that often isn’t infrastructure at all.
If you’ve ever built a quick tool for your team (a calculator, a form, a dashboard, a script with a UI), you’ve probably felt the cliff:
- It works on your laptop.
- It works for you.
- It even works in a demo.
- Then you try to share it.
Suddenly, a one-hour tool becomes a two-week project. Not because the tool is hard, but because making it safely usable by other people drags you into a long list of setup and maintenance work.
What “publishing” means
Publishing an internal tool means turning a useful thing you built into something other people can reliably use:
- a shareable URL
- access control
- a place it lives (so it’s discoverable)
- a safe path to update it
Hosting is how the tool runs. Publishing is how the tool becomes usable.
This matters because a lot of “deploy internal app” work is really “publish internal tool” work in disguise.
Hosting vs. publishing (the simple distinction)
Here’s the simplest distinction:
- Hosting is how the tool runs.
- Publishing is how the tool becomes usable by other people.
Most teams treat these as the same thing because historically they were bundled.
If you wanted someone else to use software, you had to:
- provision infrastructure
- set up a domain
- configure deployment
- handle auth
- think about access control
- figure out where state lives
- monitor it
- keep it secure
All of that is real. But it’s not what you’re trying to accomplish.
What you actually want is simpler:
- “Make this tool available to the right people.”
That’s publishing.
Example: a margin calculator
Let’s say you build a margin calculator for your sales team.
You build a simple app:
- inputs: deal size, discount, COGS
- output: margin dollars + margin percent
On your machine, it’s done.
Now you want the team to actually use it.
If you frame this as “hosting an internal tool,” you will immediately fall into questions like:
- Where will it run?
- How do we get updates live safely?
- Who maintains it?
- How do we keep it secure?
If you frame this as “publishing an internal tool,” the checklist is different:
- Who should be able to access it?
- What’s the shareable URL?
- Where does the team find it later?
- Can we update it without breaking everyone?
- Can we roll back?
Those questions map to the real outcome.
Two more quick examples
A lot of teams get stuck because they only picture one kind of “internal app.” In reality, internal tools show up everywhere.
Finance: an approval workflow
You build a lightweight approval app:
- request: vendor spend / software budget / travel
- routing: manager to finance
- output: approved / rejected + notes
The “hosting” framing pushes you into infrastructure debates.
The “publishing” framing forces the operational questions that actually matter:
- who can submit
- who can approve
- where the audit trail lives
- what happens when the approver changes roles
Ops/People: onboarding checklist
You build a small onboarding tool:
- tasks and owners
- due dates
- links to docs
Publishing is the difference between:
- “it’s a doc someone updates”
- and “it’s a tool that assigns work, enforces access, and stays current.”
The hidden cost of “just host it”
The mismatch isn’t just semantics. It changes what work gets prioritized.
When you choose to host or deploy an internal tool yourself, you also choose to own the failure modes. When it goes down, you are the one answering questions, restoring service, and explaining impact. That might be during peak business hours, or it might be at 3 a.m. Either way, you inherit the on-call responsibility.
That responsibility is often the hidden cost that kills momentum. Not because teams cannot build a tool, but because they cannot justify becoming a mini platform team for a calculator.
When you say “host it,” you implicitly commit to the entire surface area of production infrastructure.
That pushes teams toward one of three bad outcomes:
- The tool stays single-player (living on someone’s laptop).
- The tool becomes a spreadsheet again (easy to share, but fragile, error-prone, and impossible to govern).
- The tool turns into a full software project (which means it never ships).
Publishing is the missing middle: it’s the step that turns a useful internal tool into a team asset without turning it into a major platform project.
What changes in practice
If you treat it as hosting, you optimize for
- choosing and setting up where it runs
- getting changes live without breaking things
- reliability and performance
- monitoring and troubleshooting when something fails
- locking things down early
If you treat it as publishing, you optimize for
- access for the right people (and only the right people)
- a stable URL that people can use and bookmark
- discoverability (a home or directory)
- safe iteration (updates that don’t break everyone)
- governance (owners, permissions, auditability)
Hosting can still exist under the hood. But publishing is the operational outcome your org feels.
When you really need “production-grade”
Let’s be clear: production-grade matters. The question is what “production-grade” needs to include for this tool.
Some internal tools are effectively core systems. They need serious reliability, clear ownership, and tight governance from day one.
Other tools are smaller and more local (a calculator, an approval flow, a team dashboard). They still need to be secure and reliable, but they do not need a full platform build-out before anyone can use them.
Publishing is production-grade for internal tools
Publishing is not “lower quality hosting.” It is a production-grade workflow for making internal tools usable: access control, ownership, a stable URL, and a safe way to update.
You mainly need publishing when
- the tool is for one team or a few teams
- the goal is “get it in people’s hands” not “run it for the whole company”
- the tool changes often and you want safe iteration
- you need clear access, ownership, and governance without a long infrastructure project
You need full hosting plus publishing when
- the tool must connect to complex, locked-down systems inside your company
- the tool needs very high reliability or fast response times
- you have strict compliance requirements and need a fully managed, audited setup
- you are building something that becomes a core system of record
In other words: publishing is the baseline for making internal tools production-ready. Full hosting is the additional layer you add when the tool truly demands it.
A simple “publishing” checklist
If you want a practical “deploy internal app” standard that doesn’t balloon into a platform project, start here.
- Identity and authentication
- How do users sign in (SSO, email, existing identity provider)?
- Access control
- Who can view?
- Who can edit?
- What groups map to those permissions?
- A shareable URL
- What link do you send in Slack?
- What link do people bookmark?
- Discoverability
- Where does this live so people can find it again (a directory, a dashboard, a hub page)?
- Ownership
- Who owns the tool?
- Who updates it?
- Who gets paged (or at least notified) when it breaks?
- Safe updates
- How do you ship changes without breaking everyone?
- Can you roll back?
- Auditability (when relevant)
- Can you answer: who accessed it, who changed it, and when?
- Data handling (when relevant)
- Where does data live?
- What’s the retention policy?
If you can answer these, you’re publishing.
If you can’t, you’re not blocked on infrastructure — you’re blocked on operationalizing access.
What we mean when we say “publish”
When we say “publish,” we mean a workflow that gives you:
- A simple way to give teammates access (so it’s not “ask me for the file”)
- Access control so only the right people can use it
- A home (a dashboard or directory) so it’s discoverable later
- A safe update path so improvements don’t become scary
- Admin-friendly controls so access isn’t a free-for-all
Notice what’s missing:
- choosing infrastructure
- arguing about deployment strategy
- reinventing auth
Those are important concerns, but they shouldn’t be the price of sharing a calculator.
A few common pushbacks
”Isn’t publishing just hosting with marketing?”
No. Hosting is about running software. Publishing is about making sure the right people can actually use it.
Publishing can sit on top of many different hosting setups, or it can abstract them away entirely. The point is that you should be able to build quickly, share safely, and iterate confidently without needing to become a part-time DevOps team.
”Our security team won’t allow this.”
Security teams don’t block “publishing.” They block:
- unclear access control
- unknown data handling
- no ownership
- no audit trail
Publishing, done right, is what makes internal tools governable.
It gives security a real surface to approve: identity, permissions, owners, and logs — instead of ad-hoc links and laptop apps.
”If it’s important, it needs to be production-grade.”
Some tools absolutely should be. But “production-grade” is a spectrum, not a switch, and the problem is forcing every internal tool to the far end of that spectrum before anyone can use it. Publishing lets you ship a safe, working version quickly and then harden it as the tool proves it matters.
The takeaway
If your internal tools are stuck on someone’s machine, the blocker is rarely “we don’t know how to host.”
The blocker is:
- no safe way to share it
- no governed way to grant access
- no obvious home for the tool
- no easy way to update it without breaking people
That’s a publishing problem.
A better question to ask next
If you’re building internal tools today, ask a different question.
Instead of:
“How do we host this?”
Ask:
“How do we publish this so the right people can use it?”
The second question leads you to better defaults and a much shorter path from “I built it” to “the team uses it.”
Sources
Gartner. “Top 8 Cybersecurity Predictions for 2023–2024,” Gartner Security & Risk Management Summit, March 2023. securitybrief.com.au