How to build a marketing analytics dashboard with Bolt

Rule of thumb: if the numbers must arrive without anybody exporting a file, if you need forty connectors maintained by somebody else, if clients expect a branded portal, or if a platform’s API changing is a problem you want to buy your way out of, rent, and if one free report in Google’s own tool already answers your question, use it and spend the fortnight on something else. Build when the meter is the problem: when the fifth client, the eleventh dashboard or the fourth data feed is the thing standing between you and looking at your own numbers, and when what a conversion means in your business is a definition you would rather own than accept. The survey figure above is the honest reason this is worth the effort: buying another tool is the thing this profession is already good at, and it has not moved the integration score in two years.

* The free-tier line that matters here is not the 500 MB of database, which holds years of campaign rows because this data is small and narrow. It is the pause: a free project stops after a week of inactivity, and a dashboard that gets read at the end of each month is exactly the project that goes quiet for a week and greets somebody with an error. Pro, from $25/mo, ends the pause, keeps 7 days of backups, and raises the allowances that matter once people are downloading board exports: 250 GB of egress (then $0.09 per GB) and 100 GB of file storage (then $0.0213 per GB), the latter being where your uploaded CSVs pile up.

Either way the dashboard is yours, and the only running costs are a database plan and a few cents of model usage a month. What differs is who builds it: a developer you pay up front, or you, describing each piece to an AI tool.

Prices and rates from supabase.com, developex.com, developers.openai.com and bolt.new, checked August 2026.

The GitHub step comes before Bolt exists for you at all. Everything after it happens inside the browser tab Bolt opens, with no install.

1. 01

   Running in a tab, with two rules on the record

   A project that boots in the browser, and one prompt fixing the definitions everything after it resolves to.

   PromptSet up the projectCopy

   Create a React 18 + Vite + TypeScript project with Tailwind for a marketing analytics dashboard, and get it running. Then fix the vocabulary before we build anything: organisation, data source, channel, campaign, impression, click, conversion, cost, revenue, dashboard, widget, reject. Two rules to hold throughout, written into the project’s notes rather than only agreed here. First: a conversion means exactly one thing across this whole project, written out in a sentence I will give you, and no screen ever computes a rate for itself. Every rate comes from one place that guards its division, so a card can never show infinity. Second: every row belongs to an organisation, every access rule has to test both what the person may do and which organisation the row belongs to, and neither half is ever left out because the other one looks sufficient.

   Getting the rules into a file in the project matters more here than the wording of them. A browser tab is an easy place to build quickly and an easy place to lose the reasoning from twenty prompts ago, and these two rules are the ones that are expensive to reinstate.

2. 02

   The schema, with an organisation on every row

   Connect a database and describe the tables. No sign-in and no screens yet, which makes this the cheap moment to find out your own exports need a column nobody thought of.

   PromptModel the organisation and the campaign dataCopy

   Connect a Supabase project and write the data model, with no authentication yet and an organisation reference on every table from the start. Organisations. Members linking an account to an organisation. Data sources, one row per file or platform somebody imports from, carrying the import’s status and counts. Then the campaign data in two shapes so I can choose later: a wide table of one row per date, channel and campaign with impressions, clicks, conversions, cost and revenue on it, and alongside it a campaign dimension with separate fact tables for sessions, cost and conversions. Then a rejects table holding every row an import refused, with the line number, the raw row and the reason. Then dashboards, and widgets belonging to a dashboard carrying their own type, title, configuration and position. Seed two organisations with deliberately awkward data: one with a campaign whose name contains a comma, one with the same fortnight imported twice.

   Ask for the seed data in the same prompt as the tables. It is what makes the next four steps something you can look at rather than imagine, and on a tool where the reward is watching things work immediately, an empty database is a slow start you do not need.

3. 03

   Upload a real export into the tab

   The step that separates a dashboard from a demo. Get a real month out of one ad platform and give it to the project. What you actually have is the specification for the hardest thing in this build.

   PromptImport a real exportCopy

   Here is a real CSV export from my ad platform. Read it before you write anything and tell me what you found: the exact column names, the date format, whether fields containing commas are quoted, how it writes a zero or a missing value, any totals row at the bottom, and anything you cannot map onto my schema. Then build the import: a private storage bucket restricted to CSV and scoped so a person reaches only their own folder, and a server-side function that parses an upload with a parser that handles quoted fields properly rather than splitting on commas, checks the required columns are present, validates every row (dates parseable and inside a period I state, numbers numeric, nothing negative that cannot be, channel recognised), inserts what passes and writes every failure into the rejects table with its line number and reason. Never drop a row silently. Handle a re-upload as a decision: key each row on date, channel and campaign, and let me choose per import whether an existing row is skipped or overwritten. Then import my real file and show me three things: the accepted count, the full reject list with reasons, and the total spend of the accepted rows so I can compare it with the same figure in the ad platform.

   Compare that total with the ad platform before going any further. Ten seconds of arithmetic here is what makes the rest of the build worth doing, and once two more layers of aggregation sit on top of these rows, the same check turns into an afternoon of working out which layer moved the number.

4. 04

   Six rates once, then a library to compose from

   The arithmetic in one place first, then the widgets over it, and a single query behind them that runs as whoever is looking.

   PromptBuild the rates, the widgets and the filtersCopy

   First the six rates, computed in one place and never in a component: click-through rate, cost per click, cost per thousand impressions, cost per acquisition, return on ad spend, and return on investment. Every one of them guards its division so a day with no impressions or a campaign with no conversions returns nothing rather than infinity, and I want to see what each returns for a zero case before we go on. Then the widget library: a line chart, an area chart, a bar chart, a pie chart, a metric card showing one number, and a data table. Each widget stores its own metric, grouping and title, and a dashboard stores the widgets on it and their positions as data so somebody can rearrange a board without a developer. Then one server-side function that answers a widget’s query, and build its database client from the caller’s own credentials rather than a service key, so the database applies that person’s permissions to every widget including ones added next year. Then four filters that apply to the whole board at once (date range, channel, campaign and country) passed into every widget’s query rather than filtering in the chart, and remembered between visits.

   Watch what happens the first time you drag a widget and reload the tab. If the layout comes back, positions are being stored as data the way this prompt asks. If it snaps back to how it was written, they are in code, and that is worth fixing now rather than the day somebody else wants to arrange their own board.

5. 05

   Three roles, and a rule with both halves in it

   A database holding what you spend and what it earned, and three kinds of person who should not have the same power over it. The slowest prompt to read and the one worth reading.

   PromptAdd auth, roles, and the access rulesCopy

   Add Supabase Auth with email and password: sign-up, login, logout, a persisted session, and a profile row per account. Joining an organisation happens on the way in, and a person cannot choose or change which organisation they are in afterwards. Add a role enum of 'viewer', 'editor' and 'admin' in a roles table kept out of the account’s own record, plus a SECURITY DEFINER function that reads it, and give roles an organisation, so somebody is an editor of one organisation rather than an editor everywhere. Then row-level security on every table, and write every policy as two clauses joined: what this role is permitted to do, AND that the row belongs to the organisation this person belongs to. Never let a role check stand alone as if it were a boundary. On top of that, a per-dashboard grant table so a viewer can be given one specific dashboard, checked alongside the role rather than instead of it, and reachable from an invitation so the grant can exist before the account does and transfer when it is accepted. Then prove six things by querying as a signed-in account: the second organisation’s campaign rows are unreachable, its dashboards are unreachable, an editor of one organisation cannot update a dashboard belonging to the other, an admin of one cannot grant themselves access to the other’s dashboard, a viewer cannot create a widget, and a viewer cannot open a dashboard nobody shared with them.

   Run the six checks in the tab with two accounts rather than trusting that they passed. Four of them will fail loudly if something is wrong. The two about an editor and an admin reaching across organisations fail silently, by working, which is exactly why they are on the list.

6. 06
   Destination

   The summary, its ceiling, and one channel checked

   The written paragraph, the cap on what it may spend, the exports, and the reconciliation that decides whether anybody should act on this.

   PromptAdd the summary, the cap, and reconcileCopy

   Add the written summary at the top of a board, built so it cannot invent anything. Compute first, with queries: this period’s totals for each metric, the same totals for the previous period of equal length, the change in each, and the same per channel and per campaign. Send only those computed figures to one server-side function that calls the model, and instruct it to describe what it was given without inventing a comparison, trend, projection or cause that is not in the numbers, and to say when a change is too small to matter. Print the figures it was given underneath and name the two periods. Then cap it before I ship: record every call with the account, the feature and the tokens used, and enforce a per-account hourly limit and a project-wide monthly limit I can change without redeploying, refusing politely when either is reached. Then exports: the board as a PDF, and the rows behind any single widget as CSV. Finally, reconcile with me: take one channel for one month, put your figures beside the same figures in the ad platform they came from, and account for every difference, including the rows sitting in the rejects table.

   Put the model key in the project’s environment settings rather than anywhere the browser downloads, and check that before you publish rather than after. It is the one secret in this build that somebody else can spend, and a tab that has been working perfectly for an hour tells you nothing about where the key ended up.

Review the access rules (row-level security policies) on every table. For each one, tell me in simple terms who can view, add, edit, and delete records, confirm that people can only reach their own data while the right roles can reach more, and flag anything left open that shouldn’t be.

Prove all of it by querying as a signed-in account rather than reading the code back. Make a second organisation with its own numbers and check, one query at a time, that it cannot be reached, including the two that look legitimate right up to the last clause: a viewer opening a dashboard nobody shared, and an editor updating a board belonging to somebody else entirely.

All eight serve a dashboard well enough that speed is not the deciding question. Three others are: whether the plan permits commercial use, since Vercel’s Hobby tier does not and client reporting is commercial. Whether it publishes from a private repository, given what this code sits beside. And whether a deep link resolves for a browser that has never seen your site, because a shared dashboard is a link somebody sends.

Rewrite the written summary so it can only describe numbers it was given. First compute, with queries: this period’s totals for each metric, the same totals for the previous period of equal length, the change in each as an absolute and a percentage, and the same per channel and per campaign. Send only those computed figures to my ai function, and instruct it to describe what it is looking at without inventing any comparison, trend, projection or cause that is not in the numbers I sent, and to say when a change is too small to be worth a sentence. Print the figures it was given underneath the summary, name the two periods being compared, and if a metric has no previous period to compare against, have it say so rather than skip it.

Add a "why did this move" action on any metric card. Compute the answer first with queries: the campaigns and channels contributing most to the change between the two periods, with each one’s absolute contribution and its share of the total movement, and whether the movement came mostly from cost, from volume or from conversion rate. Then send only those computed contributions to my ai function for two or three sentences in plain language. Show the contributing rows underneath, and where a single campaign accounts for most of the movement, have it say that plainly rather than listing three things as if they were comparable.

After every import, run a check for rows worth a second look, computed with queries: amounts far outside the usual range for that campaign, cost-per-acquisition or return-on-spend figures orders of magnitude away from that channel’s norm, dates outside the period I said I was importing, days that already had data before this upload, and any metric that moved more than a threshold I set. Then send the flagged rows to my ai function for one line each on why it might be a mistake, and show me the list with an accept or investigate action per row. Nothing is edited or deleted automatically, and the flagged count sits beside the import summary where the reject count already is.

Add a panel where I type a question about my own campaign data in ordinary words. My ai function turns it into a read-only query, runs that query under my own access rules so it can never reach another organisation’s rows, and uses the model only to word the answer. Under every answer, show me the query that ran, the rows it returned, and the period and filters that were in effect. Two hard rules: when a question needs data I do not import, it says so rather than estimating, and it never answers from what it already knows instead of from a query. It writes nothing, ever.

Add a spending ceiling to my ai function before I ship any of the features above. Record every call with the account that made it, the feature it came from, and the tokens it used. Then enforce two limits I can set without redeploying: how many calls one account may make in an hour, and a total for the whole project per month, refusing politely and telling the person when either is reached, rather than failing silently or charging on. Show me current usage against both limits on an admin screen, and log a refusal the same way as a call so I can see when a limit is doing something.

Pick a lighter model for the high-volume prompts above and save a stronger one for wherever the reasoning actually matters. That is the same token-budget logic as the rest of this page, applied to the app’s own AI calls instead of the build itself. When Bolt flags a missing secret, add the key through its secrets settings instead of pasting it into the chat, and keep every AI feature behind one server-side function so there’s only one key to manage.