Metabase vs Tableau for Custom Software Shops: Project Profit

The hard part of this report is never the math. It is getting hours logged in Harvest or Toggl, invoices from your billing system, and ticket status from your project tracker into one place without three separate CSV exports every Friday. Metabase handles this well once the data lands in a shared database or warehouse: write one query that joins hours to rates to invoiced amounts, and margin per project falls out automatically.

Tableau does the same join, but through its own data modeling layer rather than a query you can hand to another engineer to read. That is more setup, and it pays off once you have enough active projects and enough non-technical staff (a delivery lead, an account manager) who need to see margin without learning SQL.

Billable utilization, the share of an engineer's paid hours that actually land on a client invoice, is the other number that determines whether the shop is healthy. A Metabase dashboard filtered by engineer and week answers "who is underutilized this month" in seconds, and a scheduled Slack alert can flag anyone under a threshold before the monthly close instead of after it.

Tableau adds real value here once you want to slice utilization by seniority, by practice area, or by client vertical for a partner-level review, and once that view needs to look consistent across every leadership meeting rather than get rebuilt each time.

Say a fixed-bid project was scoped at 400 hours and priced accordingly. By week six, a Metabase dashboard joining Harvest hours to the project record shows 260 hours already logged against a project that is only forty percent complete by ticket count. That gap, hours burned against delivery progress, is exactly the kind of early warning a spreadsheet updated monthly cannot give you. The same query run weekly instead of at project close turns a surprised loss at delivery into a scope conversation with the client in week seven, while there is still time to have it.

A Tableau version of the same dashboard would add one more layer: showing the delivery lead their project alone, the practice lead every project in their group, and the managing partner the firm-wide picture, all from one governed data source instead of three separately maintained spreadsheets.

Most custom software shops do not have anyone whose job is analytics engineering, so the setup path matters as much as the finished dashboard. Connect your time tracking and billing tools to a small warehouse or directly to Metabase if they already write to a database. Build the hours-to-margin query first, since it is the one number that changes how you scope the next project. Utilization and pipeline dashboards can follow once that first one is trusted.

Disqualifier: skip Tableau at this stage if nobody has a few weeks to spend modeling the data properly, since an unmaintained Tableau workbook goes stale faster than a query you can just reopen and fix.

Set up project margin reporting in this order:

1. Connect your time tracking and billing tools to a small warehouse, or directly to Metabase if they already write to a database.
2. Build the hours-to-margin query first, joining hours to rates to invoiced amounts, since it is the one number that changes how you scope the next project.
3. Compare hours logged against delivery progress by ticket count, so a fixed-bid project burning hours too fast shows up early.
4. Add a scheduled Slack alert for engineers under a utilization threshold, so the flag arrives before the monthly close instead of after it.

A fixed-bid engagement and a time-and-materials retainer need genuinely different charts, not the same chart with a different filter. On a fixed-bid project, the dashboard that matters is hours consumed against the original estimate, because that gap is your entire risk exposure and the client's invoice does not move with it. On a time-and-materials retainer, the number that matters is closer to a pacing chart: hours billed so far this month against the monthly cap, so nobody discovers on the thirtieth that a client blew through their budget two weeks ago.

Building both into one shared dashboard, filtered by contract type, is straightforward in either tool once the underlying project records are tagged correctly. The mistake most shops make is tagging that distinction inconsistently in the project management tool in the first place, which no dashboard can fix after the fact.