Most SaaS products assume you'll use them every day.
Daily active users. Weekly retention. Monthly engagement. The entire playbook is built around habitual use.
But some problems don't work like that.
Some problems show up twice a year. Or once every six months. Or only when something breaks.
These are episodic SaaS use cases. And if you design for them like you'd design for Slack, you're going to lose.
What Makes Episodic Use Cases Different
An episodic SaaS use case is any workflow where users need your tool infrequently but critically.
Think about it. You don't need to screen CVs every day. You need it when you're hiring. That might be once a quarter. Or twice a year. Or never, if you're fully staffed.
You don't need to write a SEN appeal letter every week. UK parents need it once, maybe twice, when they're fighting their local authority for educational support.
You don't search for company directors daily. You do it when you're prospecting, when you're chasing a lead, when you're doing due diligence.
The pattern is clear. High stakes, low frequency.
Traditional SaaS metrics fall apart here. DAU means nothing. Retention looks terrible if you measure it weekly. Churn gets murky because someone who hasn't logged in for three months might not have churned. They might just not need you yet.
Why Most SaaS Products Get This Wrong
Most SaaS founders optimize for engagement because that's what VCs want to see. Growth curves that go up and to the right. Users coming back every day.
So they add notifications. Gamification. Daily emails. Artificial reasons to log in.
For episodic SaaS use cases, this is poison.
Your user doesn't want a streak. They want the tool to be there when they need it and invisible when they don't.
They don't want onboarding flows that assume they'll spend an hour setting up integrations. They want to solve the problem in front of them right now and leave.
They don't want to relearn your interface every time they come back after four months. They want it to be obvious.
Here's the trap. If you design for daily use and your product is episodic by nature, you end up with a bloated, confusing tool that people abandon the first time they try it.
How We Design for Episodic Use at Marvanova
At Marvanova, we build tools that people use occasionally but need urgently.
Lucuma is a good example. Recruiters don't screen CVs every day. They screen them when a role opens. That might be monthly. It might be quarterly. It might be once and then nothing for six months.
So we designed Lucuma to work like this. You sign up. You paste the job description. You upload the CVs. You get scored results in seconds. You're done.
No onboarding wizard. No dashboard you need to understand. No feature tour that assumes you'll be back tomorrow.
When you come back in three months, it works the same way. No relearning. No updates that broke your workflow.
SEN Letters UK is even more extreme. UK parents use it once or twice in their child's school life. That's it.
We can't rely on habit. We can't gamify it. We just need to solve the problem completely, the first time they use it.
Same with dunlin Scout. Prospecting isn't a daily task for most people. It's something you do in bursts. A few hours one week. Nothing for a month. Then another session.
The tool needs to be fast to pick up and fast to put down.
The Real Metrics That Matter for Episodic SaaS Use Cases
If DAU doesn't work, what does?
We track time to value. How long from signup to first useful output? For episodic SaaS use cases, this needs to be minutes, not days.
We track return rate in context. Not "did they come back this week?" but "did they come back the next time they had this problem?"
We track completion rate. Did they finish the job they came to do? If someone uploads CVs to Lucuma and never downloads the results, that's a failure. If they do it once, get the results, and don't come back for four months, that might be perfect.
We track support volume. Episodic users can't afford to get stuck. If they email us confused, we've failed at clarity.
And yes, we track retention. But we measure it in months, not weeks. Someone on an annual plan for dunlin Radar who uses it three times a year and renews? That's success.
Designing for Clarity, Not Engagement
Episodic SaaS use cases force you to prioritize differently.
You can't hide features behind progressive disclosure because your user won't be around long enough to discover them. Everything they need has to be obvious on the first screen.
You can't rely on tooltips or help docs. They won't read them. The UI has to explain itself.
You can't assume they remember how it works from last time. Every session is effectively their first session.
This is hard. It means you can't add features just because they're useful to 10 percent of users. If it clutters the main flow, it doesn't go in.
It means you can't have five pricing tiers with feature matrices. You need simple, clear offers. Lucuma has three plans. That's it.
It means your onboarding is your product. There's no separation. The first thing they see has to be the thing they came to do.
The Business Case for Episodic SaaS
Here's the counterintuitive part. Episodic SaaS use cases can have better economics than daily-use tools.
Why? Because you're not competing on habit. You're competing on being the best solution when the problem shows up.
Users don't compare you to their daily workflow. They compare you to the alternative that day. Usually, that alternative is doing it manually. Or not doing it at all.
Pricing is easier too. People will pay for a tool they use twice a year if it saves them eight hours of work each time. The value is obvious.
Churn is lower if you get it right. They're not canceling because they stopped using it. They're canceling because it didn't work when they needed it.
And word of mouth is strong. Episodic problems are painful. If you solve one cleanly, people remember. They tell others who have the same problem.
Building This Way at Marvanova
We don't build episodic SaaS use cases by accident. We look for them.
We look for workflows that happen infrequently but matter a lot. Screening 200 CVs. Writing a legal appeal. Searching for decision-makers.
We look for problems where the existing solution is "spend a day doing it manually" or "pay a consultant £2000."
We look for moments where someone would pay £99 to make the problem go away in 10 minutes.
Then we build the simplest possible version. No dashboards. No analytics. No integrations unless they're critical.
We test it by asking: could someone use this successfully if they only touched it once and never came back?
If the answer is no, we simplify.
Your Product Might Be Episodic Without You Knowing It
Look at your usage data. How many of your users log in once a month or less?
If it's more than 30 percent, you might have an episodic product that you're treating like a daily-use tool.
Ask yourself: are you building features to drive engagement, or are you building features to solve the problem faster?
Are you sending emails to get people to log in, or are you sending emails when they actually need you?
Are you measuring success by how often people use your tool, or by how well it worked when they did?
Episodic SaaS use cases don't need to look like traditional SaaS. They need to work when it matters.
Final Thought
The best episodic tools are invisible most of the time and perfect when you need them.
That's harder to build than a habit-forming daily product. But it's also more honest.
You're not tricking people into using your tool. You're just there when the problem shows up.
If you're building something people need urgently but infrequently, stop optimizing for engagement. Start optimizing for clarity and speed.
Your users will thank you by paying, using it when they need it, and telling others.
Want to talk about building tools for episodic use? Email us at hello@marvanova.com.