A lot of SaaS products rely on pushing users toward upgrades in ways that feel a bit forced. You hit a limit that doesn’t quite match how you’re using the product, or a feature is locked behind a higher plan even though it’s not something you use often. In those cases, upgrading feels like a decision you have to justify, and most people just avoid it. Notorious examples abound, like Unity’s (now canceled) runtime fee fiasco.
What works better is when the pressure to upgrade comes from something the user is already doing and wants to keep doing. Not because you told them to, but because they’ve run into a real constraint that’s getting in their way.
That’s what I mean by natural upgrade pressure. Not something forced by the app, but a natural extension of what the user’s already doing.
Workflows Already Do This
Workflows tend to create this almost by default, because they’re tied to repeated behavior. People don’t build workflows out of curiosity or for fun. (Unless you’re like me and founded a workflow company!)
They build them because they’re doing the same thing over and over and over and want to stop doing it manually every single time. The first workflows usually small, but once it works, it changes how they think about the product.
After that, it’s hard not to see other places where the same idea applies. More actions get connected, more steps get automated, and the product starts handling a larger part of what they do. It doesn’t feel like adding new unnecessary features, it feels like extending something that’s already useful.
As that grows, limits start to show up in a way that actually makes sense. Maybe they can only create a certain number of workflows, or they hit a cap on how often they run. Maybe they want to add slightly more complex logic and realize it’s not available on their current plan.
The key is that these limits don’t feel arbitrary. They show up right when the user is trying to do something they already understand and value. The upgrade isn’t about unlocking a random feature, it’s about continuing something that’s already working for them.
That’s a very different dynamic from trying to convince someone to upgrade based on a list of features they may or may not use.
Why External Automation Tools Break This
This is also why a lot of products lose that advantage when they rely on external automation tools. If users are building their workflows somewhere else, that’s where the upgrade pressure shifts. They’ll pay more to the tool that’s actually running their processes, not to your product.
Over time, that weakens your ability to grow revenue through usage, because the most important part of the workflow isn’t yours anymore.
Keeping it inside your product keeps that pressure where it belongs. With Embed Workflow, workflows are built directly into your app, using the same actions and data your users already rely on. As they expand what they’ve automated, the limits and upgrade points stay connected to your product.
In practice, the best upgrades don’t feel like upgrades. They feel like removing a restriction that’s blocking something useful. Workflows create that situation naturally, which is why they tend to convert better than most other features.
David Amrani is the founder and CEO of Embed Workflow. After building three custom workflow automation systems from scratch, with each taking over 8 months at companies like Brivity, a healthcare startup, and Resorcity, he saw the gap between bloated iPaaS tools and what SaaS companies actually need.
In 2022, he launched Embed Workflow: a white-labeled, embeddable, high-performance solution designed for startups. With 10+ years in engineering leadership and deep expertise in automation architecture, he’s building the tool he wished he’d had.