Why per-connection pricing punishes multi-product founders

From the SoleOS answers series — written about our own product space; grounded in published definitions and documented behavior, never invented numbers.

Per-connection pricing charges you for every data source you link — one fee for Stripe, another for RevenueCat, another for each app's App Store account — instead of charging for the outcome you actually want, which is visibility across a portfolio. For a founder with one product and one payment processor, that's fine. For a founder running five, ten, or twenty small apps, each with its own Stripe account, RevenueCat project, and app store listing, the bill scales with your architecture, not your revenue. You end up paying the most exactly when your portfolio is working the way it's supposed to: many small, low-maintenance products instead of one big one.

What "per-connection" actually means

Most dashboard tools price one of two ways. The first is per-source: every distinct data connection — a Stripe account, a RevenueCat project, a GA4 property — is a billable unit, often $10–$50/month each on its own. The second is per-project or per-plan-tier, where a flat monthly fee includes a fixed number of connected projects or sources, and you upgrade tiers when you cross that line.

Per-source pricing looks cheap at first because the entry price is low. The problem shows up as you add products. If you track Stripe and RevenueCat separately for the same app (which is common — see tracking Stripe and RevenueCat together for why they rarely agree and both are worth watching), that's two sources for one product before you've even added a second app. Multiply by ten apps and you're paying for 15-20 connections to get a view of a portfolio that might be doing $3,000/month combined.

The math that catches founders off guard

Say you run six apps. Three are subscription mobile apps with Stripe or RevenueCat plus App Store Connect and Google Play. Two are web SaaS products with Stripe and GA4. One is a content site with Search Console and AdSense. That's roughly 14 distinct data sources for six products.

At $15/connection/month, that's $210/month before you've looked at a single number. At $25/connection, it's $350/month. Compare that to a flat portfolio tier — SoleOS's Maker plan, for example, is $39/month for up to 15 projects, with every supported connector included at no extra charge. The gap isn't marginal; it's the difference between a tool that's a rounding error and one that's a real line item on a portfolio doing modest revenue.

This is the core mismatch: per-connection pricing assumes more connections means more usage of the tool, which is true for a single company with many integrations. But for a solo founder, more connections usually just means more products, each contributing a small amount of revenue. You're being charged enterprise-style integration fees for running a lean, diversified portfolio — the opposite of what the pricing model was built to price.

It punishes the architecture that makes a portfolio resilient

The whole point of running several small products instead of one big one is that no single app has to carry the business. That means intentionally keeping things separate: separate Stripe accounts to simplify taxes and payouts, separate app store listings, separate analytics properties so one app's traffic spike doesn't skew another's baseline. Real numbers from a 10-app portfolio show what that separation actually looks like once you total it up.

Per-connection pricing directly taxes that architecture. It creates an incentive to consolidate — fewer Stripe accounts, fewer analytics properties — not because consolidation is better for the business, but because the dashboard bill goes down. That's a bad reason to change how you structure your products.

When flat, project-based pricing still isn't enough

Flat per-project pricing isn't automatically better — it just moves the constraint. If a plan caps you at 5 projects and you're managing 8 small experiments, you're either paying for an upgrade tier you don't fully use or splitting your portfolio across two accounts, which defeats the purpose of a single view. Before switching tools over pricing structure alone, check what a plan's project cap actually covers, and whether "project" means "app" or "connection" — vendors define this differently, and some quietly count a mobile app's App Store and Play Store data as two projects. SoleOS pricing counts a project as a product, not a per-source connection, but read the fine print on any tool you're evaluating, including ours.

What to actually compare

When you're pricing out dashboard tools for a multi-product setup, ignore the sticker price and calculate three numbers:

• Cost per product, not cost per connection — total monthly bill divided by number of apps you're tracking.
• Marginal cost of your next product — does adding app #7 cost $0 (within a tier), a fixed step-up (next tier), or a new per-connection fee? This is the number that determines whether the tool scales with you or against you.
• Cost if you split a payment stack — if you ever track both Stripe and RevenueCat for one app (recommended, since they rarely match), does that count as one project or two?

If a tool's marginal cost for a new small app is close to zero, it rewards portfolio growth. If it's a fixed per-connection fee, it taxes it. Run this math against your own current or planned portfolio size before signing up for anything, including SoleOS — a two-app founder with simple Stripe billing might genuinely be fine with a spreadsheet (see SoleOS vs a spreadsheet for where that line sits) or a cheaper single-source tool. You don't need portfolio pricing if you don't have a portfolio yet.

Disclosure: SoleOS wrote this post about its own space — pricing models for multi-product dashboards — so read the comparison with that in mind, and check SoleOS vs Baremetrics for a head-to-head against a well-known per-source-priced tool.

Frequently asked questions

Is per-connection pricing ever fair?

Yes — for tools where connections roughly track usage or infrastructure cost, like API-heavy integration platforms, per-connection pricing accurately reflects load. The mismatch specifically arises for portfolio dashboards used by solo founders, where "more connections" usually means "more small products," not "more usage of one product."

How do I know if a plan's "project" limit really covers my portfolio?

Ask the vendor (or check their docs) whether a project means one product or one data source. A mobile app with RevenueCat, App Store Connect, and Google Play could count as one project or three depending on the tool. Get this in writing before committing to a plan, especially an annual one.

Does SoleOS charge per connector?

No — SoleOS plans are priced by number of projects (5, 15, or 40 depending on plan), and all supported connectors — Stripe, RevenueCat, GA4, Search Console, App Store Connect, Google Play, PostHog, Firebase, Supabase, and Bing Webmaster — are included at no extra per-source cost. See what SoleOS connects to for the full list and how access scopes work.

What if I only have one or two products right now?

Per-connection pricing may genuinely be cheaper at that scale, or a spreadsheet may be enough — see SoleOS vs a spreadsheet. Portfolio-tier pricing pays off once you're juggling enough sources that "just check each dashboard separately" starts costing you real time every week.

Should I switch tools purely because of a pricing model?

Not purely. Weigh switching costs (re-connecting sources, re-learning a tool) against the actual dollar gap you calculated using cost-per-product and marginal-cost-of-next-product. If the gap is small, it may not be worth the migration yet — but track it, because the gap tends to grow as you add products.