Worked Example: What It Costs a 200-Customer SaaS to Ship Customer-Facing Dashboards

Editorial Note: This Is an Illustrative Model, Not a Customer Story

ShiftStack is not a customer. ShiftStack does not exist. We invented it so the numbers in this post could be specific instead of vague.

Dashrendr launched publicly on Product Hunt a few weeks ago. We do not yet have a customer with a year of production history and a signed-off results page, and we would rather say that plainly than dress up a fictional logo as a real one. What we do have is the architecture, the published pricing of every platform in this category, and a lot of conversations with developers who are weighing the same decision.

So this is a worked example. Every figure below is an assumption, labeled as such. None of it is a claim about any real company's results, including ours. The value here is the structure of the calculation, not the output. Swap in your own numbers and the model still works.

The Scenario

ShiftStack is a hypothetical B2B SaaS selling workforce scheduling to mid-market logistics and hospitality companies. For the purposes of this example, assume:

• 200 paying customers, averaging $7,000 ARR each, so roughly $1.4M ARR
• Six engineers, none of them dedicated to data
• PostgreSQL 15 on RDS as the primary operational database, around 40 million rows in the shift events table
• No data warehouse, no analytics engineer, no dbt
• Customers currently get a CSV export button and nothing else

The trigger is commercial, as it usually is. Three deals in the last quarter stalled at procurement because the buyer wanted reporting their operations managers could open themselves. Support is fielding a steady stream of "can you pull the numbers for March" requests. Someone proposes building dashboards in-house. Someone else proposes buying. Nobody has a number.

Step One: Write Down the Requirements Before the Cost

Most build-versus-buy arguments go badly because the two sides are costing different products. Pin the requirements first. For ShiftStack, assume the list is:

• Each customer sees only their own data, enforced server-side, with no possibility of a tenant ID being spoofed from the browser
• Six to eight standard charts covering shift coverage, overtime, no-show rate, and labor cost trend
• Date range and location filters
• Dashboards styled to match the ShiftStack product, not an obvious third-party iframe
• CSV and PDF export, because procurement asked
• Sub-two-second load on the median dashboard
• Admin users at a customer can see all their locations, managers see one

Note what is not on the list: ad-hoc query building, custom chart authoring by end users, a semantic layer, or white-labeled sub-accounts. Those are the requirements that make the build option genuinely expensive, and ShiftStack does not need them yet. Being honest about scope is the single biggest lever on this calculation.

Step Two: The Architecture Is the Same Either Way

A detail that gets lost in build-versus-buy debates: the hard parts of multi-tenant customer-facing analytics do not disappear when you buy. They just move.

Tenant isolation

ShiftStack needs row-level security enforced at the data layer, not in application code. In PostgreSQL that means ENABLE ROW LEVEL SECURITY on the relevant tables and a policy keyed to a session variable set from a verified token. If isolation lives in a WHERE clause in your API handlers, one forgotten clause is a cross-tenant data leak. This is true whether you build the charts yourself or embed them.

Query load

Forty million rows is comfortable for Postgres until 200 customers start opening dashboards on Monday morning. The realistic answer for ShiftStack is a pre-aggregated rollup table refreshed every 15 minutes, with the live table reserved for drill-downs. Assume that is roughly one engineer-week of work on its own, and assume it is unavoidable in both scenarios.

Read replica

Analytics queries should not compete with the scheduling app for connections. Assume an RDS read replica at about $280 per month, so $3,360 per year. Again, both scenarios.

Set these three aside as common costs. The build-versus-buy difference is everything on top: the chart layer, the embedding and auth plumbing, the filter and export UI, and the ongoing maintenance of all of it.

Step Three: Costing the Build

Assume a fully loaded engineering cost of $180,000 per year, which is about $3,460 per engineer-week. Assume two engineers on the project.

• Chart components, responsive layout, and theming: 6 engineer-weeks
• Auth, signed tokens, and tenant scoping for the analytics endpoints: 4 engineer-weeks
• Filter state, URL persistence, and empty or error states: 3 engineer-weeks
• CSV and PDF export, including server-side rendering for PDF: 3 engineer-weeks
• Caching, performance tuning, and load testing: 2 engineer-weeks
• QA, accessibility, and cross-browser fixes: 2 engineer-weeks

Total: 20 engineer-weeks, or roughly $69,200 in year one.

Then maintenance. Dashboards are not a ship-and-forget feature. Chart library upgrades, new metrics requested by sales, browser regressions, and performance work as data grows. Assume 15% of one engineer's time ongoing, or about $27,000 per year.

There is also the cost nobody puts in the spreadsheet: those 20 engineer-weeks were not spent on the scheduling product. If you believe your roadmap has commercial value, that opportunity cost is the largest line item on this page, and it is the one most likely to be waved away in the meeting.

Step Four: Costing the Buy

Embedded analytics platforms in 2026 price in roughly three bands: usage-based developer tooling in the low thousands annually, mid-market platforms in the $10,000 to $30,000 range, and enterprise suites that start near six figures and scale with end users. For ShiftStack, assume a mid-market platform at $12,000 per year. Check real pricing before you reuse that figure, including how it scales with end users rather than customer accounts, which is where these contracts tend to surprise people in year two.

Integration work does not vanish:

• Connecting the data source and modeling the six to eight charts: 1 engineer-week
• Embedding, signed token handoff, and theming: 1 engineer-week

Total: 2 engineer-weeks, or roughly $6,920, plus $12,000 in license. Year one lands near $18,900.

Step Five: The Three-Year Comparison

Common costs (rollup table, read replica) are excluded because they apply equally to both paths.

Build: $69,200 year one, then $27,000 per year maintenance. Three-year total: $123,200.
Buy: $18,900 year one, then $12,000 per year license. Three-year total: $42,900.
Difference: roughly $80,300 over three years, and about 18 engineer-weeks returned to the product roadmap.

Time to first customer-visible dashboard matters too. In this model, buying ships in two to three weeks and building ships in ten to twelve. For a team with three stalled deals, that gap is not a rounding error.

Where This Model Breaks

A worked example is only honest if it shows its own failure modes. Buying stops winning when:

• Analytics is the product. If customers are paying you primarily for insight, the chart layer is core IP and outsourcing it is a strategic mistake, not a cost saving.
• Your visualizations are genuinely unusual. Standard charts are commodity. A domain-specific interactive view that no platform supports will fight the abstraction forever.
• Per-end-user pricing collides with your model. A platform at $12,000 for 200 accounts can become $60,000 when those accounts have 40 seats each. Model year three, not year one.
• Data residency or air-gapped deployment is contractual. This narrows the vendor list fast and can eliminate it entirely.
• You already have the team. A company with a platform team and a design system has a materially lower build cost than the 20 weeks modeled here.

Change the assumptions and the conclusion changes with them. That is the point of writing them down.

How to Run This for Your Own Company

Copy the structure, not the numbers:

1. Write the requirements list first, and be ruthless about what is genuinely needed in version one.
2. Separate the common costs that apply to both paths, so you are comparing only the real difference.
3. Estimate build in engineer-weeks, then multiply by your actual fully loaded cost.
4. Add ongoing maintenance at 10% to 20% of one engineer. Do not set it to zero.
5. Get real quotes, and model them against your year-three user count.
6. Put a number on time-to-ship, especially if there is revenue waiting on it.

Even a rough version of this beats the usual process, which is whoever argues most confidently in the meeting.

Conclusion

ShiftStack is fiction. The decision is not, and it is one developers bring to us most weeks. In this particular hypothetical, buying wins by roughly $80,000 over three years and ships two months sooner, mostly because the requirements are conventional and the team is small. Change either of those and the arithmetic moves.

When we have customers with real production numbers and permission to publish them, we will replace this post with the genuine article. Until then, the honest version is the one where you can see every assumption and argue with it.

If you want to pressure-test the buy side of this model, our pricing is public. Bring your own numbers.