The "Build vs. Buy" debate

Traditionally, DAPs' offerings were built in-house, and in many cases today, teams continue to manage tooltips, banners, announcements, etc., with their core product development workflows. 

Most companies that do this have not proactively decided to build in-house rather than buy; they continue to operate as they always have without really considering the trade-offs. 

As more and more SaaS platforms are “hired” to do jobs that previously required employees, it’s at least worth considering the pros and cons of which approach best suits your product and goals. 

To keep it simple and fair, we’ve picked the top 5 reasons to choose either: 

Benefits of building in-house

  • 1 Full customizability and control: not just in terms of design/style but in terms of being deeply entrenched within your UX vs. being an overlaid UX. 
  • 2 There are no dependencies: your UX is not dependent on the uptime or functionality of a third party over which you don’t have control. Any issues are resolvable based on your capacity and capabilities. 
  • 3 No additional cost: you won’t have to “hire” a DAP, and there won’t need to be an additional line item in your budget. In-house resources are already absorbed into your cost basis, and opportunity cost is rarely factored in. 
  • 4 Differentiation: if you want your in-app nudges and experiences to be unique and/or a core capability of your product or service that differentiates it from all others. 
  • 5 Required: as per some of the reasons above, DAPs do not support your technology or platform or are irrelevant to your needs. 

Benefits of buying a platform

  • 1 Depth: A platform will likely offer advanced capabilities that your in-house system will not (e.g., automated clash avoidance, frequency capping, A/B testing, etc.).
  • 2 Engineering time: Engineering time is the most valuable for a software-first company, so you can redirect this to more fundamentally important endeavors. 
  • 3 Speed: There can be an order of magnitude difference in how quickly changes can be made and deployed with a platform compared to in-house. 
  • 4 Tech debt: It’s much easier (and cheaper) to drop or switch a vendor than to continue maintaining and managing a growing in-house system. 
  • 5 Expanded capabilities over time: as with most SaaS platforms, you can benefit from the platform adapting over time to what is successful across the broader market (e.g., new patterns) at low/no additional cost

How to trade off the benefits of building vs. buying

Hopefully, the reasons above help you assess which camp you might fall into, but if not, and you’re still on the fence, here is some of our subjective (but hopefully fair) advice on which might be a better fit for your situation.

Reasons to potentially build over buy: 

  • Icons 300 If you’re cash-poor and can’t afford additional expenditures but can maintain your existing team
  • Icons 300 If the cost of your engineering team is significantly lower than the costs of DAP platforms (e.g. if you’re based in a country with low Purchasing Power Parity)
  • Icons 300 If you have a dedicated Growth Engineering team that doesn’t have many other initiatives to focus on 
  • Icons 300 If in-app experiences are going to be a core differentiator to enable a stronger/deeper PM Fit for your product/service
  • Icons 300 If you can’t afford dependencies or are at a scale (e.g., Facebook, Netflix) where it’s critical to manage systems in-house
  • Icons 300 If you’re unable to leverage a DAP because of technical limitations (i.e., they don’t support your platform because, for example, it’s built into hardware)

Reasons to potentially buy over build:

  • Icons 300 If you’re new to PLG and want exposure to common patterns and best practices for in-app experiences
  • Icons 300 If you don’t have any additional budget or capacity to hire/commit dedicated engineers and designers for an in-house project
  • Icons 300 If you want quick wins from in-app experiences to improve product engagement, retention, upsell, etc. 
  • Icons 300 If your engineering team is already stretched to the limit and there is an existing large backlog of key features/functionality you need to deliver
  • Icons 300 If your experience has been that in-app experiences get deprioritized by the engineering team, even with the best of intentions to build in-house
  • Icons 300 If you want to apply a data-driven approach to measuring and iterating on in-app experiences to drive results
"Previously, we were building things in-house, so if we wanted to test out onboarding flows, they had to be built by our developers, and it took a lot of time to iterate."
Elyssa Stewart, Director of Product Management

Another approach is to use a DAP for experimentation, try the “quick and dirty” approach, and assess which in-app nudges and guidance work before building that into your core UX in-house. There are many ways to experiment with in-app experiences for all use cases (onboarding, activation, upsell, adoption, support, etc.).