Is Dashies right for you?

Read this before you install anything. Every limit below is a real property of the product today, not a roadmap gap being softened. If one of them is disqualifying, it is cheaper to know now.

Dashies fits well when

• Your data is in one of six warehouses: PostgreSQL, BigQuery, Snowflake, Amazon Redshift, Databricks, or Microsoft SQL Server.
• You already work through an AI tool and want the dashboard authored there rather than assembled by hand in a BI tool.
• The dashboard is read by people opening a link. Viewing is free and unlimited; you pay per editor seat, not per viewer.
• The numbers move on a business cadence, not by the second. Hourly, daily, weekly and monthly are the normal cases.
• You want a specific look. Dashies ships arbitrary HTML rather than a fixed widget vocabulary, so a dashboard can look like your company rather than like a BI tool.
• You are replacing a deck someone rebuilds by hand every month. That is the clearest win: the rebuild stops happening.

Dashies does not fit when

You need row-level security per viewer

A published dashboard is one set of bytes served to everyone who can open it. There is no per-viewer filtering: two people looking at the same dashboard see identical numbers.

Access is all-or-nothing, and the two private modes are the only ones that exist:

• A personal private dashboard is visible to its owner and nobody else. There is no share link and no per-viewer grant. A signed-in non-owner gets the same 404 as a URL that does not exist.
• A workspace private dashboard is visible to every current member of that workspace.

If a sales rep must see only their own region, you need one dashboard per region, each bound to a query that already filters. Dashies will not do it for you.

You need refresh faster than every 15 minutes

The fastest cadence is every 15 minutes, and there are conditions on it: it is set in the web app rather than by your AI tool, and it applies to personal dashboards only. For a workspace dashboard the fastest cadence is hourly.

Nothing here is live or streaming. A scheduled run starts on a grid rather than at an exact instant, so a 09:00 daily refresh begins within roughly half an hour of 09:00. Schedules states the precision honestly.

If you need a number that is seconds old, or a page that updates while someone is watching it, this is the wrong tool.

Your data lives in Microsoft SQL Server and is large

SQL Server works, but it is the most constrained of the six engines, and by a wide margin:

• Its executor caps a single result at 5,000 rows, where every other engine allows 100,000. A dataset that is comfortable on Postgres or Snowflake can be refused outright on SQL Server.
• It has no Parquet offload at all, so a large row-level dataset has no escape hatch. Coarsening the grain, narrowing the time window, or lowering a dimension's cardinality is the only remedy.

If SQL Server is your only warehouse and your dashboards need row-level detail at scale, expect to spend the difference in query design.

Your dashboard needs to call an API when someone opens it

Every served dashboard runs in a sandbox on an opaque origin. It cannot use localStorage, sessionStorage, cookies, or IndexedDB, and it cannot make a same-origin authenticated request. Everything a viewer sees comes from data that was already inside the file.

This is deliberate: without it, a published dashboard would share an origin with the Dashies web app and could read a viewer's session out of it. But it does rule out a dashboard that fetches something live at view time.

Nobody on the team uses an AI tool

There is no authoring UI. You cannot build a dashboard by clicking around in the web app, and there is no plan to add one: the whole design assumes your AI tool is the authoring surface. Someone on the team has to be driving Claude Code, Codex, Cursor, or another plugin-capable agent.

You need to trigger a refresh from CI today

There is a headless HTTP endpoint for triggering a refresh, but there is no way to create an API key in the app, so it is not usable in practice yet. If your plan depends on a pipeline kicking a refresh after a nightly load, that is not available today. Refresh on a schedule, on demand in the web app, and on demand through your AI tool all work.

Limits that are worth knowing, but rarely disqualifying

• Your account handle is permanent. It is derived from your email address at signup and there is no rename path. If you need a chosen label in the URL, create a workspace: a workspace slug is yours to pick.
• Approximate aggregates are rejected where exactness is being promised. This matters most on BigQuery, which has no exact percentile function, so a percentile dashboard there has to ship row-level data rather than a precomputed lattice. See Datasets and the four modes.
• Multi-select and range filters cost more. A dashboard whose filters are all single-select can ship a small precomputed artifact. Multi-select over a non-additive measure needs a heavier one. Same page as above.
• The web app's version history page is personal dashboards only today. Workspace version history works through the MCP tools.
• Refreshing on demand needs a paid plan, and so does connecting a warehouse or setting any cadence other than manual. Publishing, sharing and private dashboards do not. See Plans and what is gated.

If you are not sure

The cheapest test is the Quickstart. It uses the built-in self connection, needs no warehouse and no paid plan, and ends at a live URL. It will tell you within one session whether the authoring loop feels right.