.png)
When in-app messaging expands, more ideas start to emerge—often beyond the original use case. And sometimes, those ideas spark a familiar thought:
We could build that in Appcues…
Should we? Or should we build that natively?
It’s not a daily debate. Most of the time, the answer is clear. But every now and then, something lands in the gray area—and that’s when the conversation starts.
We had one of those moments recently and realized it was a good opportunity to get the answer down on paper. So we created a simple framework to help us gut-check the decision—and turned it into a template for others to use, too.
We’re not drawing hard lines, but we are asking better questions. Here are a few to guide our thinking:
Is it flexible or fixed?
If it’s going to change often, target specific users, or live a short life—Appcues.
If it’s a core part of the product experience—hard-code it.
Does it need to be personalized?
If the message or experience needs to change based on the user—who they are, what they’ve done, or what they haven’t—Appcues makes that easy. Hard-coding personalized logic is usually time-consuming and hard to maintain.
Will we want to test or iterate?
We use Appcues when we’re still in “let’s see what works” mode. It’s way easier to test different messages, placements, and triggers—then build what sticks.
Who owns the outcome?
If the outcome is owned by a go-to-market team (like driving activation or adoption), we own the experience in Appcues. If product owns the outcome and it’s tied to core functionality or backend logic, it might belong in the codebase.
Does it need to be different for different audiences?
If there’s no one-size-fits-all version—or different users need different messaging—Appcues makes that a lot easier.
Once an experience is published, it’s easy to let it sit—especially things like Pins, Tooltips, or adoption nudges. These patterns tend to live longer than others and are more likely to break if the UI changes, so we’re working on building a habit of checking back in.
The goal is to pause and ask:
Should this move into the product?
If it’s still helping users and doing its job, great.
If it’s become central to the product experience (and doesn’t require segmentation or targeting), it might be time to make it native.
If it’s no longer needed, we’ll sunset it and move on.
Creating this feedback loop will help us stay nimble—and ensure our tools are working as effectively as possible.
Now that we’ve aligned and templatized this, the next step is building it into our planning process—adding it to Appcues guidelines, kickoff docs, or anywhere decisions get made early.
We’re also started to tag experiences in Appcues as “experimental” or “test,” so we know what to revisit over time.
