Open QuickBooks for what was invoiced, open the CRM for what is in the pipeline, then reconcile the two by hand in a spreadsheet. The request to make that one screen is common, and the build is not exotic. What decides the cost is a handful of choices people tend to make late: which system owns which number, how fresh the data has to be, and whether anything writes back. Here is the whole sequence, including the parts that reliably cost more than expected.
The request usually arrives in the same shape. Someone opens QuickBooks to see what was invoiced, opens the CRM to see what is in the pipeline, opens a spreadsheet where a staff member reconciles the two by hand, and asks whether all of that could just be one screen.
It can. The build is not especially exotic. What makes or breaks it is a set of decisions people tend to make late, when they are expensive to change: which system owns which number, how often the data syncs, and what happens when the two sources disagree. This is a walkthrough of the whole thing, including the parts that cost more than expected.
What people actually mean by “dashboard”
Three different projects hide behind the same word, and they differ in cost by roughly an order of magnitude.
- A reporting view. Read-only. Pulls numbers from systems you already run and displays them together. Nobody edits anything. This is the cheapest and it is what most small businesses actually need.
- An operational dashboard. Read and write. Staff take actions from it: mark a job complete, assign an owner, flag an invoice. Now you need permissions, an audit trail, and conflict handling.
- A replacement system. The dashboard becomes the system of record and the old tools get retired. Largest scope, and the only one where data migration is on the critical path.
Being honest about which one you are asking for is the single biggest lever on the quote. A reporting view that someone describes as “simple” but expects to write back into QuickBooks is not a reporting view.
The five questions that decide the architecture
1. Which system owns each number?
If a customer's name exists in both QuickBooks and the CRM and they disagree, one of them has to win. Decide this per field, in writing, before anyone writes code. The usual split is that finance data is owned by the accounting system and pipeline data is owned by the CRM, but the edge cases are where projects stall. Who owns the mailing address? Who owns whether an account is active?
2. How fresh does the data need to be?
“Real time” is expensive and usually unnecessary. A dashboard that refreshes every fifteen minutes costs a fraction of one that reflects changes instantly, and for a morning operations review nobody can tell the difference. Ask what decision the number drives and how quickly. If the answer is “I look at it with coffee,” nightly is fine.
3. Read-only, or read and write?
Writing back into QuickBooks changes the risk profile of the whole project. A bug in a read-only dashboard shows a wrong number. A bug in a write path creates a wrong invoice. Write access is often worth it, but it should be a deliberate decision with testing budget attached, not something that gets added in week six because it seemed convenient.
4. Who sees what?
Role-based access is the requirement people forget to mention and then treat as obvious. The moment a dashboard shows revenue, somebody on staff should not see all of it. Retrofitting permissions into an app that assumed one trusted user is one of the more expensive changes you can make, because it touches every query rather than one screen.
5. What happens when an integration breaks?
It will. Tokens expire, APIs get versioned, someone renames a field. The question is whether your dashboard fails loudly or silently. Silent failure is worse than an outage, because the numbers keep rendering and they are quietly stale. Insist on sync-status visibility and alerting. It is a small line item that prevents the failure mode that destroys trust in the tool.
What it costs, and what drives the number
Our own pricing for this work follows the same bands as other custom builds: most internal tools and dashboards land between $15,000 and $60,000, quoted fixed-price after a scoping phase. Where a project sits in that range comes down to four things, in roughly this order of impact:
- Number of integrations. Two systems is a project. Five is a different project. Each one brings its own auth, rate limits, and failure modes.
- Write access. Read-only to read-write is not a small increment. It adds validation, conflict handling, and a real testing burden.
- Number of distinct roles. One role is trivial. Four roles with overlapping permissions is a design problem before it is a coding problem.
- Historical data. Starting fresh is cheap. Migrating and reconciling years of records is often the largest single line item, and it is the one most often left out of initial estimates.
When you should not build one
Three situations where custom is the wrong answer, and we will tell you so:
- Your CRM already does it and nobody configured it. A surprising share of dashboard requests are met by reports that ship with the software. Check first. It is free.
- You need a chart, not a system. If the requirement is genuinely a few visualizations over one data source, a BI tool pointed at your data will get there faster and cheaper than anything bespoke.
- The underlying process is not settled. Software makes a process faster and more rigid. If the process is still changing weekly, building it into an application locks in something you are about to change.
Custom earns its cost when the workflow is specific to how you operate, when off-the-shelf forces you to work around it, and when the manual reconciliation is consuming real hours every week. If you are replacing a spreadsheet stack rather than adding a chart, the case is usually straightforward. We covered that decision in more depth in replacing spreadsheets with custom software and in build versus buy.
A realistic sequence
The projects that go well tend to run in this order, and the first step is the one people want to skip.
- Write down the questions the dashboard answers. Not the fields. The questions. “How much did we invoice this month against pipeline?” is a requirement. “Show QuickBooks data” is not.
- Map ownership per field across the systems involved, and settle the conflicts on paper.
- Build the read-only version first and put it in front of staff. Half of what people ask for stops mattering once they can see the numbers at all.
- Add write paths one at a time, each with its own testing, rather than as a single phase.
- Add roles once the screens are settled, because permissions designed against a moving interface get designed twice.
Most of these builds ship a useful first version in four to ten weeks, with the read-only view live well before the whole scope is finished. That sequencing matters more than it sounds: an unfinished dashboard people are already using generates better requirements than any amount of upfront specification.