“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.
Why companies choose custom development
There are certainly times when custom software development makes sense, such as when:
- You’re strapped for cash, and time is a resource you can part with right now.
- Your team has an abundance of engineering and design talent and can afford to throw it all at development.
- You have a massive average deal size, and you choose to solve user engagement problems with your sales and customer success teams.
- Your tech simply doesn’t work with external providers.
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.
Why building it yourself isn’t as cheap and easy and it seems
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 .
Misconception #1: Custom development will 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 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.
How much does custom development really cost?
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 onboarding development team
1. Designers
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.
2. Product managers
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.
3. Engineers
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:
We were pretty close to building a tool to create and launch modals into AdRoll ourselves! We [were] staring down the rabbit hole of requirements and finding that the list grew intimidating really quickly. In the end, investing in Appcues was a drop in the bucket. At this point, it has probably saved us months of engineering time…It doesn’t really even take engineering work, and it doesn’t really take creative work. Appcues is very “drag and drop.” It’s super simple and creating modals take, like, 15 minutes rather than a few days.
How to calculate the real cost of build vs. buy
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.
Misconception #2: You only need to build one onboarding experience
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.
Iteration is mandatory
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.
The power of segmentation and personalization
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!
Misconception #3: Build vs. buy is purely a financial decision
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:
We have been taking some time to build better on-boarding experiences for our clients. This is critical for us in growth. We recently discovered a tool called Appcues that can help accelerate that process tremendously. I was very cautious about bringing this forward to our Dev and Design teams but we also need them to scale so anything we can do to optimize that would be great. Also, any tool that plugs into Segment give[s] us better insight and so that's really important. It's things like that where you think you might get some resistance to looking at alternative but our teams were very open minded.
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?
Misconception #4: Everyone on your team wants to collaborate on this project
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.
The choice is yours
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.
TL;DR
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.
