"If we self-host Matomo or Umami, the revenue dashboard is free, right?" That's one of the most common questions I hear from SMB EC operators in Japan. The short answer: license-fee-free is not TCO-free. After laying four options side-by-side at Japanese freelance rates, self-hosted dashboards land at ¥460K-880K per year — 4-7x the cost of a focused SaaS like the one I'm building.
I've been building RevenueScope for the Japan SMB EC market, so I have a stake in this comparison. But the math here is structural, not promotional: when you account for build hours, ongoing ops, server costs, and learning curve, "free" OSS quietly becomes one of the most expensive choices on the table.
This post walks through the TCO breakdown, the three hidden cost layers most operators miss, and a 3-question framework that decides between self-hosted and SaaS in about 60 seconds.
TL;DR
- Self-hosting Matomo, Umami, or rolling your own GA4+Looker Studio dashboard runs ¥460K-880K per year at a ¥5,000/hour Japanese freelance rate (industry-average estimates, not measured ground truth).
- A focused SaaS option for SMB EC — RevenueScope Growth at ¥9,800/month (~¥117K/year) — sits 4-7x lower on TCO.
- The hidden cost is a three-layer stack: opportunity cost (40 build hours not spent on revenue work), learning curve (Matomo configs, GA4 event design, Looker DAX), and upgrade churn (OSS major versions, GA4 API breaks). License-fee-zero hides all three.
Why "TCO" matters more than license fees
The "OSS is free" intuition only counts software license cost. Real total cost of ownership for an EC operator pulls in at least four other line items:
- Initial build hours — server setup, tracking install, dashboard build, first-pass QA
- Monthly ops hours — data quality checks, tracking fixes, new metric requests, incident response
- Server cost — VPS / cloud / storage
- Learning curve — docs, Stack Overflow, internal wiki, knowledge transfer
Counted as labor at ¥5,000/hour (the Japanese freelance marketing/data-analyst median), self-hosted TCO climbs into the high hundreds of thousands of yen — quickly.
The second concept that operators tend to miss is opportunity cost. Forty hours spent building a Matomo dashboard is forty hours not spent on creative A/B tests, LP iterations, or email segmentation work. For a JPY-10M-monthly EC, those forty hours represent roughly 25% of a working month — directly tradeable against revenue work.
License-fee-zero and TCO-zero are different numbers. That's the starting point for any honest comparison.
One-year TCO across four options
I lined up Matomo On-Premise, Umami v3, GA4 + Looker Studio, and RevenueScope Growth at industry-average estimates (not measured ground truth — your numbers will vary).
The annual numbers (rounded, ¥5,000/hr labor):
- Matomo self-hosted — ~¥880K (40h build + 8h/mo ops + ¥3K/mo hosting + 16h learning)
- Umami self-hosted — ~¥460K (20h build + 4h/mo ops + ¥2K/mo hosting + 8h learning)
- GA4 + Looker Studio — ~¥500K (16h build + 6h/mo ops + 12h learning; product is free, your time isn't)
- RevenueScope Growth — ~¥117K (¥9,800/mo plan + ~0.5h/mo to actually look at the dashboard)
The "free" intuition collapses the moment you add 40 build hours and 6-8 ongoing ops hours per month at Japanese freelance rates. The license is the small line item; labor is everything else.
The three hidden cost layers
Beyond the headline numbers, three layers of hidden cost stack on top of self-hosting and account for most of the gap between OSS and SaaS economics.
Layer 1 — Opportunity cost. Forty hours building Matomo is forty hours not running creative A/B tests or shipping LP improvements. For JPY-10M-monthly EC, that's roughly 25% of a working month redirected away from revenue work. The TCO row "build hours = ¥200K" is the direct cost; the indirect cost (campaigns not run, pages not improved) is often larger.
Layer 2 — Learning curve. Matomo's admin surface is dense; custom report authoring is close to writing SQL by hand. GA4 demands real care around event design, custom dimensions, and the data layer. Looker Studio adds calculated-field syntax (DAX-adjacent) plus BigQuery SQL knowledge if you take the connector route. Each one has a real ramp before the dashboard becomes operational.
Layer 3 — Upgrade churn. OSS ships major versions; GA4 breaks API contracts; Looker Studio re-skins UIs. Matomo schema migrations, GA4 export schema changes that retroactively break your queries, Looker chart configs that need re-doing — these arrive a few times a year and don't fit cleanly into the "monthly ops hours" budget. SaaS providers absorb this churn on your behalf.
Stack the three layers together and the gap between "Matomo at ¥880K" and "RevenueScope at ¥117K" stops looking like a margin choice. It looks like a structurally different cost model.
A 3-question decision framework
For SMB EC operators wondering which side they fall on, three binary questions resolve it in about 60 seconds.
Q1 — Are you a JPY-10M-50M monthly Shopify / BASE / STORES / EC-CUBE operator? If yes, continue. If under JPY-10M, GA4 + Looker Studio with a hand-built dashboard is usually proportionate. If over JPY-1B, you're in BI-tool territory (Tableau, Looker, Mode).
Q2 — Do you want engineering and ops hours pointed at revenue work, or at dashboard maintenance? If revenue work, lean toward SaaS. If dashboard work is part of how you want to spend the team, OSS makes sense — and it's a legitimate choice when you have an in-house philosophy around tooling ownership.
Q3 — Are Revenue, AOV, RPS, CVR, plus Sessions enough? If yes — that's RevenueScope's deliberate scope cap (4 core metrics + Sessions = 5 KPI cards). If you need MMM, MTA, margin, LTV, inventory, or in-app ROAS computation, look at full-stack tools (Triple Whale category) instead.
Note: RevenueScope intentionally does not compute ad-spend ROAS in-app. Ad consoles (Meta, Google, TikTok) already surface ROAS natively; calculating it again in a separate tool just doubles the surface area to maintain. Delegating ROAS to the tool best positioned to compute it is a deliberate scope decision.
When self-hosting genuinely makes sense
To be clear about when OSS or DIY is the right answer:
- Compliance-driven — when first-party customer-data residency on your own servers is a hard requirement (large enterprise, regulated industries)
- Engineering-rich teams — when in-house engineers are already comfortable with Linux server ops and treat tooling as part of the platform
- Bespoke metrics — when you need indicators no SaaS will model out of the box, and you want full control over the schema
- Above JPY-1B/month — at large scale, SaaS per-event pricing can flip; self-hosting can become the cheaper option
For SMB EC with marketing teams of 1-3 and no dedicated engineer, none of these usually apply. That's the population where the TCO gap matters most — and where a focused SaaS earns its keep by removing the three hidden cost layers entirely.
Closing
"OSS is free" is technically true and operationally misleading. License-fee-zero stops mattering once you count 40 build hours and 6-8 monthly ops hours at ¥5,000/hour. The real question for an SMB EC operator isn't "free vs paid" — it's "do I want my team's hours pointed at revenue work or at dashboard maintenance?"
The full breakdown — per-option TCO math, suitability profiles, and references — is at Matomo / Umami / GA4+Looker Studio Self-Build vs RevenueScope: 1-Year TCO for EC Revenue Dashboards. For the prior post in this series (full-feature SaaS comparison, not self-build), see Triple Whale vs RevenueScope.
Top comments (0)