Key Takeaways

• Some work is meant to leave the building. A client status page, a partner-facing tracker, a public changelog: attachments are the wrong shape for these, because the moment you export a file it starts going stale.
• An AI employee can publish work as a live page instead. Viktor builds these as Spaces: small hosted web apps he writes and deploys himself, delivered back into the conversation as a URL you can send to anyone.
• Every Space ships on its own named URL, like yourproject.viktor.space. It is stable, shareable, and does not require the viewer to have Slack, Teams, or a Viktor account.
• Access control is a decision, not a default. An open-link Space is for content you would share publicly anyway. For anything sensitive, ask for a login gate and domain-restricted signups in the brief.
• The hosting is the vendor's problem, in a good way. Spaces run on Viktor-managed infrastructure, encrypted in transit and at rest, covered by the same security program as the rest of the product. There is no server for your team to babysit.

The report your client never sees

An agency runs a weekly performance report for a client. The AI employee assembles it every Monday: spend, results, what changed. Then someone exports it to PDF, attaches it to an email, and by Thursday the client is asking a question the Monday numbers cannot answer. The report was right; the format was wrong. What the client actually wanted was a page they could open anytime.

Internal teams already know the fix. We have written about how an AI employee builds dashboards and internal tools for your own team. This post is about the next step: work that needs to be seen by people outside your workspace, on a real URL, without anyone exporting anything.

What kinds of work belong on a live URL?

Anything a person outside your chat workspace needs to check more than once belongs on a URL. If it will be looked at repeatedly and it changes over time, a page beats an attachment.

The shapes that come up most often:

• Client status pages. Where the project stands, what shipped this week, what is blocked and on whom. The client checks it instead of emailing you.
• Shared trackers. An order pipeline a partner can see, a hiring tracker a fractional recruiter checks in on, a delivery board a vendor works against.
• Public-facing pages. A changelog, an event page, a simple signup form that writes responses somewhere your team can act on them.
• One-purpose tools. A calculator or lookup page you want customers to self-serve on, instead of asking your team the same question weekly.

The common thread: none of these viewers are in your Slack. Posting the answer in a channel does not help them, and emailing exports creates a stale copy every time.

How does publishing actually work?

You describe the page in chat, and it arrives as a link. No repo, no hosting account, no ticket to engineering. Viktor writes the app, deploys it, and posts the URL back in the thread.

@Viktor build a client-facing status page for the Meridian onboarding project: current phase, completed milestones, open items with owners, and a "last updated" stamp. Pull the items from our Linear project and refresh daily. Gate it behind a login.

Iteration happens the same way. "Move the blockers to the top." "Add a column for target dates." "Make it read-only for everyone except us." Each request updates the live page, and the URL stays the same, so the link you already sent the client keeps working.

Because Viktor connects to 3,200+ integrations, the page can show live data from the systems where it actually lives: Linear, HubSpot, Stripe, Google Sheets. That is the difference between a page and a snapshot. If your team has never shipped a Space before, shipping internal tools without engineers walks through the first build in more detail.

What URL do you get, and who can see it?

Every Space ships on its own named subdomain, like yourproject.viktor.space. Viewers just open the link in a browser; they do not need Slack, Teams, or an account with Viktor.

Who can see it is your call, and it is worth making deliberately:

The practical rule we give every team: start read-only. Launch the Space as a dashboard or status page, confirm the data is right at the URL, and only add write actions like forms or buttons once you trust the output. And say the access level in the brief, because "gate it behind a login, only @meridian.com addresses" is one sentence that saves an awkward conversation later.

Is a page you did not host yourself actually safe?

The hosting layer is Viktor's responsibility and sits inside the company security program; the app layer is whatever you asked for, which is why the access decision above matters.

Concretely, Spaces run on Viktor-managed infrastructure, not on an account your team has to create or maintain. Traffic is encrypted in transit and data is encrypted at rest, and the hosting is covered by the same program that covers the rest of the product, including SOC 2 Type I. The full posture is documented at viktor.com/security.

Two judgment calls remain yours:

• Match the gate to the content. An open-link Space has no access control by design. If the page shows client names, revenue, or anything you would not tweet, ask for the login gate.
• Keep regulated data out. Do not put protected health information or similarly regulated records on a shared page. That is a data-classification decision no hosting setup makes for you.

Where do live pages fit next to reports and dashboards?

A useful way to think about your AI employee's output: messages answer a question once, files package an answer for a meeting, and pages keep an answer current for an audience. Most teams start with the first two and discover the third when an outside audience shows up.

The upgrade path usually looks like this: a recurring report someone keeps forwarding becomes a Space with a login gate; a question customers keep emailing becomes a public page; a spreadsheet a partner keeps requesting becomes a shared tracker. Each one removes a copy-and-send loop from someone's week. If you already run recurring tasks, the pattern will feel familiar: describe the outcome once, let it stay current on its own.

Frequently Asked Questions

What is a Viktor Space?

A Space is a small hosted web app that Viktor builds, deploys, and hosts himself, delivered as a live URL. Dashboards, status pages, trackers, forms, and small tools are the common shapes. You describe it in chat, and it arrives as a link.

Do viewers need a Viktor account to open a Space?

No. A Space is a normal web page. Anyone you share the URL with can open it in a browser, subject to whatever access gate you asked for. Viewers do not need Slack, Teams, or Viktor.

Can a Space run on my own domain?

Spaces ship on named viktor.space subdomains today, like yourproject.viktor.space, and that URL is stable enough to link from your site or share directly. If a custom domain matters for your use case, tell your team's Viktor admin to raise it, and link the Space from your own site in the meantime.

How do I restrict a Space to just one client's team?

Ask for a login gate with domain-restricted signups in the brief. Viewers then sign in with their email and a one-time passcode, and only addresses on the domains you allow can register. It is the standard setup for client portals.

Does the data on a Space update automatically?

If you ask for it. A Space can pull from the tools Viktor is connected to and refresh on a schedule you set in the brief, like daily or hourly. A page without a refresh instruction shows the data from when it was built, so say the cadence you want.

What should not go on a Space?

Anything regulated, like protected health information or protected student records, and anything you would not want to exist outside your workspace even behind a login. For everything else, the rule is simpler: open link for public content, login gate for the rest.