Speaker A
In this video, I'm going to show you how you can build a financial dashboard connected to your live data, refreshing itself every 30 seconds, running on a real domain that anyone on your team can open while keeping the costs low.
Learn how to build a live, auto-refreshing finance dashboard using Claude AI and Hostinger Horizons with real-time Google Sheets data integration.
Key Takeaways
- Claude AI can automate complex dashboard design by analyzing multi-tab financial data.
- Google Sheets API integration enables live data refresh and real-time updates.
- Hostinger Horizons allows no-code deployment of AI-generated dashboards on custom domains.
- Separating design and deployment workflows streamlines building and sharing finance dashboards.
- Using AI tools reduces manual coding and maintenance effort for finance automation.
Summary
- The video demonstrates building a financial dashboard that auto-refreshes every 30 seconds with live data.
- It uses Claude AI's Opus 4.7 model to analyze multi-tab Google Sheets data and generate a step-by-step dashboard build plan.
- The data set mimics a real SaaS company's internal data, structured across seven functional tabs.
- Google Sheets API is enabled and configured to allow Claude to access live data via an API key.
- Claude produces a structured markdown document with 10 sequential prompts to build the dashboard in any AI dashboard tool.
- Hostinger Horizons is used to deploy the dashboard on a real domain without coding, using a prompt-based React and Tailwind stack.
- The dashboard includes KPIs, charts, responsive layout, and a live status indicator as designed by Claude.
- The workflow separates design (Claude) from deployment (Horizons), enabling easy sharing and live updates.
- The tutorial includes cost-saving tips like selecting a 12-month Hostinger plan and using discount codes.
- The final product is a shareable, live, and automated finance dashboard accessible by the whole team.
Full Transcript — Download SRT & Markdown
Speaker A
Because building a financial dashboard with Claude that looks good is really not that difficult anymore. But the problem is it looks good, but it doesn't automatically refresh when new data comes in, and you can't really share it with your team very easily. So the file
Speaker A
lives on your machine, nobody else can see it. And the moment your data updates, well then the dashboard goes stale. Now, as a quant and finance automation developer, I'll walk you through this next-level approach to how to get from raw messy company data to a
Speaker A
complete system where the dashboard updates itself when new data comes in. The logic stays consistent, and you can share the dashboard with your team.
Speaker A
Remember, if you want the prompts, [music] the data set, and the full build guide from this video, they're in my free community. The link is in the description below. Now, let's get into it. Setting up the data layer. Before
Speaker A
Claude can design anything, we need a data set that reflects how a company actually operates. So, dashboards fail when they are built on one flat table because real businesses do not run on one tab. Finance has revenue data, has
Speaker A
you know, sales, has pipeline data, marketing has spend and leads, operations has support tickets, and none of all this stuff lives in one single place. So I'm working with this Google sheet here that you can see, which is fin database, and
Speaker A
it's structured like a real SaaS company's internal data. It has seven tabs, each one representing a different function including raw transactions, customers tab, sales pipeline, marketing spends, COGS, budget forecasts, and support operations. The next I make the sheet
Speaker A
readable by an API because that is what powers the auto refresh later on. So I open my browser and I go to Google Cloud's website, which is console.cloud.google.com, google.com, and at the top there is a project selected and I click it and I
Speaker A
click new project, name it finance dashboard, and then I click create. Now, once the new project is selected, I go to the left sidebar, I click APIs and services, and then library, and I search for Google Sheets API, click on it, and I
Speaker A
hit enable. Then I head back to the APIs and services section, and I click credentials, click create credentials, and choose API key. Now Google generates the key instantly. I copy it and I set it aside. And the last step is I open
Speaker A
the FIN database sheet and I click share and I set it to anyone with the link can view. Now, without that permission, the API cannot read the data. So I grab the share link and now I have what Claude
Speaker A
needs, the sheet link and the API key, letting Claude design the system. Now this is where the workflow splits off from a normal dashboard build. Now in a normal build, you decide what KPIs matter, what charts to use, how the
Speaker A
layout should flow, and then you write the code or you prompt an AI piece by piece. Now, that approach works, but it puts you in the position of designing a finance system from scratch every single time. Now, I want Claude to do that
Speaker A
part. I want it to figure out what matters across seven tabs of interconnected data to decide how the pieces relate and then produce a build plan that I can execute anywhere. So for that kind of reasoning, I'm using
Speaker A
Claude's Opus 4.7 model because Opus is built for exactly this type of structure planning across multiple complex inputs as well. Now I open a fresh workbook task. I select Opus 4.7 and I make sure Google Drive is connected so Claude can
Speaker A
read the sheet directly. Then I give it a single prompt and the prompt tells Claude to find the sheet Finn database in my drive, analyze all seven tabs, decide what KPIs and charts the data supports, and then break the whole build
Speaker A
into step-by-step prompts that I can paste into an AI dashboard tool builder. Now, it also gives Claude the sheet link and API key, so it can generate real API endpoints instead of just placeholders.
Speaker A
Now, Claude starts by locating the file in my drive and confirming it has seven tabs. Then it reads sample data from each one so that the design decisions come from looking at the actual data rather than guessing from tab names. And
Speaker A
after that it tells me it has a clear picture of the data set and then it begins designing. Now what comes out is two deliverables. Claude even runs a sanity check against the API and confirms that the numbers add up. The
Speaker A
second deliverable is where the real leverage is. Now, Claude generates a structured markdown document that breaks the entire dashboard into 10 sequential prompts. Each one designed to be pasted directly into an AI dashboard tool builder. Prompt one handles the layout,
Speaker A
the theme, and responsiveness. Prompt two connects the data layer, including the API endpoint format and the 30-second refresh logic. The middle prompt, well, the middle prompts I should say, each build one analytical layer, KPI, calculations, chart groups, and data tables. And prompt nine handles
Speaker A
the automation behavior. Prompt 10 then polishes the UI. So, at this point, Claude has produced a transferable blueprint I can take to any platform and deploy without rewriting a single piece of logic. But this HTML file that Claude
Speaker A
generated lives on my system. So for a finance team, that's just not enough. What they need is a dashboard on a real domain that updates itself and opens in any browser. And that's where Hostinger Horizons comes in. Bringing the system
Speaker A
to life. Hostinger Horizons is a prompt-based tool/app builder. So instead of writing code or setting up servers and databases, you describe what you want and it generates the application for you. So in our case that description is already written.
Speaker A
Claude produced it as the 10-prompt build sequence. So the workflow becomes Claude designs the system and Horizons builds and deploys it. Now I go to Horizons through www.hostg.xyz.
Speaker A
XYZ/shjmJ. You can find that link in the description below. And on the page, I choose the starter plan, which is the premium plan because it already includes everything needed to run the setup, which is hosting, a domain, and the full
Speaker A
builder in one place. I select the 12-month plan since it's 73% cheaper than paying monthly. And at checkout, I enter the code L Horizons for an extra 10% off. And there's a 30-day money-back guarantee if you want to use it
Speaker A
yourself. Now, the interface is a chat window. I take Claude's first prompt, [music] the one that defines the layout, the theme, and the dashboard structure, and then I paste it in [music] as is.
Speaker A
Now, Horizons responds with a clarification worth understanding. It tells me it does not support plain HTML with vanilla JavaScript because the platform is built on React with Tailwind. [music] So instead of rejecting the request, it just reframes it. Everything in the
Speaker A
prompt can still be built just in React. Now design [snorts] intent stays identical. The implementation layer adapts. Claude then decides what to build and Horizons handles how to build it inside its own stack. I confirm and Horizons starts generating and within a
Speaker A
very short time it produces the first version of the dashboard in a live preview. [music] Dark theme matching what Claude specified, a sticky header showing finance dashboard with a live status indicator, KPI cards for total revenue, total expenses, net income,
Speaker A
growth rate, and a full set of chart components below. The layout is responsive and the charts animate on hover. Structure is correct but the data is not yet wired to the live Google Sheets endpoint. So that is [music] the
Speaker A
next prompt's job wiring in the live data layer. The second prompt is what turns this from a dashboard UI into a live application. So I paste it into the same Horizons chat and this prompt is focused entirely on data and automation.
Speaker A
Now it tells Horizons to integrate all seven Google Sheets tabs in paral...
Speaker A
Horizons reads the prompt and lays out what it is going to build before touching any code. Now, once it finishes, the dashboard behavior changes. [music] The charts are no longer rendering predefined values. They are pulling from the sheet every 30
Speaker A
seconds. The KPI cards recalculate each cycle automatically. The header now shows a green live indicator with a last updated time stamp. And if a fetch fails, it switches to red while keeping the last valid state on screen so the
Speaker A
dashboard stays usable even when the network blips. Now at this stage the system is running but a few KPIs still need logic refinement and the chart set needs to match the analytical framing that Claude designed and that is what
Speaker A
the remaining prompts handle. completing the build. From here, I work through Claude's prompts three through 10, pasting each one into Horizons without any modification. Each prompt adds a layer, and each new layer builds on the one before it, which is why I run them
Speaker A
in order [music] rather than just mixing them up. Prompt three handles a KPI layer, defining exactly how each metric gets calculated from the raw data.
Speaker A
Prompts four through seven build the full chart grid across revenue costs pipeline marketing customers and support. Prompt eight adds the two tables top customers and sales rep leaderboard joined across the transactions and customer data sets. And prompt nine handles the refresh
Speaker A
architecture parallel fetching across all seven tabs and in place chart update so nothing flickers between cycles and the last prompt polishes the UI. One thing worth calling out Claude originally included a win rate KPI from the sales pipeline and once the full
Speaker A
system was up the metric was redundant because pipeline conversion was already visible through the stage chart and the sales leaderboard. So I removed it and ended up with eight tightly relevant KPIs instead of nine. By the end of the
Speaker A
sequence, the dashboard is production grade. Eight KPI cards, [music] 10 integrated charts, two live tables, and every element connected to real data. So let's update and let's publish this dashboard. Dashboard auto update. Auto update is the feature that changes how
Speaker A
this dashboard gets used dayto-day. So, it's worth showing it working against real changes. So, I open the Google sheet, which is Finn database, and I insert around 10 new rows across multiple tabs. A few new raw transactions, a couple of new pipeline
Speaker A
entries, and some new customer records. Then I switch back to the dashboard and wait for the next refresh cycle. Within 30 seconds, the numbers move. Total revenue ticks up from 13.5 million to 13.7 million as the new transactions
Speaker A
land. CAC drops from 58.2,000 to 48.8,000 once the new customer and lead data gets factored in. Active customers climbs from 80 to 88. Open pipeline expands from 8.7 million to 9.2 million.
Speaker A
Budget variance recalibrates from negative 5.6% 6% to -4.7% as the gap against forecast narrows and every KPI that depends on any of the change tabs updates on its own. Now these shifts propagate across the whole dashboard.
Speaker A
The revenue time series extends the regional and product distributions rebalance. Both tables reorder themselves based on the new aggregates.
Speaker A
The status indicator stays green. The time stamp advances and nothing flickers because chart instances are updating in place rather than rebuilding from scratch. Publishing the dashboard. Up to this point, the dashboard has been running in the horizon's preview. For a
Speaker A
finance team, that's still not really that useful. They need a URL that they can open in any browser or in any device without me having to share anything. So, publishing handles that in a single click. I click publish in the Horizon's
Speaker A
interface and then Horizon's handles deployment automatically and attaches the dashboard to a custom domain that I'd already set up which is luke-finance.com.
Speaker A
Now if you do not have a custom domain configured then Horizon's generates a default hosted URL for you. Now in my case the dashboard goes live on the branded domain instantly. I open the published URL in a new tab and it is
Speaker A
exactly the same as we saw before. To confirm the live system is recomputing rather than showing a snapshot, I go back into the Google sheet and I insert another round of rows across transactions, customers, and pipeline.
Speaker A
Within the next refresh, the published dashboard reflects every single change. Total revenue climbs further to 13.7 million. Marketing spend updates to 2.1 million. CAC drops again to 41.8,000 and active customers rises to 97. Open pipeline hits 9.4 million. Average
Speaker A
resolution time shifts to 34.9 hours and budget variance moves to negative 10.7% as the forecast alignment recalculates in real time. The revenue trend extends, the distributions recalibrate, and both tables reorder automatically. And everything that was updated inside the
Speaker A
preview now updates the same way on the live URL which means the entire team is always looking at the same current state of the business. So that's it. That's the full workflow. A Google sheet with seven interconnected tabs designing the
Speaker A
entire dashboard system end to end. Horizon's turning that design into a live React application and a published domain where finance, sales, marketing and operations are all reading from the same continuously updating source of truth. So your role shifts with the
Speaker A
setup. You you define the objective. You provide the data and then you review the output. The system handles execution.
Speaker A
The judgment that matters, whether the numbers make sense, whether the metrics reflect what is happening in the business, whether the trends warrant action, that is still yours and it always will be yours. For now, that's all and I'll see you next
Topics:finance dashboardClaude AIlive dataGoogle Sheets APIHostinger Horizonsfinancial automationdashboard tutorialSaaS finance datano-code deploymentAI dashboard builder
