I built a SaaS revenue-risk workflow. Looking for 2 founders to test it on real data
Hey IH — I’m Suraj, a second-year CS student in India building a portfolio-led SaaS revenue analytics practice.
I wanted to understand how SaaS teams find revenue risk before it appears as a cancellation, so I built an end-to-end analysis workflow around a controlled B2B SaaS dataset.
The analysis covered 2,000 accounts, 2.35M feature-usage events, support tickets, and subscription records.
What I found:
• Net New MRR fell to just $852 in January 2024 after $55,990 in New MRR was offset by $71,840 in Churned MRR.
• Enterprise observed logo churn was 13.88% versus 10.58% for Basic.
• A strict usage-decay screen flagged 78 currently active accounts representing $411,801 in current MRR exposure. Twenty-two Enterprise accounts represented $315,767 of that exposure.
• SSO and Webhook adopters showed lower observed churn in the portfolio data. I’m treating that as a retention hypothesis, not proof that those features cause retention.
• I also built a time-aware calibrated churn-risk model and packaged the scoring workflow into a Streamlit app that can score one account or rank a batch CSV.
I’m now looking for two early-stage B2B SaaS teams willing to let me test the workflow on anonymized or limited data.
Pilot 1: free, in exchange for candid feedback. If the work is useful, a testimonial or anonymized write-up would be appreciated.
Pilot 2: $99 for a focused 3-day Revenue Leak Diagnostic.
The 3-day diagnostic covers:
• Data-quality and metric-definition review
• MRR movement and churn observations
• One or two focused risk cuts
• Usage-decay review if product-usage data is available
• A short prioritized action memo
• A CSV-style account review list where the data supports it
For a real company, I would first agree on what “active,” “churn,” and “at risk” mean before making any conclusions.
What I would need:
• Subscription or MRR export
• Usage data if available
• Support/CSAT data if available
• Anonymized account IDs are completely fine
Portfolio: https://suraj-saas-analytics.netlify.app/
Streamlit app: https://velocity-saas-churn-predictor.streamlit.app/
GitHub: https://github.com/SURAJRAJPUT2006/b2b-saas-revenue-analytics
Full transparency: I don’t have corporate SaaS clients yet. This project demonstrates the workflow, and I’m looking for real-world validation now.
If you’re working on churn, retention, or revenue visibility, I’d be interested in comparing notes.
Thanks for writing this up. Bookmarking it for later.
The part I’d be most interested in testing is how much the risk score changes the decision-making, rather than just how accurately it predicts churn.
I like that you’re being careful with the SSO/Webhook finding and calling it a retention hypothesis instead of a causal result. That distinction gets lost surprisingly often in churn analysis.
I’d also be curious how stable the 78-account risk list is when you change the definition of “usage decay” or move the observation window. If a relatively small change in those assumptions produces a very different list, that would be important for anyone using the output operationally.
The real-world pilot should be a good test of that: not just “can the model find risky accounts?”, but “does the resulting list help a CS/revenue team decide what to do next?”
Treating SSO and webhook adoption as a retention hypothesis instead of proof is the right line. The January net new MRR drop is mostly churned MRR offsetting new MRR, so the usage-decay screen on those 78 accounts is the part worth testing on a second dataset.
Agreed. I’m treating SSO and Webhook as hypotheses, not headline conclusions. The first real pilot will focus more on whether the usage-decay screen finds accounts worth reviewing on a second dataset, and whether it changes what CS does. That feels like a much more useful validation than trying to prove the model from one portfolio dataset.
I’d make the first pilot a decision test, not a model-accuracy test. For each flagged account, record the action the team would take, whether the signal arrived early enough, and what new data would have changed the call. That gives you a useful baseline against a simple ruleset before the workflow earns more complexity.
I agree. For the pilot, I’ll record what CS already knew, what action they would take, whether the signal arrived early enough, and what the workflow added. I’ll also compare it with the simpler usage-decay rule. If the model does not change the decision, I’d rather keep the simpler workflow.
What made you pick this stack over the alternatives?
What made you pick this stack over the alternatives?
I chose SQL/DuckDB for fast, reproducible file-based analysis, Python and scikit-learn for the modelling workflow, and Streamlit so a small team can use the output without opening notebooks. For an early-stage pilot, keeping the stack lightweight and easy to hand off mattered more than building a heavy data platform.
Strong validation angle. One practical next step: turn the 78 flagged accounts into a small, blinded review—have CS label 20–30 as “healthy / watch / at risk” before showing the model score, then compare precision by segment. That gives you a trust-building baseline and shows whether the workflow changes an actual retention action.
Great suggestion. I’m going to add a blinded review step: have CS label a sample of accounts as healthy, watch, or at risk before showing the workflow’s scores. Then I can compare the model with the team’s existing judgement and a simple usage-decay rule. I’ll also track whether the output changes an actual retention action, not just whether the score looks accurate.
The SSO/Webhook retention observation is the most interesting thing in here, and the right call is to treat it as a hypothesis to test rather than a proof. In my experience, feature adoption and retention usually correlate because both track a third variable: how seriously the customer treats the tool. SSO rollout means an IT decision, which means budget was approved, a contract was signed, and someone owns the relationship. That customer was always going to have lower churn, whether they used SSO or not.
The more actionable version of this analysis for early-stage founders is usually simpler than it looks: who are the 10% of accounts that stayed longest and used the most, and what did they have in common in the first 30 days that churned accounts didn't? That question doesn't need 2.35M events. It needs a conversation with your five best customers.
The usage-decay screen is genuinely useful for identifying accounts that are about to churn but haven't yet — that's the list worth a CSM or founder call in the next week. The 22 enterprise accounts representing $315k of exposure is a concrete action item, not just a risk metric.
For your pilot: I'd suggest working with a team that has at least 50 paying accounts and usage data, otherwise the pattern won't be statistically meaningful and you'll struggle to validate whether the model is predicting anything real versus noise. Worth stating that threshold upfront.
This is exactly right. I was over-interpreting the SSO/Webhook result, so I’m moving it back to a hypothesis rather than calling it a retention lever.
I also like the “best customers vs churned customers in the first 30 days” comparison—it’s simpler and probably more actionable for an early-stage team. For the first pilots, I’ll target companies with roughly 50+ paying accounts and usable product-usage data. The 22 Enterprise accounts / $315K figure is a current review queue, not a prediction. Thanks, this genuinely changed how I’m scoping the pilot.
What made you pick this stack over the alternatives?
This is great work — reminds me of some of the calls I've had to make building Xstream4K. What would you do differently if you started over?
I’d start with the definitions and time windows before writing the model. I’d separate the current usage-decay queue from the future-churn model, preserve missing averages instead of converting them into fake values, compare the model with a simple rules baseline, and avoid treating feature associations as causal claims. That would make the analysis simpler and easier to trust from the beginning.
Makes sense. Are you planning to charge for it, or keep it free for now?
I am running one free design-partner pilot for candid feedback. After that, the starter diagnostic is $99 for a focused 3-day scope, the full audit is $299, and the advanced scoring prototype starts at $750. I’m keeping the first pilot small because I want to validate whether the workflow changes CS actions, not just generate a report. Are you working on a SaaS product or mainly curious about the model?
The definition check before scoring seems like the right foundation. For the pilots, I’d track whether each alert leads to a concrete retention action, not just model accuracy—otherwise a good score may not change outcomes. Good luck finding the two teams; messy real data will probably be the most valuable test.
Exactly. I’m treating “did this alert lead to a real retention action?” as more important than model accuracy alone. For each pilot, I want to compare what CS already knew, what the workflow surfaced, what action was taken, and what happened afterward. I’m also comparing the model against a simple usage-decay rule so the extra complexity has to earn its place. Thanks for commenting and yes real data will be valuable test indeed.
Interesting approach. What was the hardest part to get right?
Honestly, defining the time windows without leaking future information. I had to separate historical analysis from prediction: past 90-day support and past 30-day usage become features, and churn in the next 60 days becomes the label. The other challenge was turning the output into a CS queue instead of just showing model scores.
Nice work shipping it. What has been the biggest challenge since launch?
Getting the definitions and scope right, honestly. At first I was mixing historical findings with predictive claims. I had to separate the current usage-decay review queue from the future-churn model. That made the project much more useful and much more honest.
Great breakdown. What feedback have you had from early users?
I’m still pre-client, so I don’t want to pretend I have user feedback already. The conversations here are helping me refine the workflow, and the first pilots are specifically meant to test whether the alerts change real CS actions.
Interesting. How are you measuring whether it is working?
I’m looking at it at three levels: whether the definitions and data are sound, whether the model ranks future churn better than a simple rules baseline, and whether a real pilot alert changes a CS action. Commercially, the strongest validation would be a founder choosing to repeat the workflow or pay for the next diagnostic.
Clear and practical, thanks. Did anything surprise you along the way?
The biggest surprise was how stable total MRR could hide a much weaker growth engine. In January 2024, Net New MRR was only $852 because churn absorbed almost all New and Expansion MRR. The other surprise was that a current usage-decay queue is more actionable for CS than just reporting one overall churn rate.
Good point. Did you test that with users before committing to it?
Not with corporate users yet. This is why I’m looking for the pilot teams. I’ve tested the workflow on held-out portfolio snapshots, but real-world validation needs messy exports, agreed definitions, and feedback from the people who would actually use the queue.
Really relatable. How much time do you put into this each week?
The core build took roughly three focused weeks. Since then, I’ve been refining the definitions, validation, and delivery workflow for real-world pilots. I’m now keeping a consistent weekly block for product and outreach work.
Nice work shipping it. What has been the biggest challenge since launch?
nice work
Thanks, appreciate it. I’m using the first pilot conversations to pressure-test the workflow on real operating data.
The definition check before scoring is the bit I’d keep rigid. I’d ask each pilot to name one account they already feel is at risk, then see whether the workflow surfaces it without tuning to that example; otherwise the 78-account exposure number will be interesting but hard to trust.
Yeah, I agree. For the pilots I want to keep the definitions fixed first, then ask for one or two anonymized accounts they already suspect are at risk and see whether the workflow surfaces them without tuning to those examples. I’ll also track what CS already knew, what the flag added, and whether it led to a real action. Otherwise the $411K is just an interesting dashboard number. This is exactly the kind of validation I need.
What made you pick this stack over the alternatives?
I chose DuckDB and SQL for fast, reproducible analysis on file-based data, Python and scikit-learn for the modelling workflow, and Streamlit because it lets a CS team use the output without needing to run notebooks. For a larger client setup, the same logic could move into their warehouse or CRM workflow.
For the two pilots, what outcome would validate the workflow commercially—accurately identifying risks, changing a retention decision, or founders paying to repeat the diagnostic?
I’d look at all three, in this order: did we agree on the definitions, did the alert change a real retention action, and did the founder find enough value to repeat or pay for the diagnostic? Model accuracy alone is not commercial validation.
That progression makes sense. Could be useful to dig into the pilot results a bit more by email sometime.
Absolutely, that would be useful. I’m especially trying to validate whether the output changes a real CS decision, not just whether the model ranks accounts well. Happy to send a short outline of the pilot and the questions I’m testing. Is the email on your profile the best one?
Yes, that’s the easiest one. Send it there and I’ll dig into it.
Thanks, Aryan. I don’t see an email listed on your profile—what address should I send it to?
hello@beryxa.com
The most useful part of a pilot may be agreeing on definitions and then testing whether alerts change an actual CS action, not just whether a score correlates with past churn. For each flagged account, capture what the team already knew, what action they took, and whether the account outcome changed; that helps separate signal from hindsight. I’d also compare a simple rules baseline against the model so the extra complexity has to earn its place.
That’s a very good test. For a pilot, I’d ask the team to name an account they already suspect is at risk, then run the workflow without tuning it to that example. I’d record what the team already knew, what the workflow added, and what action followed. That should help separate useful signal from hindsight.
Revenue-risk workflows are hard to validate without real messy data, so testing on actual founders' numbers is the right call. What signals is it currently trained to flag?
The current workflow uses recent active days and usage events, support-ticket volume, CSAT, resolution time, account age, plan, industry, acquisition source, and early SSO/Webhook adoption. The current dashboard queue is rule-based usage decay; the model separately estimates next-60-day churn risk.
Thanks for writing this up. Bookmarking it for later.
Appreciate it. If you ever want to compare notes on revenue visibility or retention workflows, happy to chat.
Thanks for sharing the numbers, that makes it much easier to follow.
Thanks — I tried to keep the business impact visible instead of hiding everything behind model metrics.
Happy to be one of your two testers — we're a small but real B2B services shop (launch-video production plus a docs↔ToS audit line): 26 delivered specs, live conversion funnel, quote-to-close across two price tiers. Not SaaS logos, but genuine revenue + funnel data if a second dataset shape helps.
One question worth answering before founder outreach: in your 2024 data, how many days before the cancellation did the usage-decay screen actually fire? Lead time is the whole product — a flag that beats the churn event by 30 days is a save campaign; by 3 days it's a postmortem. If the screen fires late, tightening the decay threshold will do more for the pitch than more accounts will.
The distinction between “finding a risk” and “changing what the team does about it” is important.
I’d probably treat the workflow as successful only when the output changes a real decision: contacting an account, changing an onboarding step, investigating usage, or deciding not to intervene because the signal isn't strong enough.
That also gives you a useful way to compare the model with simpler rules. If a simple usage-decay rule leads to the same useful actions as the more complex model, the simpler approach may be easier for a small SaaS team to maintain.
The first few pilots should be interesting because real-world data will probably expose workflow problems that don't appear in the controlled dataset.
Exactly. I’m planning to measure the workflow by actionability: what the team already knew, what the workflow added, what action changed, and whether the simple usage-decay rule was already enough. If the simpler rule creates the same useful decisions as the model, I’d rather use the simpler approach for a small SaaS team. The complexity has to earn its place.
The good thing here is that you're testing this on real SaaS data rather than trying to validate it through hypothetical scenarios. That's probably where you'll find out whether the workflow actually catches risks founders recognize as meaningful. I'd be interested to see what patterns come out of the first two pilots.
Same here. I’m expecting the first pilots to expose definition and workflow problems that never appear in a controlled dataset. I’ll be looking closely at whether the flags match what founders already recognise as meaningful, and I’ll share the lessons anonymously if the pilot partners are comfortable.