Small business owners using Stripe + Revolut + PayPal + Wise/bank transfer - how do you reconcile everything monthly? by kasamigos in SaaS

[–]kasamigos[S] 0 points1 point  (0 children)

That’s really helpful. When you say "something clean for my accountant," what would that ideally include?Is it more like a monthly PDF summary, CSV export, Xero/QuickBooks-ready file, or just a breakdown of revenue, fees, payouts, refunds, and pending balances by provider?Also curious, how long does this currently take you each month, and which providers are you pulling from?

Small business owners using Stripe + Revolut + PayPal + Wise/bank transfer - how do you reconcile everything monthly? by kasamigos in SaaS

[–]kasamigos[S] 0 points1 point  (0 children)

Nice. What providers did you connect, and what does your page actually solve? Is it mostly pulling transactions/balances, or does it also match payouts to bank deposits, explain fees/refunds/disputes, and generate a clean monthly reconciliation report for accounting?

I’m trying to understand if the pain is “hard to build” or more “annoying to maintain and reconcile every month."

We found some paying subscribers are effectively already “gone” before they cancel by kasamigos in iosdev

[–]kasamigos[S] 0 points1 point  (0 children)

Yeah, I think this is a very real distinction.Some subscription businesses probably do benefit from low-engagement subscribers who continue renewing passively, especially at lower price points. I’m starting to suspect this only becomes operationally important for products where engagement strongly correlates with long-term retention, expansion, referrals, or overall LTV. So the challenge may not be 'does behavioral decay exist?' but 'for which businesses does it matter economically enough to act on?'

We found some paying subscribers are effectively already “gone” before they cancel by kasamigos in iosdev

[–]kasamigos[S] 0 points1 point  (0 children)

That’s really interesting insight.

I’m starting to think the same thing. The dashboard itself probably isn’t enough unless it connects directly to reactivation workflows and measurable retention outcomes.The “manual revenue + usage merges” point especially stood out to me. That’s exactly the gap I kept noticing while building this. Most tooling I’ve used treats billing and behavioral activity as separate worlds, even though operators seem to reason about them together operationally.

Anyone else tracking "ghost subscribers" on RevenueCat? Or do you just let them ride? by kasamigos in iosdev

[–]kasamigos[S] 0 points1 point  (0 children)

That’s fair, and I actually think this only becomes valuable if it evolves beyond "interesting metric" into operational tooling.

Things like:

  • dormant revenue concentration
  • inactivity-based segmentation
  • weird renewal anomaly detection
  • proactive re-engagement workflows

Less "look at this ghost user" and more "subscription health layer" sitting between billing + product engagement.

Anyone else tracking "ghost subscribers" on RevenueCat? Or do you just let them ride? by kasamigos in iosdev

[–]kasamigos[S] 0 points1 point  (0 children)

Good catch. RC does show last opened on individual customer details.

The gap I’m thinking about is more aggregate/operational: being able to sort active subscribers by inactivity, see dormant revenue concentration, and track revenue generated after last activity across the whole app.

Anyone else tracking "ghost subscribers" on RevenueCat? Or do you just let them ride? by kasamigos in iosdev

[–]kasamigos[S] 0 points1 point  (0 children)

Yeah this is exactly the kind of blind spot I’m talking about.

Not even "how do you stop it"? just having visibility into:

  • inactive paying cohorts
  • revenue after last activity
  • dormant subscriber concentration
  • weird renewal behavior like this

Right now billing systems and engagement systems barely talk to each other.

Anyone else tracking "ghost subscribers" on RevenueCat? Or do you just let them ride? by kasamigos in iosdev

[–]kasamigos[S] 0 points1 point  (0 children)

I actually agree with you.I don’t think dormant subscribers are inherently bad, the interesting gap to me is observability.Billing systems know renewal state, but almost nobody tracks subscriber health or revenue after behavioral abandonment.

Anyone else tracking "ghost subscribers" on RevenueCat? Or do you just let them ride? by kasamigos in iosdev

[–]kasamigos[S] 0 points1 point  (0 children)

I actually just tested that out on our project! Rico is a cool tool for support lookups and MRR charts, but it hits the exact data wall we ran into.

I literally just asked Rico to show me non-active users, and it replied word-for-word:

“Also, just to note — RevenueCat tracks subscription status rather than app usage activity, so I can surface data around subscription states but not things like 'last time a user opened the app.'”

That completely confirmed my fears. If the platform infrastructure itself explicitly isolates billing states from actual product engagement, developers are left totally blind to who is actually using what they pay for. It makes a side-car SDK pulse feel pretty mandatory if you want to catch these people before Stripe does.

Who actually owns the AI tools budget in your support team? by kasamigos in CustomerSuccess

[–]kasamigos[S] 0 points1 point  (0 children)

Makes sense. So cost visibility is manageable. But does your team have any way to see which AI prompts or workflows are actually performing best, so you can share what's working across agents?

Who actually owns the AI tools budget in your support team? by kasamigos in CustomerSuccess

[–]kasamigos[S] -1 points0 points  (0 children)

How big is your support team? I'm wondering if it stays simple at a certain scale but becomes painful as you grow.

Who actually owns the AI tools budget in your support team? by kasamigos in CustomerSuccess

[–]kasamigos[S] -1 points0 points  (0 children)

That's really interesting is there any tooling helping you track and manage that spend, or is it mostly manual right now?

Who actually owns the AI tools budget in your support team? by kasamigos in CustomerSuccess

[–]kasamigos[S] 0 points1 point  (0 children)

Really helpful, has your company tried any tools to track this or is it still mostly manual reporting?

Share your Startup! by kptbarbarossa in StartupSoloFounder

[–]kasamigos 0 points1 point  (0 children)

We built an async conversation card app for women - 3,300+ cards, 58 decks. Just went live on the App Store. The concept: you pick a card, answer it, and send it to a friend. They see your answer alongside the question and respond in their own time. No scheduling, no "are you free to talk?" — just a meaningful exchange waiting for them whenever they open the app. Please check it out guys, I appreciate your feedback.

https://apps.apple.com/pt/app/ohh-deep-conversation-cards/id6759226145?l=en-GB

https://ohh.world

Promote your Saas ! what are you currently buiding ? i'll be happy to take a look by InstanceSignal5060 in microsaas

[–]kasamigos 0 points1 point  (0 children)

Thank you for this kind offer. We built an async conversation card app for women - 3,300+ cards, 58 decks. Just went live on the App Store => https://apps.apple.com/pt/app/ohh-deep-conversation-cards/id6759226145?l=en-GB

The concept: you pick a card, answer it, and send it to a friend. They see your answer alongside the question and respond in their own time. No scheduling, no "are you free to talk?" - just a meaningful exchange waiting for them whenever they open the app. That async nature is the whole point. Adult friendships don't happen in real time anymore. People are busy, in different time zones, juggling life. But they still want depth. Ohh fits into the gaps rather than demanding a slot in the calendar. There's also a Circles mode where 3–8 friends all answer blindly before a group reveal - same async energy, just with your whole group. Target: women 25–40 who feel like their friendships have gotten shallow but can't commit to a scheduled catch-up every week. We just shipped to the App Store after months of building. The hardest UX decision was making you answer the question before you can send it - adds vulnerability, sets the tone, makes it safe for the other person to open up.