How to build a finance dashboard with Replit

Rule of thumb: if the numbers must arrive automatically rather than through a file, if several entities need consolidating, if a client expects a branded pack with a review trail, or if somebody would rather ring a supplier than read a query, rent. If what you want is your own five numbers, defined the way your business defines them, in a currency you chose, with a bill that does not move when you open a second company, that is the half worth owning. One honest note either way, from the same survey as the figure above: 68% of those senior finance people said manual work leaves their organisation vulnerable to decision-making errors. Building the dashboard does not fix that by itself. It fixes it on the day you stop maintaining the spreadsheet beside it.

* Two free-tier lines matter here, and neither is the one people check. The 500 MB database is enough for years of records, because financial data is small. What bites is the pause: a free project stops after a week of inactivity, and a dashboard read monthly is exactly the sort that goes quiet for a week. Pro, from $25/mo, ends the pause, keeps a daily backup for 7 days, and lifts egress to 250 GB (then $0.09 per GB) and file storage to 100 GB (then $0.0213 per GB), the second being where imported files accumulate.

Either way the dashboard is yours, and the only running costs are the database tier and whatever the forecast spends on a model. The difference between the columns is who does the work: pay someone up front, or describe what you want and build it yourself.

Prices and rates from supabase.com, developex.com and replit.com, checked August 2026.

The first two are all you need to start. Everything here stays inside the one browser tab, the app included once you publish it, and the GitHub copy is the one deliberate exception.

1. 01

   App, Postgres and the ground rules, in one message

   The Agent can create the app and provision Postgres beside it in the same breath. Spend the rest of the message writing down the two rules the build leans on.

   PromptSet up the projectCopy

   Create a new React 18 + Vite + TypeScript app with Tailwind and its own server, and add a Postgres database to this workspace. Keep the database connection string in Secrets, never in anything the browser downloads. Then write a short PROJECT_NOTES.md fixing the vocabulary for a finance dashboard (company, invoice, payment, expense, bank line, daily figure, basis, base currency, rate, reject, role) and recording two standing rules for the rest of this build. First: every figure shown is derived from records, on a stated accounting basis and at a stated rate, with anything estimated or carried forward flagged all the way to the card, and never a hardcoded number. Second: every row belongs to a company, the company a person belongs to decides what they may see, and it is never a value that person can change, and because this workspace has no hosted identity service, my own server is what declares who is asking and which company they are in before any request touches a table, so every policy is written to read that declaration. Start the app so I can see it boot.

   That second rule carries more weight here than on the other tools. Nothing is going to hand the database a company on your behalf, and a policy that reads a declaration nobody made does not complain. It admits everybody, and what it admits everybody to is every company’s books in the workspace.

2. 02

   The schema, with a company on every table, at a checkpoint

   Nothing is displayed yet, which makes this the cheap moment to discover your own records need a field nobody thought of. Take a checkpoint once you are happy.

   PromptModel the company and the recordsCopy

   Write the data model in the workspace Postgres, with no sign-in yet and a company reference on every table from the start. Companies. Profiles linking an account to a company. Customers and vendors. Invoices with an issue date, a due date, an amount, a currency and a customer. Payments against invoices with their own date. Expenses with a date, an amount, a currency, a vendor and a category, plus my own category table. Vendor bills for payables. Bank lines with a date, an amount and a direction. A rate table keyed by currency and date with a flag for whether a rate is real or carried forward. A per-company settings table holding the accounting basis, base currency, timezone and whether future dates are allowed. Empty daily-figure tables for revenue, expenses, cash flow, receivables and payables. Seed two companies with deliberately awkward data: one invoicing in three currencies, one with invoices paid sixty days late. Before you write any of it, tell me how a rate lookup will handle a date with no rate, and how a partial payment against an invoice will be represented.

   Answer those two, then take a checkpoint. A rollback here restores the files, the configuration and optionally the database together, which is broader than a code-only undo and exactly what you want at the one point where changing your mind means changing the shape of every figure downstream.

3. 03

   Import your real export, into object storage and Postgres

   Export a real month out of your accounting system before this message. The file you have is the specification for the hardest part of this build.

   PromptImport a real fileCopy

   Build the import. Uploaded files go into object storage rather than a table, kept private and reachable only through my own server, restricted to CSV, and scoped so a person can only reach their own uploads. A server route parses an uploaded file, validates every row (required fields present, dates parseable and inside a period I state, amounts numeric, currency known, no exact duplicate of an existing record), inserts what passes into the right table, and writes every failure into a rejects table with the line number and the reason. No row is dropped silently. Then a screen where I upload, watch it process, and see the accepted count beside the full reject list. A real CSV export from my accounting system is in the workspace: read it first and tell me what you found before writing the parser: column names, date format, how negatives and credit notes appear, and any total rows at the bottom. Then run it and give me the sum of accepted invoice amounts.

   Check that the upload route is the only way to reach a stored file. An accounting export is a list of your customers and what they pay you, and on a tool where your own server is the gatekeeper, "private" means "my server refuses" rather than a setting somewhere else.

4. 04

   The figures in Postgres, and a job you can put on a timer

   The arithmetic this application is made of, and the first place on this tool where it is worth asking what should run without anybody pressing anything.

   PromptCompute the daily figuresCopy

   Build the figures as Postgres functions invoked by a server route, each rebuilding a period I name rather than appending. Revenue from invoices by issue date for the accrual basis and from payments by their own date for the cash basis, computed both ways. Expenses by date and category. Cash flow as inflows and outflows from payments and bank lines, with a running balance. Receivables and payables outstanding, bucketed by how overdue, plus days-sales-outstanding. Convert every amount into my base currency at the rate for that record’s own date. Where no rate exists, carry the last real rate forward, mark the resulting figure as partly estimated, and never overwrite a real rate with a carried-forward one. Then print the working for one specific month: which records fed each figure, on which basis, how many conversions used a carried-forward rate, and both totals side by side. Finally, tell me which of these jobs I would want running on a schedule rather than on a button, and what that means for how I publish this app.

   Ask that last question now rather than at publish time. Rebuilding figures and filling rate gaps are the two things here that want to happen overnight instead of when somebody remembers, and on this tool that is a separate deployment type rather than a database feature, much easier to plan for than to retrofit.

5. 05

   Sessions your server issues, and policies that read them

   Two halves that only work together on this tool: sessions your own server issues, and policies written to trust what that server declares about which company is asking.

   PromptAdd auth, roles, and the access rulesCopy

   Add email-and-password sign-up, login, logout, sessions my own server issues and verifies, and a profile row per account carrying its company. Add two roles, admin and viewer, in their own table rather than on the account record, with a security definer function to check a role. Then row-level security on every table, and because nothing hosted is handing Postgres an account or a company here, have my server declare the requesting account, its company and its role before each request touches a table, and write every policy to read that declaration. Two things to do deliberately. One: every policy scopes rows to the declared company, and the rule allowing somebody to update their own profile carries an explicit with-check forbidding a change to which company it points at, because which row you may edit and what that row may become are different questions and this column is what every other rule resolves to. Two: any rule meant to be admin-only checks the role in its condition rather than only in its name, most importantly on the roles table itself, since a viewer who can write it is an admin. Beyond that: only an admin writes records, changes settings or runs the jobs. A viewer reads everything and writes nothing. Then prove six things with a second account: the other company’s invoices are unreachable, its figures are unreachable, a viewer cannot insert an expense, a viewer cannot change the base currency, an account cannot move its own profile to another company, and a request arriving with no declaration at all is refused rather than treated as trusted.

   That sixth check is specific to this tool and it is the one to be stubborn about. A policy reading a declaration nobody made fails open rather than loudly. Ask the Agent to show you a request with the declaration deliberately missing, and watch it be refused before you put a single real figure in.

6. 06
   Destination

   The pages, the forecast, reconciling, and publishing

   The seven pages, the exports, the audit trail, a month checked against your own books, and only then a release, of two things rather than one.

   PromptBuild the pages, the forecast, and reconcileCopy

   Finish the app. The pages, all reading the computed figures rather than raw records: an overview of KPI cards. Revenue with filters that drill to the rows behind a total. Expenses by category. Profitability with the margin definition printed beside it. Cash flow with a running balance. Receivables and payables with ageing buckets and days-sales-outstanding. A reports page with downloadable profit-and-loss, cash-flow and expense packs as PDF and CSV. Show the accounting basis and base currency on every page, and mark any total that used a carried-forward rate. Then the forecast: twelve months projected from my own figures with a trend and a month-of-year seasonal factor, the method and the months fitted named on the chart, and any model restricted to a sentence of commentary that cannot change a number, with its key in Secrets. Then audit triggers on invoices, payments and expenses recording old and new values. Then reconcile with me on one real month against my accounting system, accounting for every difference including the rejects table. Finally, tell me which deployment type the app needs, what the overnight rebuild of figures needs instead, and what Publishing is about to make visible and to whom.

   Ask that last question before you press publish rather than after. This build wants two releases (the app people read, and the overnight job that keeps the figures current) and reviewing who the app is visible to is a setting most people meet for the first time after the address is already in somebody else’s hands.

One rule outranks the rest here: the database connection string and any model provider key live in Replit’s Secrets and nowhere else: not in anything the browser downloads, and not in a repository. Treat either one that escapes as burned, and replace it the same day.

All of these are Replit rather than a third party, so the choice is shape rather than vendor, and this build wants two of them: one to serve the pages, and Scheduled for the overnight rebuild. Review who the app is visible to before the first release, since Publishing is what sets it, and on this application that setting decides who can read your accounts.

The twelve-month forecast currently sends my history to a model and asks for realistic projections. Change it in two steps. First, compute a baseline in the database from my own figures (a trend over the last twelve months plus a month-of-year seasonal factor) and draw that as the forecast line, naming the method and the months it was fitted from on the chart. Second, keep the model but give it a different job: send it the computed projection and have it return a short commentary on what the shape suggests and which assumptions would break it, with no power to change a number. Label the chart so a reader can tell arithmetic on my data from a model’s opinion, in the chart, not only while it loads.

Add a screen listing imported expense rows with no category or one I have flagged as doubtful. Send the description, the vendor and the amount to my server-side ai function and get back a suggested category from my own list, plus a confidence and a one-line reason. Show them as a reviewable list I accept, change or reject in bulk, writing nothing until I do. Anything below a confidence I set stays uncategorised rather than guessing. Include recent accepted examples for that vendor so it learns from my corrections, and never invent a category that is not already in my list.

Add a "why did this move" action on any figure. Compute the answer with queries first: the top contributing categories, customers or regions behind the change between two periods, with their amounts and their share of the movement. Then send only those computed contributions (no customer names unless I turn that on) to my ai function for two or three sentences explaining the movement in plain language. Print the figures it was given underneath, state the two periods, and where the movement is mostly one row, say so rather than listing three.

After every import, run a check for rows worth a second look: amounts far outside the usual range for that vendor or customer, near-duplicate invoices, dates outside the period I said I was importing, and totals differing from last month by more than a threshold I set. Compute all of it with queries. Then send the flagged rows, without customer names, to my ai function for a one-line reason each on why it might be a mistake, and show the list with an accept or investigate action per row. Nothing is deleted or edited automatically, and the flagged count sits beside the import summary.

Add a panel where I ask about my own figures in ordinary words. Have my ai function turn the question into a read-only query against my computed figures tables, run it under my own access rules so it can never reach another company’s data, and use the model only to phrase the answer. Show the query it ran and the rows it used under every answer, state the period and the accounting basis, and refuse rather than guess when the question needs data I do not import. It never writes, and never answers from memory instead of from a query.

A cheap model is plenty for most of the prompts above. Save Pro’s stronger models for the one or two spots where the extra reasoning actually pays for itself. Add any provider key through Replit’s own Secrets tool rather than hard-coding it, and keep every AI feature behind one server-side function so a single key covers the whole app.