“Why should we buy Appcues when we can build onboarding into our product ourselves?”
We’ve heard this question a thousand times. As a third-party user onboarding solution ourselves, we’re keenly aware of the decision-making process that product teams go through as they consider purchasing a SaaS solution like Appcues to personalize their product and improve user engagement.
When evaluating a new SaaS tool, there are always options. Sometimes, those options are our direct competitors—but far more often, we see teams deciding between buying Appcues or building the same functionality internally.
There are certainly times when custom software development makes sense, such as when:
All are legitimate reasons for choosing custom development, and all have a place in the build vs. buy discussion.
But one of the things we’ve learned from talking with thousands of potential and current customers is that there a some commonly held misconceptions about the build-it-yourself approach that can get product teams in real trouble.
Oversights about the upfront costs, the cost to customize and maintain, time to ship, and your team’s motivation can all make the build decision seem much simpler and cheaper than it actually is.
If you’re you’re trying to decide whether to buy a SaaS solution (for user onboarding or otherwise) or build internally, keep reading.
We’re going to break down 4 common reasons (myths) why companies decide to build in-house instead of using Appcues—and the realities that lead many folks to ultimately reconsider and choose a third-party solution in the end .
People assume that because they’ve already invested in their team, they will be saving money if they end up building an onboarding experience themselves, rather than paying for a SaaS solution.
But it’s the opportunity cost of time spent that impacts the bottom line, as well as the upside that you could have created.
Take a look at the diagram below, in which we’ve mapped out the build process for a best-in-class user onboarding experience:
Bear in mind that this process will ultimately involve user research, design and wireframing, storyboarding, building, and regular reviews between the developers, design, and product management teams.
Let’s take a closer look at some of the components. We’ll start by defining the team using real Glassdoor national averages for salary information.
(For a more flexible financial analysis, check out the User Onboarding Cost Calculator.)
User experience is not an internal investment. User eyes = designer involvement. Conservatively, let’s say the project will involve one designer involved for roughly a week, spread out over the 2-month project.
You’ll need at least one PM to keep the project organized and moving along. This person (or people) will spend just over a week (over the course of 2 months) overseeing the project.
Let’s assume you need 2 front-end developers and a back-end developer (remember, this is a conservative estimate.) Scope will include building the components of the user onboarding tour or walkthrough, back-end functionality, incorporating design work, etc. There will be regular reviews with design and product. Also, things will break in testing. The devs will fix those things.
You wouldn’t be alone in thinking that it will take a couple of days for an engineer to build an onboarding experience from scratch, but in reality, it takes a multidisciplinary product team every bit of 2 months to research, build, test, and deploy a good user onboarding experience.
But don’t take our word for it. The growth team at Adroll explains:
Now, let’s take another look at that build map:
Based on the national averages outlined above, you’re looking at an upfront cost of at least $45,018 in terms of your team’s time. Again, that’s a very conservative number based on a light team and no major hiccups.
A lot of teams stop here. But there’s more to building and maintaining a user onboarding experience: If you want to update your in-product messaging, for example, you’ll need at least a few hours from your newly formed onboarding team to do so. Let’s say you need to change your messaging 4 times a year (but really, it should be reviewed much more often and continuously improved upon) and it takes one sprint—about a week—every time.
That amounts to a month of engineering time (with time from designers and PMs sprinkled in), or roughly $25,766 per year in maintenance cost. That’s a year one total cost of $70,784 for a single custom developed user onboarding experience.
The reality is that in most cases, a user onboarding solution like Appcues would have cost you a fraction of what you’d spend on custom development. Not only that, but you’d have pushed your experience out the door much faster, driving ROI and new experiments.
In the meantime, you could have been making improvements to your core product, shipping new features, and improving your user experience—not coding for modals and tooltips and rebuilding the same targeting infrastructures over and over.
Want a more accurate estimate of how much building it yourself will cost? You can use our User Onboarding Cost Calculator to do the math.
When most people weigh a build vs. buy decision, they fantasize about a set-it-and-forget-it build scenario:“How hard can it be to build one onboarding flow?”
Well, what happens when you want to iterate on it?
We've seen so many teams spin up onboarding, only to then change their product dashboard, for example, creating a need to redo the product tour or walkthrough completely. In worst-case scenarios, onboarding gets dropped from scope due to added complexity.
Or, let’s say you have a basic SaaS product with 3 different types of users—marketers, product managers, and engineers.
When you do the math, you find there are dozens of different “states” a user could be in the next time they log into your product. Would you want a marketer with a soon-to-expire trial who has completed 3 of your 5 key actions to see the same user experience as an engineer who has been idle since signup and is returning on day 3? Of course not.
It may sound simple to whip up an initial onboarding experience. But the true value of user onboarding is created in iterations, and testing effectiveness can illuminate paths through your product that you had never considered. Iterations ultimately drive activation and retention even further, creating ever-increasing ROI for your onboarding sequence.
Then there’s the small matter of segmenting users and delivering personalized experiences throughout their journey. As modern users, we expect products to be hyper-relevant to us—to know where we've been and where we still need to go.
User onboarding doesn’t just happen in the first 5 minutes. User onboarding is about helping new users complete tasks and take the necessary steps to reach their first aha moment and achieve value with your product. That process can—and often should—happen gradually, at relevant moments in the user journey.
Lifecycle nudges like the one above can be unbelievably effective at turning new users into power users. They work because they target very specific subsets of users based on behavior.
Here’s the targeting for the flow above:
These are the types of experiences that often get overlooked in a a build vs. buy decision—and they’re the ones that will inevitably get cut from scope when you decide to build it yourself.
Because by the time you’ve realized that you need to add another targeted in-product message, your engineering team will have moved onto something else. They’ll be back to improving the core product—which exactly what they should be doing!
Even the simplest user prompt, when built in-house, can take weeks to ship live in your product. During the interim, you could potentially have hundreds of new users sign up and churn because they don’t see any immediate value from your product.
In fact, a recent Mixpanel study of 572 products and 1.3 billion unique users showed that roughly 60% of users are lost within a week of their first product experience. If you’re losing users to onboarding development time, that's a lot of marketing and sales spend down the drain.
And it’s not just the dedicated engineering time that makes custom development so costly— it’s also the time it takes your product team to decide on and implement a strategy. The input that marketing, sales, and customer success teams provide, the back-and-forth to change copy or the color of a button, the analysis that goes into evaluating how engaging an onboarding flow is—it all adds up.
And it doesn’t matter if you’re an an early-stage startup with a tight budget or a multinational corporation with a suite of products: Time, not money, is your most valuable resource.
Even IBM—which has dev resources that smaller SaaS companies can only dream of—is looking for ways to work smarter, not harder. Nancy Hensley, former Chief Digital Officer for IBM Analytics explains in an AMA with GrowthHackers:
In-house development puts a strain on your team, and it gives ample time for users to become disengaged with your product. If you don’t have to go through that, why would you?
Sure, it’s possible. But it’s more likely that your engineers are busy enough building out your core product. In our experience, writing the code for modals, tooltips, and hotspots ends up feeling a lot like unnecessary work when there are tools out there that let you drag and drop those same UI elements onto the page.
And custom development means that every time you build a new feature or make a change to your UI, your engineering team will also need to include maintaining your bespoke onboarding flow in the scope of their work.
PMs and product marketers—who typically own the metrics around user onboarding, engagement, retention, and conversion within a product—get reduced to an advisory role in this whole process. They have to wait 2 months to go from vision to reality, and weeks more after that any time a change is needed.
Those same product managers and product marketers could instead be building, targeting, deploying, testing, and iterating on product experiences in minutes.
Once we saw that we were getting amazing completion rates of 70%—or more—just for the onboarding flow, we started creating flows for all of the major features.
Look, we’re a little biased. Appcues is a SaaS solution for user onboarding, after all. But we’re also engineers and designers and CSMs and marketers and product managers—and we know how much time, effort, and money it takes to build and iterate on a product. That’s why we created Appcues: to make it easy for other companies to create engaging experiences that their end users will love—without eating up dev time and resources.
And even if you do have the resources to spare, user onboarding just shouldn’t be in the hands of your engineers. It should be owned by product, marketing, customer success—the teams who converse with users on a regular basis. Not to mention the fact that an immersive onboarding experience requires a feedback loop—you should be able to analyze, iterate, and deploy changes to your onboarding flows quickly when need be.
Think about it: A single onboarding experience can cost you $45,018 a year, plus another $25,766 for maintenance. That’s for just one onboarding experience for all users. Other experiences in a user’s lifecycle—like feature adoption, redesign communication, product updates, etc.—require targeted in-product messaging, too.
There are some things that you just have to build in-house to get right; but for most companies, user onboarding just isn’t one of them.
.svg){kind=icon}
