What is custom dashboard development?
Custom dashboard development is the work of turning data from several business systems into one agreed set of KPIs, stored in a model you control and shown on screens built for the people who make decisions. The screen is the visible 10 percent; the definitions, pipelines and permissions underneath are the rest.
A built-in report inside QuickBooks Online or Shopify answers questions about that one tool. A custom dashboard answers questions that cross tools: which marketing channel brings customers who actually pay their invoices, which sales rep's deals turn into repeat orders, what margin looks like after refunds and shipping. Those questions need data from two or three systems joined on a shared key, such as a customer email, order number or invoice ID.
So when a US team asks us for custom dashboard development, we treat it as a small data project with a user interface on top. It has four layers: extraction (getting data out of each app on a schedule), modelling (cleaning, joining and defining measures), presentation (Power BI, Looker Studio or a React app) and access (who can see which rows). Skipping any of them is how dashboards end up ignored six weeks after launch.
- Extraction: APIs, connectors or scheduled exports from each source
- Modelling: one table per business entity, with clear keys and measures
- Presentation: the tool your viewers will actually open
- Access: roles that match your org chart, tested before go-live
When does a US business need custom dashboard development instead of built-in reports?
You need custom dashboard development when the answer to a routine question requires exporting from more than one app, when two people get different numbers for the same KPI, or when the report you want sits behind a plan upgrade you would otherwise not buy.
The signals are usually practical rather than technical. Your operations manager spends Monday morning building a spreadsheet from three exports. Your sales total in HubSpot never matches revenue in QuickBooks, and nobody can explain the gap. Your investors or franchise owners ask for a monthly pack that takes two days to assemble. Your team shares one admin login to a tool just so people can see a report. Each of these is fixable, and each costs staff time every single week.
There are also times not to build. If one tool holds nearly all the data you care about and its native reports cover your questions, learn those reports first. If your data is less than a few months old or your processes change weekly, wait until they settle; a dashboard freezes definitions, and freezing the wrong ones creates arguments. A good test is to write down the five decisions you will make differently with better numbers. If you cannot name them, spend on something else for now.
Which KPIs belong on a custom operations dashboard?
The right KPIs are the ones tied to a recurring decision and an owner. Start with seven to twelve numbers across the whole business, then add department pages; a first page with forty tiles is a sign nobody made choices.
Before we open any tool, custom dashboard development with us begins with a KPI dictionary. Each line holds the metric name, a plain-English definition, the exact formula, the source system, the refresh frequency, the owner and the decision it informs. “Revenue” alone is not a definition. Is it Shopify gross sales, net of refunds, including shipping, or QuickBooks income booked on invoice date? Writing it down forces the conversation that otherwise happens in every meeting afterwards.
Owner or general manager
Cash in bank, revenue against last year, gross margin percent, open pipeline, and a simple traffic trend. Readable on a phone before a 9 a.m. call.
Finance or controller
AR aging buckets, days sales outstanding, budget versus actual by class or location, and payroll as a share of revenue.
Sales lead
Deals by stage, stage-to-stage conversion, average days in stage, win rate by source and quota attainment per rep.
Operations or ecommerce
Orders shipped on time, refund rate, stock cover in days, top SKUs by margin rather than by units.
The dictionary becomes part of your handover pack. When someone new joins, they read one document instead of reverse-engineering formulas.
How do you get QuickBooks Online data into a custom dashboard?
QuickBooks Online data reaches a dashboard through Intuit's developer API or through a connector service that uses it, landing in a small database where invoices, payments, bills and accounts can be joined to your other systems. Direct spreadsheet exports work for a pilot but do not hold up for scheduled refreshes.
The accounting side is where custom dashboard development most often goes wrong, because accountants and operators read the same numbers differently. Revenue on an accrual basis differs from cash received. Classes and locations may be used inconsistently. Journal entries made at month end can move last month's figures after the dashboard has already been screenshotted. We deal with this by agreeing with your bookkeeper which reports the dashboard must reconcile to, usually the profit and loss and AR aging for a closed month, and building a small reconciliation check that flags any difference.
Access is handled through an app connection that someone with admin rights on your QuickBooks company authorises. We do not need your QuickBooks password. We pull only the entities the KPIs require, typically customers, invoices, payments, items, accounts and classes, and nothing about payroll unless you explicitly ask for it. Credentials for the connection live in your cloud account's secret store, not in our laptops.
Shopify and HubSpot in one dashboard: orders, deals and the join problem
To combine Shopify and HubSpot, you need a shared key, usually the customer email or a customer ID written into both systems, and a clear rule for which system is the source of truth for each field. Without that rule the same customer appears twice and totals double.
On the Shopify side, we use the Admin API. Shopify's own documentation states that the REST Admin API is a legacy API as of October 1, 2024, and that new public apps must use the GraphQL Admin API from April 1, 2025. For a private dashboard integration, that means we write extraction against GraphQL so it does not need rewriting later. Orders, line items, refunds, customers, products and inventory levels are the usual tables.
On HubSpot, a private app with narrowly chosen scopes produces an access token that reads deals, companies, contacts and pipelines. HubSpot's developer docs describe how each scope limits what the app may read or change, which is exactly what you want for a read-only reporting link. We never ask for write scopes unless the dashboard writes back, for example to tag a contact.
The join logic then sits in the model: a HubSpot deal marked closed-won links to the first Shopify order or QuickBooks invoice for that customer, so the dashboard can show time from deal to cash. That single view is often the reason owners commission custom dashboard development at all.
Adding GA4 to a custom dashboard without losing history
GA4 data can come in through the Google Analytics Data API for aggregated reports, or through the BigQuery export for event-level detail. Before either, check your property's data retention setting, because the default can be shorter than your dashboard needs.
Google's help page on GA4 data retention explains that standard properties can keep user-level and event-level data for 2 months or 14 months, and that the setting affects explorations and funnel reports rather than standard aggregated reports. If your dashboard relies on exploration-style detail, set retention to 14 months today, since the setting is not retroactive for data already removed. For anything longer, the BigQuery export keeps its own copy. Google's documentation lists a daily BigQuery export limit of 1 million events for standard properties, which small and mid-size sites rarely reach.
In practice, most leadership dashboards need sessions, users, conversions and revenue by channel, landing page and week. That is aggregated data and the Data API handles it well. Event-level exports matter when you want to join a GA4 purchase to a Shopify order or a HubSpot contact, which needs a transaction ID carried through both systems. We check that your tags pass that ID before we promise the join.
Choose Power BI when your company runs on Microsoft 365 and viewers already have or can justify Pro licences. Choose Looker Studio when data lives mostly in Google products and reports go to many casual viewers. Choose a custom React dashboard when outsiders such as clients or franchisees sign in, when you need write-back, or when per-viewer licensing no longer makes sense.
One naming note first: Google's documentation now says Looker Studio is called Data Studio. We use both names on this page because buyers still search for the older one. It remains a no-cost tool for building reports, with a paid Pro tier for team administration.
The honest trade-off is between speed and control. Power BI and Looker Studio get a first version on screen in days, and your staff can edit visuals themselves later. A React dashboard takes longer and needs a developer for changes, but it can look exactly like your product, handle thousands of external users with your own login system, and cost nothing per viewer. Many of the teams we talk to end up with both: an internal Power BI or Looker Studio model for staff, and a small React portal for customers reading from the same database.
Power BI fits when
Finance lives in Excel, staff sign in with Microsoft accounts, you need DAX measures and row-level security, and viewers are mostly employees.
Looker Studio fits when
Marketing data comes from GA4, Google Ads and Sheets, reports are shared by link, and modelling needs are light.
A custom React app fits when
Clients, drivers or franchise owners need their own login, you want the dashboard inside your product, or you need forms and actions next to charts.
How often should a custom dashboard refresh?
Refresh as often as a decision needs, not as often as the tool allows. Finance KPIs are usually fine nightly, sales pipelines a few times a day, and only live operations such as dispatch or stock alerts need near-real-time data.
Tool limits shape this. Microsoft's Power BI data refresh documentation says semantic models on shared capacity get eight scheduled refreshes a day, while models on Premium, Premium Per User or Fabric capacity can schedule up to 48. The same page notes that a gateway is needed when a model mixes on-premises sources with cloud sources in one query. That matters if your inventory sits in a SQL Server in the back office and your orders in Shopify.
For a custom React dashboard, refresh is whatever we schedule: a job in your cloud account that pulls each source every 15 minutes, hourly or nightly, writes to the database and records success or failure. Every refresh job we build sends an alert when it fails and shows a “data as of” time on the screen, so nobody makes a decision on yesterday's numbers thinking they are today's.
API rate limits also matter. Shopify, HubSpot and Intuit each cap how many calls an app may make in a period, so pulling everything every five minutes is neither polite nor necessary. We pull only records changed since the last run.
Role-based access in custom dashboard development
Role-based access means each person sees only the rows and pages their job requires: a regional manager sees their region, a rep sees their own deals, a client sees their own account. It should be designed with the KPI dictionary, not added the week before launch.
In Power BI this is row-level security: roles defined with DAX filter expressions, then assigned to users or security groups in the service. Microsoft's documentation adds a detail many teams miss. Row-level security only restricts people with the Viewer role in a workspace; Admins, Members and Contributors can edit the model and therefore see everything. So the person who owns the dashboard should put regional managers in the Viewer role, not make them Members out of convenience.
In a custom React app, access lives in your own code and database. We usually model it as users, roles and a scope table (region, location, client ID) and apply the filter on the server, never only in the browser. Each access rule gets a test: sign in as a sample user from each role and confirm the totals match what that role should see. Access changes are logged, and removing a departing employee is one action in the admin screen.
- List every viewer group and what they must never see
- Decide which system holds the user list: Microsoft Entra ID, Google Workspace or the app itself
- Filter data on the server or in the model, not in the chart
- Test each role with a real sign-in before launch
How much does custom dashboard development cost?
With us, a dashboard built in Power BI or Looker Studio starts at US$600, and a custom React dashboard app with its own logins and roles starts at US$900. Software licences, connector subscriptions and cloud usage are separate and paid by you to those vendors.
Across the market, quotes for custom dashboard development vary widely, and the spread usually comes from scope, not from rates alone. Four things move a quote most. The number of sources and how clean they are: one Shopify store is quick; three stores, a QuickBooks file with inconsistent classes and a sales spreadsheet maintained by hand is not. The refresh frequency and whether you need a gateway or a warehouse. The number of roles and how fine-grained each must be. And how much reconciliation your finance lead needs before they trust the numbers.
When comparing quotes, ask each provider for three things in writing: the KPI list they are pricing, the sources and refresh frequency, and your total monthly running cost after launch, including licences. A lower build figure that ignores per-viewer licences for 60 staff can end up the more expensive choice within a year. Our general pricing page shows every starting price in one place.
How long does custom dashboard development take?
A tool-based dashboard with two or three clean sources usually takes two to four weeks. A custom React dashboard app with logins, roles and several sources usually takes six to twelve weeks. Waiting for access to your systems is the most common delay, not the build itself.
The first week is almost entirely discovery and access: agreeing the KPI dictionary, getting API connections authorised by your admins and pulling a sample of each source. The middle weeks are modelling and reconciliation, which is where the real work sits. Only then do we design pages, and that part moves fast because the numbers are already agreed. The final week is role testing, refresh monitoring and training.
You can shorten the timeline by naming one person on your side who can approve definitions and grant access within a day. You can lengthen it by changing KPI definitions after reconciliation, which is fine, but it should be a conscious choice rather than a surprise.
The tech stack behind a custom dashboard build
For most US small and mid-size businesses, a practical stack is scheduled extraction jobs, a managed PostgreSQL database or BigQuery dataset in your own cloud account, SQL views that hold the business logic, and a presentation layer in Power BI, Looker Studio or React.
We keep business logic in one place. If “net revenue” is calculated in SQL, every tool reads the same definition. If it is calculated separately in Power BI, again in a React component and a third time in a spreadsheet, the numbers drift within a month. For custom React dashboards we typically use Next.js or Vite with a charting library, a Node.js API that applies access rules, and server-side caching so pages load quickly even on a sales rep's phone.
Hosting goes where you already are. A Microsoft shop often keeps the database in Azure; a Google Workspace company may prefer BigQuery; many small teams are happiest on AWS with a small managed database. Our AWS consulting page for small businesses covers setting up that account cleanly, including backups and billing alerts, if you do not have one yet.
- Extraction: scheduled jobs using each vendor's official API
- Storage: PostgreSQL or BigQuery in your account
- Logic: versioned SQL views with tests
- Presentation: Power BI, Looker Studio or Next.js with server-side access control
- Monitoring: failure alerts and a visible data-as-of timestamp
How to choose a partner for custom dashboard development
Choose someone who asks about your decisions and definitions before they talk about chart types, who proposes to work inside accounts you own, and who can explain in writing how each number will be reconciled to your books.
Useful questions: Which KPIs are you pricing, and how will each be defined? Where will the data be stored, and whose account is it? How do refresh failures get noticed? How will you test that a regional manager cannot see another region? What will I pay monthly after launch? Can another developer maintain this if you disappear?
Red flags are worth naming too. Be careful with anyone who wants your QuickBooks or Shopify admin password rather than an authorised app connection, keeps the data in their own cloud account, demos a beautiful dashboard built on sample data without ever looking at yours, or cannot explain why their total differs from your accountant's. Also be wary of the opposite: a proposal for a full data warehouse, orchestration platform and multiple environments for a 15-person company with three sources. Custom dashboard development for a small team should be small, understandable and cheap to run.
Custom dashboard development with a team in India: how it works from the US
From the US, you work with us over video calls in your Eastern morning, which is our evening, and on WhatsApp or Slack between calls. Quotes and invoices are in USD and paid by wire, Wise or PayPal. You create the accounts; we are invited in with limited roles.
India is nine and a half hours ahead of US Eastern time in summer and ten and a half in winter, so a 9 a.m. call in Boston or Atlanta lands in our early evening, and West Coast teams usually take a 7 or 8 a.m. slot. The time gap is useful for dashboard work: you review numbers during your day, leave comments, and find answers and fixes waiting the next morning.
Days 1–2
You share the tools you use and the questions you want answered. We reply with clarifying questions, then an itemised USD quote about two working days later.
Week 1 after approval
KPI dictionary drafted and agreed on a call. Your admins authorise read-only app connections to QuickBooks, Shopify, HubSpot and GA4. We pull samples and list data-quality issues with examples.
Week 2
First version of the data model in your cloud account, a reconciliation table sent to your bookkeeper, and a rough page layout you can click through.
Contracts and ownership
Scope, confidentiality and ownership are set out in your written quote; the defaults are on our terms page. Invoices come from India, and we do not visit on site.
Everything we build lives in your accounts: the database, the Power BI workspace or Looker Studio reports, the repository and the cloud project. Read our terms for the default contract language.
Worked example: a hypothetical Austin coffee roaster's custom dashboard
Say a coffee roaster in Austin sells online through Shopify, wholesale to cafés through HubSpot deals invoiced in QuickBooks Online, and runs ads measured in GA4. This is an illustrative scenario, not a client story.
The owner's questions are specific: which channel brings retail customers who reorder within 60 days, which wholesale accounts pay late, and what margin looks like per bag after shipping and refunds. Today the answer takes a weekend of exports.
The plan starts with a KPI dictionary of eleven metrics. Extraction jobs pull Shopify orders and refunds through GraphQL, HubSpot deals and companies through a read-only private app, QuickBooks invoices and payments, and GA4 channel data through the Data API, all into a small PostgreSQL database in the roaster's AWS account. SQL views define net revenue, reorder rate and days-to-pay once. The team uses Google Workspace and only four people view the dashboard, so Looker Studio is the presentation layer; that portion is quoted from our US$600 line.
Six months later, the roaster wants each wholesale café to sign in and see its own order history and invoices. That becomes a small React portal reading from the same database, quoted separately from US$900. Nothing in the first build is thrown away, which is the point of putting logic in the database rather than in the charts.
Handover and keeping a custom dashboard trusted after launch
A dashboard stays useful when someone owns each KPI, refresh failures are visible, definitions are documented and changes go through one person. Without that, trust fades quietly and people drift back to their spreadsheets.
At handover you receive the KPI dictionary, a diagram of sources and refresh jobs, the SQL or DAX for every measure, the list of roles and who is in each, and a short video walkthrough recorded on your data. We run a training call for editors and a shorter one for viewers. Maintenance is free for two months after launch; after that, care plans start at US$120/mo and cover connector breakages, API version changes and small additions.
API versions do change. Shopify retired REST for new public apps, HubSpot has moved private apps into a legacy category in its newer developer platform while still supporting them, and Google renamed Looker Studio. None of that is dramatic, but each is a reason to budget a little time every quarter to keep custom dashboard development work from going stale.
Custom dashboard development checklist before you sign off
Before launch, confirm that every KPI reconciles to its source for a closed period, each role has been tested with a real sign-in, refresh failures alert a named person, and all accounts sit in your business name.
- KPI dictionary approved by the owner of each metric
- Closed-month figures reconcile to QuickBooks reports within an agreed tolerance
- Every source connected through an authorised app, not a shared password
- Refresh schedule documented, with failure alerts and a data-as-of time on screen
- Roles tested: each sample user sees only their rows
- GA4 retention set to 14 months, or BigQuery export enabled
- Database, workspace, repository and cloud account owned by your business
- Editors trained; viewers know where to ask questions
- Monthly running cost (licences, cloud, connectors) written down
Want a second opinion on an existing dashboard first? Send screenshots and your KPI list through our contact page, and we will tell you whether it needs a rebuild or a tidy-up.