How Your AI Employee Builds Dashboards and Internal Tools

Key Takeaways

• Some deliverables should be alive, not attached. A metrics report you ask for weekly is a file; a dashboard that stays current is a tool. An AI employee can build and host the second kind too.
• You describe the tool in chat, and it arrives as a link. No repo, no hosting setup, no ticket to the engineering team. Viktor builds the app, deploys it, and posts the URL back in the thread.
• Iteration happens in plain language. "Make the chart weekly instead of daily" or "add a filter by owner" are follow-up messages, not change requests to a vendor.
• Access is a choice. A tool can be open to anyone with the link or gated behind a login, which is the right default for anything showing internal numbers.
• The best first Space is a report you already ask for. Take the recurring summary your team rereads every week and turn it into a page that is simply always current.
• Internal tools stop competing for engineering time. The tracker, the calculator, the little status board your team never got prioritized: this is exactly the class of software an AI employee can own.

The deliverable that shouldn't be a file

Ask an AI employee for a competitor analysis and a document is the right shape for the answer. Ask for "where are we against the quarterly target" and a document is already wrong by the time it is read. Teams solve this today by re-requesting the same report, every week, forever, and the file version of that answer spends most of its life out of date.

There is a third shape of deliverable between a message and a document: a small piece of living software. A dashboard that pulls the current numbers. A tracker the team can actually open. A one-page tool that does the calculation your ops lead keeps doing in a spreadsheet. Viktor builds these as Spaces: small hosted apps he writes, deploys, and hosts himself, delivered back into the conversation as a link.

This post covers what that looks like in practice and which jobs it is the right shape for.

From a chat message to a hosted app

The workflow is deliberately anticlimactic. You describe the tool the way you would brief a contractor:

@Viktor build us a sales pipeline dashboard: deals by stage from the
CRM, total value per stage, and a list of deals with no activity in
14 days. Keep it behind a login, refresh the data when we open it,
and post the link in #sales when it's ready.

Viktor writes the app, deploys it, and the link lands in the channel. There is no step where someone provisions hosting, sets up a repository, or files a ticket. The URL lives on its own subdomain and keeps working; it is a real hosted app, not a preview that expires when the conversation ends.

The interesting part is what happens after the first version, because software is never right on the first pass. With a Space, iteration stays conversational: "the stage colors are confusing, use one color and sort by value", "add a filter by owner", "can mobile get a simpler layout?". Each of these is a message in the thread, and the app updates. The feedback loop your team is used to having with a designer over weeks happens in an afternoon.

What teams actually build

The pattern behind good Spaces is always the same: something the team looks at repeatedly, built once.

Metrics dashboards. The Monday numbers, on a page that is never stale. Instead of a summary posted weekly, the summary becomes a URL, and the weekly message becomes "anything unusual on the dashboard this week?". Our take on why recurring reports deserve this treatment is in replace weekly reporting with AI.

Trackers and status boards. Hiring pipelines, project status, launch checklists, inventory counts. Anything currently living in a spreadsheet that is really a UI problem, not a data problem.

Small internal calculators. Quote builders, capacity planners, pricing-scenario toys for internal use. The five-input tools that every ops team wishes existed and no engineering team will ever prioritize.

Client-facing pages. A polished status page or results summary for a specific customer, presentable enough to send externally, without pulling a designer into it.

Demo and event pages. A signup page, a leaderboard for an internal competition, a one-off microsite that would otherwise be a "who knows Webflow?" message.

Access: open link or login

Anything showing internal numbers should not be one forwarded link away from public. When you brief a Space, say who it is for, because access is part of the build:

• Open to anyone with the link fits demo pages, event pages, and anything you would happily post publicly anyway.
• Login-gated is the right default for dashboards and internal tools, so the pipeline numbers are behind an actual sign-in rather than an unguessable URL.

The rule of thumb is the same one you would apply to a shared document, and stating it in the brief ("keep it behind a login") is all it takes.

Where the boundary is

Honesty about the shape of the tool matters here. A Space is the right answer for the long tail of internal software: tools with a handful of screens, a clear job, and an audience of your team or a client. It is not the way to build your production customer-facing product, and it does not replace your data warehouse or your BI stack where those are already working. The point is the software that was never going to get built at all, not the software your engineers are already building.

It also does not change how the underlying data is accessed: a dashboard can only show what the connected integrations can see, with the same scoping as every other piece of Viktor's work.

A file, a message, or a tool

If you are about to ask for the same file for the third week running, that is the signal you are looking at a Space wearing a document costume.

Frequently Asked Questions

Do I need engineers to review what the AI employee builds?

For internal tools, generally no; treat it like work from a capable contractor and judge it by whether it does the job. If a Space starts carrying weight in a critical process, apply the same judgment you would to any internal tool that grew important, including asking Viktor to walk you through how it works.

Where does the app run? Do we need hosting?

Viktor deploys and hosts the Space himself, and the link he posts is the live app on its own subdomain. There is nothing for your team to provision, and the page keeps working after the conversation ends.

Can we put a dashboard with revenue numbers on a Space safely?

Yes, gate it behind a login, and say so in the brief. Open-link Spaces are for content you would share publicly anyway. The data itself stays scoped to what your connected integrations allow, like all of Viktor's work.

How do we change something after it's built?

Reply in the thread. "Add a filter by region" or "the totals should exclude test accounts" are ordinary follow-up messages, and the app updates. There is no change-request process because there is no vendor.

What happens when the data needs to be current?

Brief it as part of the build: a dashboard can pull fresh numbers from the connected tools rather than freezing a snapshot. If a number can go stale, say how current it needs to be and Viktor builds accordingly.

What should our first Space be?

The recurring report your team re-requests most. It already has a known audience, known numbers, and a known format, which makes it the lowest-risk build with the most obvious before-and-after.

Software your team was never going to get

Every operations team carries a list of small tools that would save hours and will never clear the bar for engineering time. That list is the actual market for an AI employee that ships working software: the dashboard, the tracker, the calculator, the client page. Describe the tool in the channel, get a link back, and iterate in sentences.

Add Viktor to your workspace and turn a recurring report into a live dashboard

Related reading:

• Replace Weekly Reporting With AI
• Replace Meetings With Async Reports
• Choosing Your First 3 Integrations