LLM.coPrivate, self-hosted LLM deployments
Legal AI infrastructure for firms
AI RFP discovery and response drafting
Automatic.coBusiness process automation
Secure AI virtual data rooms10 business days
To start a Tableau engagement
Scoping through first sprint
100%
Senior engineers, US-based
Tableau Desktop, Server, and Cloud experience
Every sprint
Working dashboards on a preview site
Not a status deck between milestones
100%
Workbooks and data sources you own
Deployed under your own Tableau site
What we build with Tableau
Tableau work, by what's actually being asked for
On its own, Tableau produces a simple report. The gap between that and a dashboard a decision-maker trusts and returns to is almost entirely architecture and design work, not the platform's default behavior.
Dashboard development
Built against data-visualization design practice, not Tableau's default chart formatting — the goal is a dashboard someone can read a decision out of in under a minute, not one that requires a legend and a guided tour.
Calculated fields and LOD expressions
Level of Detail expressions for calculations that need to operate at a different granularity than the view — the single most common source of a dashboard whose numbers don't reconcile with what a user expected.
Data source architecture
Deciding whether a dashboard connects live or to an extract, and whether Tableau sits on top of a properly modeled data warehouse or joins raw transactional tables directly — a decision that determines both performance and long-term maintainability.
Automation and scheduled refresh
Extract refresh scheduling and Tableau's REST and Metadata APIs used to automate what would otherwise be manual — publishing, permission assignment, and content auditing across a growing site.
Embedding
Tableau dashboards embedded into an internal portal or customer-facing application via the Embedding API, with authentication and row-level filtering that carry through correctly rather than exposing a generic public view.
Governance and administration
Tableau Server or Tableau Cloud site structure, permissions, and content certification set up so the platform scales past one analyst's personal workbook collection.
The decision that matters most
Extracts vs. live connections, and what actually decides it
This single decision, made per data source rather than as a blanket policy, is the biggest lever on whether a dashboard feels instant or makes someone wait.
Extracts are usually faster and more resilient
Tableau's in-memory extract engine (Hyper) compresses and indexes data for fast interaction, and it insulates the dashboard from a slow or unstable source database. The tradeoff is data freshness — an extract is only as current as its last scheduled refresh.
Live connections earn their place with real-time needs
Operational dashboards that need to reflect data within minutes, or sources too large to extract practically, are the genuine cases for a live connection. The cost is that dashboard performance is now bounded by the source database's query performance, not Tableau's.
LOD expressions solve a specific class of problem
Fixed, Include, and Exclude LOD expressions let a calculation operate at a granularity different from the visualization — total customer count alongside a per-region breakdown, for instance. Getting LOD scope wrong is the most common reason a dashboard's numbers look right at first glance and wrong on closer inspection.
Context filters change the performance profile, not just the results
Setting a filter as a context filter forces Tableau to compute it before other filters, which can meaningfully speed up a dashboard with several dependent filters — but it also changes how filters interact with each other, so it's a decision made deliberately, not applied by default.
A star schema feeding Tableau beats raw joins inside the workbook
Doing join logic in the underlying data model, rather than inside every Tableau data source, means one place to fix a data problem instead of auditing every workbook that touches the same tables.
Extract filters shrink what actually needs to be fast
Filtering an extract down to the data a dashboard actually needs, rather than pulling an entire table and filtering in the view, is one of the simplest, most underused performance fixes available.
What's involved
Tableau engagement types
What moves the scope is less the dashboard count and more the state of the data underneath it — a clean, modeled source is a different project than one that needs an ETL pipeline built first.
| Engagement | Commitment | Timeline | What's included |
|---|---|---|---|
| Dashboard & data source audit | Fixed scope | 1 – 2 weeks | Review of existing workbooks, data source design, and refresh performance, with a prioritized fix list. |
| Dashboard build-out | Fixed scope | 3 – 8 weeks | Dashboards built for a specific workflow or team, including the calculated fields and LOD expressions they need. |
| ETL & data pipeline for Tableau | Fixed scope | 4 – 12 weeks | A modeled data source feeding Tableau reliably, rather than dashboards querying raw transactional tables directly. |
| Server or Cloud governance & row-level security | Fixed scope | 3 – 6 weeks | Site structure, permissions, and user-filter-based row-level security so one dashboard serves every team correctly. |
| Embedding build | Fixed scope | 4 – 8 weeks | Tableau dashboards embedded into a portal or application via the Embedding API, with authentication carried through. |
| Ongoing dashboard development & support retainer | Ongoing retainer | Ongoing | Standing ownership of dashboards, data sources, and site administration as new questions come in. |
Ranges assume US-based senior engineers with Tableau Desktop, Server, and Cloud experience. The audit exists because a slow dashboard is very often a data-source design problem, not something more dashboard tuning fixes.
Where Tableau fits
Next to the rest of the stack, not instead of it
Tableau is a visualization and exploration layer. Treating it as the data pipeline, the warehouse, and the governance system all at once is how a Tableau site becomes unmanageable within a year.
Tableau vs. Power BI
The honest deciding factor is usually your existing ecosystem more than a feature comparison — a Salesforce- or Google-centric organization tends to get more out of Tableau's flexibility, while a Microsoft-centric organization often gets more value from Power BI's tighter integration with the rest of that stack.
Tableau Prep vs. a real data pipeline
Tableau Prep is genuinely useful for light, analyst-driven data shaping, but it isn't a substitute for a scheduled ETL/ELT pipeline once transformation logic needs to be reliable, tested, and shared across more than one workbook.
A data warehouse belongs underneath Tableau, not optional
Connecting Tableau directly to transactional production databases is a common early shortcut that stops working once dashboard query load competes with the application itself for database resources. A warehouse or reporting replica removes that contention.
The Embedding API vs. a public embed link
A public embed link is fine for a low-stakes internal share. Anything customer-facing, or anything that needs row-level security to carry through to an embedded view, needs the Embedding API with proper authentication — not a workaround built on public URLs.
Explain Data and AI features earn their place selectively
Tableau's Explain Data and related AI-assisted features are genuinely useful for surfacing an unexpected data point's likely drivers, but they work best as an analyst's starting point for investigation, not as an unreviewed answer presented directly to an executive.
Predictive analytics usually needs a real model behind it
Tableau can visualize the output of a predictive model well, but the model itself typically belongs in a proper data science workflow, not built as a Tableau calculated field trying to approximate one.
Governance
The part that decides whether Tableau scales past one analyst
A single analyst's Tableau Desktop workbook doesn't need governance. Forty people across five teams publishing to the same Server or Cloud site does — and the gap between those two states is where most Tableau deployments actually fail.
Site and project structure
Organizing Tableau Server or Cloud into projects that map to actual teams and data-sensitivity levels, rather than one flat list of every workbook anyone has ever published, is what keeps content findable and permissions manageable.
Row-level security via user filters
One dashboard built with a user-filter-driven security model, rather than a separate workbook per team, means one place to fix a bug and one source of truth everyone is actually looking at.
Content certification
Marking specific workbooks and data sources as certified gives users a clear signal for which version is the trusted one, which matters once workbook sprawl means three people have built three slightly different takes on the same metric.
Version control for workbooks and data sources
Treating Tableau workbooks and the calculated logic inside them with the same change-tracking discipline as application code is what prevents "which version is live" from becoming a recurring question.
Quality checks belong in the pipeline, not the dashboard
Naming consistency, grouping logic, and null-value handling are cheaper to fix once in the data source than to patch inside every workbook that touches the same field.
Related
Related services
What Tableau projects usually connect to.
Questions
Common questions about Tableau development
What teams ask before a first call.
Tableau is a data visualization and business intelligence platform for building interactive dashboards from relational databases, cloud data warehouses, and spreadsheets. The honest choice between Tableau and Power BI usually comes down to your existing ecosystem more than a feature-by-feature comparison — Tableau tends to fit organizations already invested in Salesforce or Google's stack, while Power BI tends to fit Microsoft-centric organizations more naturally.
What drives the number is less the dashboard count and more the state of the data feeding it — a clean, already-modeled data source is a much smaller project than one that needs an ETL pipeline and a data warehouse built underneath it first.
A dashboard and data source audit is usually the fastest way to find out which situation you're actually in.
A Tableau developer handles the data source architecture, LOD expressions, performance tuning, and Server/Cloud governance that determine whether a dashboard is fast, accurate, and secure at scale. A business analyst is often the right person to build a specific dashboard's logic and visual design once that foundation exists. Many organizations need both, and a lot of Tableau's reputation problems come from asking one role to do the other's job.
Extracts are the right default for most reporting use cases — they're faster, more resilient to a slow source database, and only cost you the gap between refresh cycles. Live connections earn their place specifically for operational dashboards that need near-real-time data, or sources too large to extract practically.
This is a decision made per data source based on actual freshness requirements, not a blanket policy applied to every dashboard.
Yes — using Tableau's user-filter-based row-level security to build one dashboard that shows each viewer only their own data, rather than maintaining separate workbooks per team. This keeps a single source of truth instead of multiple versions that can drift apart.
Mostly through data source design decided before the dashboard is built: extract filters that shrink the data to what's actually needed, a properly modeled warehouse underneath instead of raw joins inside the workbook, and LOD expressions used deliberately rather than as a default way to handle every calculation.
A dashboard that's slow almost always traces back to one of these design decisions, not to Tableau itself being underpowered.
Yes, using Tableau's Embedding API with proper authentication and row-level filtering carried through to the embedded view — not a public embed link, which is fine for a low-stakes internal share but isn't the right approach for anything customer-facing or permission-sensitive.
Yes. Workbooks, data sources, and any ETL or pipeline work are deployed under your own Tableau Server or Cloud site and your own data infrastructure, not held in a system only we can access. That's the only arrangement that doesn't lock your reporting to a single vendor for its next dashboard or its next hire.