Product and engineering teams in every SaaS organization have undoubtedly found themselves having to make the critical decision of whether to build ancillary product features in house, or to buy ‘off the shelf’ solutions. While individual contributors and developers often prefer to build, teams that aim to make the best resource allocation decision possible need a framework for evaluating their options.
In this in depth guide, we share insights from our roundtable discussion where I sat down with leaders from Userpilot, Cumul.io, and Cord to discuss the considerations that must be included in any build vs. buy decision. Given our backgrounds, the discussion revolved around customer-facing, ancillary features vs. internal/backend tools, but many of the insights shared can still be applied to decisions involving the latter.
Want to watch the full roundtable discussion? View it here!
Table of Contents
Before we even get into the specifics of evaluating whether you should build or buy solutions for a feature, the first question you need to answer is if buying should even be an option.
What should you always build in-house?
“You should never buy your core capability. You know something is wrong when you buy your differentiator.” - Nimrod.
Positioning and differentiators are what enable companies to outperform competitors in the crowded SaaS ecosystem. If your ‘unique’ value proposition can be bought off the shelf, this poses 3 significant risks.
- It is an indication that your core product has been commoditized.
- Your core features’ iteration potential will be limited to the solutions provider capabilities
- If the solutions provider decided to pivot or goes out of business, you no longer have a product
It’s important that you retain full control over what makes you unique in the market, as it will allow you to continue to be ahead of the competition even if they decide to copy your current feature set.
On the complete opposite end of the spectrum, you also shouldn’t buy solutions for features that are inconsequential for the majority of your user base.
“If it’s inconsequential, the quality and longevity doesn’t matter - you might just need a quick hack,” shares Nimrod.
A thorough build vs. buy evaluation comes into play in the sweet spot in between the two previous examples. This is where the feature you need to ship is close enough to your core product such that it still adds significant value to your users, requires consistent iteration, yet is not inherently unique to your business.
Examples of these types of features are guided app experiences, native integrations, dashboards, multiplayer functionality (like Figma), or even a CSV importer.
Why is there a general aversion to buying?
While many engineers have a negative perception towards buying, what’s overlooked is that most of these ‘off the shelf’ solutions providers were started and built by engineers themselves. In fact, all the panelists’ companies were founded by engineers, and you can learn about their journeys here.
However, we dug into a few common themes and reasons that engineers prefer to build in most cases.
Top-down trauma
There's a lot of uneasiness and baggage, and rightfully so from previous experiences, where teams experienced extremely top-down ‘buy’ decisions.
At many organizations, especially in later stages/enterprise, the decision makers are often very rarely the team tasked with implementing the solution. As a result, they are forced to ‘make it work’, even if the purchased solution wasn’t necessarily designed for the use case.
Builder Mentality
I think we can all agree that engineers became engineers to build - the ability to create apps and products that people love to use out of nothing but code can be a thrilling process. Therefore selling them a solution may come across as companies trying to take away their power and ownership, which will naturally trigger a negative reaction. However, we have also observed that once engineers shift into managerial roles, they begin to approach these decisions from a slightly different perspective. Their priority becomes making the best allocation decision for their limited engineering resources, which often places building core, differentiating features at odds with building supplemental, ancillary features.
Feature Limitations
“If there’s a will there’s a way.” Building in-house allows engineers to have 100% control over every aspect and detail of the feature. However, buying a solution inherently forces them to give away some control and flexibility, which can potentially lead to limitations around extremely specific and unique edge cases that the solutions provider cannot accommodate.
This is a very valid concern that needs to be top of mind during the evaluation process, which leads us to the next topic.
The importance of discovery and roadmap
When it comes to making a purchasing decision, it’s crucial that you understand your ‘must-haves’ and ‘nice to haves’ in terms of feature set.
Without a robust set of requirements for both the short and long term needs, it becomes extremely hard to:
1. Properly evaluate the costs of building and maintaining the feature in-house
2. Determine if the solution will be able to fit your use cases both immediately and through future iterations
While it may seem intuitive as part of the product development process, oftentimes teams don’t apply the same level of scrutiny on planning out (nor have the expertise with) ancillary features, when compared to their core product.
This may lead to many unexpected challenges and limitations down the line, which is why before you even begin to evaluate your options, you need to make sure to go through a proper discovery and requirements gathering process for the feature.
Now that we have that covered, it’s time to dive into the 7 considerations you need to think through when evaluating whether you should build the feature in-house or partner with a vendor.
Considerations
1. Features & Extensibility
Since you’ve done the prep work of outlining your non-negotiable requirements and ‘nice to haves’, it’s time to map out which requirements are covered by the solution you’re evaluating, if any components are (nearly) impossible to build yourself, and the time it would take to build each of those components.
Out of the box functionality
The more closely aligned the solution’s out-of-the-box feature set is to your use case(s), the more time your team will generally save.
For example, when it comes to integrations, amongst managed authentication and a native end-user UI, Paragon provides the most common workflow actions out-of-the-box without users having to write any code, so even non-technical product managers can build/modify workflows without engineering being a bottleneck.
The more coverage on workflow actions our platform has, the more internal resources our customers will save, as they wouldn't need to go through the 3rd party app’s documentation and can leverage our UI to build out full integrations.
If only a small portion of the feature requirements are provided by the solution however, then you’d have to evaluate the price of the solution solely against the resources it would’ve taken internally to build those specific features.
Extensibility
It’s common for out-of-the-box solutions to come with certain constraints that may prevent you from implementing certain rare and unique use cases exactly as you’d designed it.
What’s important here is to see if the platform offers any extensibility when it comes to accommodating your unique needs.
Identify if there is a ‘back door’ to let your team build the specific additional features within the platform, without having to Frankenstein something together - which is where you build half of the feature on the platform the other half completely from scratch.
Back to the integration example, when it comes to building an integration with Salesforce, which has a behemoth of an API, it’s unlikely that Paragon will provide built-in workflow actions for every single endpoint and use case. This is why it has been important for our customers to have the option to easily call the integration’s API directly within our platform, which prevents them from ever being limited to our scope.
Similarly, customers often come to us for their most common integration requests such as Salesforce, Slack, Google Calendar etc., but also want a platform that can accommodate their long tail of niche integrations that we don’t have connectors for. Had we not provided our users our Custom Integration Builder, which allows them to offload authentication and user our workflow builder and end-user UI on any integration, this would have been a gap that would have tilted the scales towards building.
Impossible to build
While most features can technically be built in-house, certain functionalities require scale and distribution to be economically feasible. Nimrod brought up a great example with Twilio.
“What began the success of Twilio had to do with negotiating big contracts on huge volumes of SMS units from all kinds of carriers, and that's something that no single company could do because they wouldn't know their scale andthey wouldn't have the same negotiation terms.”
In these scenarios, while less common, it makes sense to partner with a provider that can leverage those economies of scale purely from a cost perspective.
Additive Features
Beyond your basic feature requirements, there are also suites of value added features that you wouldn’t necessarily put effort into building in-house, yet may come by default with the solutions providers.
These often include:
- Error logging / flagging
- Dashboard and analytics
- Feature integrations
- Multiple workspaces
- Permissions handling
“One of our clients used to work at a large enterprise project management company where they decided to build their own version of what Userpilot offers. The project turned into building a fully fledged internal solution with actual analytics that would allow tracking, and they ended up spending $3 million in two years,” shares Emilia. “What kind of startup can afford to do that?”
2. Frequency of Updates (Maintenance)
While everyone mentions ‘maintenance’ as the big hidden cost to building, a better way to think about it is the amount of updates the feature will require overtime.
Not only do these features need to adapt to your ever-changing product, as with any core product feature, they should be consistently iterated upon to improve the customer experience or add more value.
“With dashboards, you’ll learn what questions your customers will want to answer from the data, so you start with one template dashboard. But over time you learn about new insights that would be valuable for them, so it’s important that you work with a partner that's agile enough to make changes and deploy new dashboards quickly,” shares Mieke.
The more often changes will be incurred, the more your decision should lean towards buying a low-code/no-code solution (assuming those changes can be made easily through the platform).
A great example would be with shipping interactive in-app experiences, such as product tours, feature announcements, and guided tutorials.
If you build them in-house, everytime your product changes, even to keep the same overall in-app experience, you will need to ask engineering to update the code to adapt to the changes.
If you want to change the behavior of an in-app prompt because the previous flow wasn’t driving users to the ‘Aha’ moment fast enough? That’s a ticket in Jira that needs to be prioritized in the following sprints.
Did you make a grammatical mistake and need to change ‘your’ to ‘you’re’? That’s another change request to engineering.
Compare that to using a platform like Userpilot, where product managers and even growth marketers can go in at any and make adjustments to the in-app experiences without engineering getting involved.
With these types of features, engineering will undoubtedly become a huge bottleneck, as the updates will likely fall below any work around the core product or refactoring in terms of priority.
If however, you don’t anticipate any changes will need to be made in the long run to the feature, especially if your core product remains relatively unchanged, then it may make more sense to build the feature in-house, as it would only be a one-time, upfront cost vs. a recurring cost to your business.
3. Strategic Expertise
Effective product managers are extremely knowledgeable about their core product, the use cases their customers have around the core features and benefits, and can build clear specs and user stories that their engineering teams can rely on.
However, when it comes to ancillary features, they generally will not be subject matter experts.
“Companies are not just buying a tool - they're also buying expertise from a field that they aren't too familiar with.” - Mieke
Coincidentally, both Nimrod and I have used Userpilot. The series of onboarding sessions I had with their team was crucial, because otherwise I would’ve run into this blank slate problem. While I had access to a robust set of tools, I just wouldn’t have known the right way to build an optimal, strategically driven onboarding experience or feature launch tour.
“The biggest problem a lot of our users have is not that they don't know how to use Userpilot to build the experiences, but they don't know what to build,” says Emilia. “That's why we provide onboarding sessions with our product specialists to help them come up with the strategy as well, and some of our users have even asked to pay thousands of dollars for us to build it for them.”
Similarly, at Paragon we’ve seen customers get excited about and purchase our platform, only to realize they didn’t know how to go about designing the integration workflows that would provide the best customer experience. This is why our technical success team, which has seen hundreds of integration use cases, spend a significant portion of their time and resources on helping our customers design how the integrations would function.
4. User Interface
Native & White-labeled Experience
With most customer-facing ancillary features, you may want to provide your users a truly native and white-labeled experience, such that they wouldn't notice that you are leveraging a 3rd party solution at all.
Some of the poorer implementations to watch out for are:
- No white-labeling option, which makes it glaringly obvious that you are using a 3rd party provider
- Redirects to 3rd party hosted sites or popup / iFramed interfaces
The exception to this rule would be when the solutions provider you’re evaluating has such a strong reputation, that it actually becomes an advantage to mention them in the implementation. Take Intercom for example - certain companies intentionally leave it un-white-labeled as a sign of reliability and trust. However, with the majority of the solutions you’re evaluating, this would not apply.
Design & Custom CSS
While it’s safe to assume that you wouldn’t want the customer-facing feature to stand out like a sore thumb within your app, having full control over the CSS of the feature should be a lower priority vs. it being white-labeled / native to your app.
In fact, while this is often a concern to buyers, when it comes time to implement, design always falls down the priority list when compared to functionality and designing for value.
“Ironically, even though less than 15% of all our users use custom CSS, it often comes out during the demo as a requirement.” - Emilia
We have also encountered a similar situation ourselves, where many customers ask about the ability to customize fonts on our Connect Portal (that their end-users interface with). While this is something we are providing soon, all our customers have acknowledged that it’s inconsequential to the success of the feature.
That said, it may still be important to have some control over certain elements of the design depending on what feature you are trying to build, so use your judgement on a case by case basis.
5. Urgency
Another question to ask yourself is, when does the feature need to be completed, and what are the consequences of delaying its launch?
“In growth stages, there can be a lot of pressure to grow faster, and as such the timelines are more strict. A buy decision can overtake a build decision simply because you can go to market much faster for a customer-facing module that your customers are eagerly asking for,” says Mieke.
If the feature is one that has been derived from customer/prospect demand, the easiest way to determine urgency is to evaluate the opportunity costs of not providing the feature within a given timeline.
For example, if your sales team is getting a lot of demand for certain integrations from prospects who are in the pipeline, and it’s preventing them from closing those deals, that’s an extremely time sensitive feature. Similarly, if your customer success team begins to notice that customers are churning, or that multiple customers have raised concerns around the lack of certain integrations, that may also impact the urgency for the feature.
This idea of urgency goes beyond just the initial launch of the feature as well - in line with the earlier point on frequency of updates, make sure to consider how quickly you would need to launch updates and implement fixes throughout the longevity of the feature.
6. Scaling Costs
When buying
“The most sophisticated buyers are looking at how much it will cost them if they’re massively successful,” says Nimrod.
This is a very important point to consider, especially when it comes to usage based pricing tiers, that may push you to pay for features you don’t necessarily need.
“Intercom got a lot of early stage companies on the Startup Plan, but the pricing goes up very steeply as the number of your MAUs (monthly active users) goes up. If you have like a minimal use case within their suite of features, you end up getting really bad value for the money,” adds Emilia.
Both sides of the partnership should benefit fairly as your company grows due to the features you’ve built through the 3rd party platform. Where this can go wrong however, is when the solutions provider locks you into a pricing structure that scales disproportionally to the benefit you’re receiving.
As such, ensure you discuss the costs of scaling with the provider, and potentially negotiate multi-year contracts to lock in a certain pricing structure, assuming you have done your due diligence on the product itself.
When building
On the other side of the spectrum, scaling an ancillary feature to be stable for 10x or 100x more usage comes with significant and often unforeseen costs from an engineering and customer support perspective.
The challenge is that these features are secondary to your core product, and are often hacked together to meet an immediate need.
“If you make the decision to build essentially a separate product, it ends up always being half baked. You ultimately need to make the decision at one point to stop working on the feature that is not core to your business and go back to building your own product,” says Emilia.
This inevitably leads to significant technical debt, which means your team will need to spend a lot of effort, as you scale, on refactoring just to ensure your product can continue to function properly with these features.
In parallel, your core product will likely face its own challenges to overcome around scalability (due to your exponential growth), which will be a far greater priority for your engineering team at that point in time.
This will delay the necessary infrastructure changes required for the ancillary features to accommodate the greater scale, leading to more bugs and errors that your customer support team will then have to manage.
So again, it's crucial to have a clear and longer term view of how the feature will evolve alongside your core product, and to be realistic with the internal resources that you will need to dedicate to maintain it.
7. Resource Constraints
Cash vs. Time
Early stage SaaS startups generally have more engineering resources (time) than runway and cash in the bank. This is especially true if you are bootstrapped or your founding members are from an engineering background, so it may be enticing to sacrifice more of your team’s time to hack together a solution instead of using up more of their cash.
However, it all goes back to the perception of where your time is best spent and how you value you or your team’s time.
“In pre-launch, teams don't like to buy, not just because they lack the resources but very often because building on their own feels like progress. They actually have a lot more time on their hands because they likely haven’t cracked the go-to-market aspect of the business,” shares Nimrod. “In my experience, the ones that buy are generally more established, as they have to hit hard metrics every quarter and spend their time building their own product at a high quality.”
At the end of the day, it goes back to the idea of opportunity costs. So ask yourself, ‘is spending months of my team’s efforts to build, maintain, and scale the feature a more effective use of our time, or could we be working on creating a more unique and differentiated core product?'
Feature Fit
The one caveat to this is if you have yet to validate the need for the feature. If you haven’t received any customer demand for the feature, and simply want to ‘test the waters’ and see if it will help improve a certain aspect of your business (such as sales conversations or retention), it may be worth hacking together a quick solution first.
In these scenarios, it does not make sense for you to commit to an annual contract just for an MVP that you may later realize does not solve a real problem for your customers.
However, once you do validate that the feature has a measurable, positive impact on your growth, that’s when you need to think critically about the long term trade offs mentioned earlier.
Summary
As you may have noticed, the build vs. buy decision is not straightforward by any means. However, by considering all the factors outlined above, you will be much better equipped to make the right choice for your company.
If you only take away 3 things from this entire guide, here are what we recommend you keep in mind:
- Never buy your core differentiator - you should have full ownership of the core aspects of your product that others cannot replicate.
- Have a clear sense of both your short and long term use cases - without it, you cannot evaluate both options fairly both from a costs perspective as well as their requirements coverage.
- Be realistic with the internal resources you’d need to allocate towards maintaining, iterating, and updating the ancillary feature down the line, both for building it in-house and if you were to use a platform.
If you found this guide useful and the roundtable discussion insightful, feel free to reach out to any of the panelists!
Panel Overview
Brian Yam - Head of Marketing
After seeing the inefficiencies while working at both enterprises and startups on integration projects for internal tooling, Brian is on a mission to help companies unify the silo’d SaaS ecosystem.
Company: Paragon
Ship native SaaS integrations for your customers on-demand with little to no code, and 5x your integration roadmap without any additional engineers.
Emilia Korczynska - Head of Marketing
As the author of Product Rantz and named in the 'Ones to watch in 2022' report by Future of SaaS, Emilia’s passion for SaaS products has helped countless companies optimize their in-app experiences to drive product adoption and retention.
Company: Userpilot
Create seamless onboarding experiences for your users with a no-code interface and skyrocket user/feature adoption and retention.
Nimrod Priell - Founder & CEO
With his roots in software engineering, and years of experience as a data scientist and product manager at Facebook, Nimrod saw the inefficiencies of building ancillary features in-house and built his own SaaS platform, Cord.
Company: Cord
Make your product multiplayer in real-time (like Figma/Google Docs) with a single line of javascript.
Mieke Houbrechts - Marketing Manager
From Microsoft to Cumul.io, Mieke has been an expert in the data analytics space, both as an end-user as well as an educator on the value of embedded dashboarding tools.
Company: Cumul.io
Embed user-facing, interactive analytics and dashboards in your app without any engineering.
