The Real Cost of Building Onboarding Yourself

“Why buy Appcues when we can build onboarding into our product ourselves?”

Over the last 5 years, the Appcues team has spoken to many hundreds of product teams as they’ve considered Appcues as a solution to personalize their product and improve user engagement.

In evaluating a new tool, there are always options. Sometimes, those options are our direct competitors—but far more often—teams are deciding whether they should buy Appcues or build the same functionality internally.

There are certainly times when an internal build makes sense.

• Maybe you’re strapped for cash, and time is a resource you can part with for now.
• Maybe your team has an abundance of engineering and design talent and can afford to hand out a few less engaging projects in the name of keeping schedules full.
• Maybe you have a massive average deal value, and you choose to solve user engagement problems with Sales and Customer Success teams, or your tech doesn’t work with external providers.

All are legitimate, and all have a place in the build vs. buy discussion.

I’ve come to learn that when teams consider building it themselves, however, there are a few commonly held misconceptions that can get them in trouble. Oversights about the upfront costs, the cost to customize and maintain, time to ship, and your team’s motivation can make the build decision seem much simpler and cheaper than it actually is.

Here are the top reasons companies decide to build in-house instead of using Appcues.

Reason #1: It’ll be cheaper

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 using a SaaS solution like Appcues. But it’s the opportunity cost of that time that impacts the bottom line, as well as the upside that you could have created. 

If you take a look at the diagram above, you’ll see we’ve fully mapped out a best-in-class onboarding build. (For more info on what constitutes “best in class,” check out our User Onboarding Academy!)

This process will include user research, design and wireframing, storyboarding, building, and regular reviews between the developers, design, and product management teams.

We’ll start by defining the team using real Glassdoor national averages for salary information. For a more flexible financial analysis, check out our onboarding cost calculator.

1. Product managers: We’ll need at least one 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.

2. Designers: User experience is not an internal investment. User eyes = designer involvement. Conservatively, we’ll say the project will involve 1 designer involved for roughly one week, spread out over the 2-month project.

3. Engineers: We’ll assume two front-end developers and one back-end developer. Remember, this is a conservative estimate. Scope will include building the components of the tour and back end functionality to ensure it shows at the correct times, incorporating design work, and attaching the tours to the right parts of the front-end. 

All of this will be compounded by regular reviews with design and product. Also, things will break in testing. The devs will fix those things.

You might think it takes 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 onboarding experience.

“Appcues enables our growth team to test multiple hypotheses within a short period of time… the whole process took 2-3 weeks, but is significantly faster than experimenting by using development.” - Canva, customer since 2016

So, you’re looking at an upfront cost of at least $33,800 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—often with mediocre experiences—stop here. But that’s not all. If you want to update your product experience, you’ll need at least a few hours from your newly formed onboarding team. Let’s say you need to change it four times a year (but really, it should be reviewed much more oftenand continuously improved) and it takes one sprint—about a week—every time.

That amounts to a month of engineering time (with time from designers and PM’s sprinkled in) or roughly $19,000 per year in maintenance cost.

An onboarding tool would have cost you a fraction of that and would have started working instantly, 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 building modals and tooltips and rebuilding the same targeting infrastructures over and over. 

Your engineers will thank you.

Reason #2: You’ll only need one onboarding experience

When most people weigh a build versus buy decision, they fantasize about a set-it-and-forget-it build scenario. They probably have one initial use case in mind. 

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 and then changing their product dashboard, creating the need to re-do the product tour workflow completely. In worst case scenarios, onboarding gets dropped from scope due to added complexity.

Let’s say you have a basic SaaS product with three different types of users signing up—marketers, product managers, and engineers. Using the EMBED framework we can determine the optimum onboarding sequences.

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. You don’t want to show the same experience to a Marketer who has completed 3 of your key actions and has an expired trial as to an Engineer who has done nothing and is coming back on day 3, do you?

It may sound simple to whip up an initial onboarding experience. The value is created in iterations, however, and testing effectiveness can illuminate product paths you had never considered. This drives activation and retention even further, creating ever-increasing ROI for your onboarding sequence.

Most of the Appcues flows end users see—30 million plus so far—aren’t a user onboarding flow (product tours, welcome sequences) as you’re probably thinking of it. As users, we expect products to be hyper-relevant to us—know where we've been and where we still need to go. They look much more like this:

A lifecycle nudge built and published in five minutes, without code, using Appcues

Onboarding does not end after a user’s first session. Lifecycle nudges like the one above can be unbelievably effective at turning new users into power users. They target very specific subsets of users based on behavior.

Here’s the targeting for the above flow:

?Getting smart with targeting is simple with Appcues

These are the types of experiences that might not be drawn up in a build vs. buy decision. They’re the ones that will inevitably get cut from scope first when you decide to build it yourself.

By the time you want to add another one, your engineering team will have moved onto something else. Back to improving the core product—exactly what you want them to be doing!

Reason #3: This is purely a financial decision

Even if you’re an early stage startup with a tight budget, money is not your most valuable resource. Time is.

Even the simplest user prompt, when built in-house, can take weeks to ship live in your product. In those weeks, hundreds of people may have already signed up for your product and churned because they didn’t see immediate value.

In a recent Mixpanel study across 2 billion users of products in various industries, the research team shows that on average 50% of users are lost in the first week of the product experience. If you’re losing users to onboarding development time, that's a lot of marketing spend down the drain.

It’s not just the dedicated engineering time. It’s also the time it takes your product team to decide on and implement a strategy. The input that marketing or sales or customer success provides, the back-and-forth to change copy or the color of a button, the analysis that goes into evaluating how engaging an onboarding flow was—it all adds up.

It puts a strain on your team, and it gives ample time for users to become disengaged with your product. 

Reason #4: Everyone on your team wants to collaborate on this

It’s possible, but most likely your engineers are busy enough building out your core product. In our experience, writing the code for modals, tooltips, and hotspots is not the most fulfilling work when tools exist that can drag and drop them onto the page. Especially when there are features to build or engaging engineering challenges to solve.

And now 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 own the metrics around user onboarding, engagement, retention and conversion in the product, get reduced to an advisory role in this whole process. They have to wait two months to get from vision to reality, and weeks more any time a change is needed.

Those same product managers and product marketers could 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.” Yotpo - Customer since 2017

Why wait?