Imagine this: A customer is browsing through your app, window shopping, and then closes the app after a while because nothing is enticing. But then you add a review feed. Now, the user sees beyond the product specification. They can read the experiences of others, ask questions, and share their pre-, post, and after-purchase experiences, and suddenly you have a highly engaged audience.
You use these User Generated Content (UGC) pieces to boost your acquisition and repurchase strategies. With time you have reduced your CAC, improved brand visibility and credibility, and increased your revenue and profits.
All of this is possible by adding an aspect(s) of one feature: feed.
In this blog, we’ll dive into understanding everything that goes into having an in-app feed feature from different forms of cost to other factors that can impact the decision to build in-house or integrate a 3rd party solution and how to decide between the two. Let’s dig in!
There are a few factors that you need to consider when building in-house such as costs including direct and indirect, current vs future recurring, scaling and customizing challenges, compliances, and more. Let’s look at each one of these:
One of the key factors when considering whether to build, buy, or defer any type of app functionality is cost. Let’s look at some direct as well as indirect cost components when building in-house.
The cost considerations for building feeds in-house or buying an existing solution differ significantly. Building in-house incurs expenses that scale with the size of the development team required for the project's complexity. On the other hand, buying a third-party solution like LikeMinds involves license fees that vary based on active user count and the specific services needed.
The flip side of the same argument is that while in-house development avoids license fees, it requires accounting for man-hours, infrastructure setup, and maintenance costs, which are notoriously difficult to estimate accurately.
To help you with cost estimates of a similar solution as ours, we have prepared a breakdown outlining the estimated time and resources required to build a comparable solution:
While the above analysis gives a glimpse of the estimated engineering effort, it doesn’t include other factors such as designs and testing cycles involved in the building process (i.e. Designer, Product Manager, QA). Once you add those, the costs will start adding up pretty quickly.
The following table will give you a rough cost estimate for building a feed feature with a mid-level experienced team:
Keep in mind that a thorough evaluation of the financial implications, including potential variability and unforeseen expenses, is crucial for both approaches.
These estimates are for building in India. Don’t forget to account for PPP if you are based out of a country where manpower costs are higher and you can not ship off development to a country with similar manpower costs due to regulatory constraints.
There are a few variables that will determine the actual server costs you will incur when building in-house. Let’s look at them individually:
Every hour worked is a missed tea/coffee break. In more serious terminology, opportunity cost is what your developers could have achieved if they worked on something else.
Instead of building a feed experience from scratch, they could focus on critical business features that are unique to the business and can't be obtained from third-party vendors. They can also focus on customizing the 3rd party integration for your business goals. This allows them to deliver more value with their limited time and resources.
To prevent your solution from regressing and to keep up with evolving compliance requirements (like GDPR, CCPA, ADA, PCI, HIPAA, etc.), significant ongoing investment is needed. Estimates suggest companies typically spend $10,000-$25,000 per year on maintenance. You'll also need to iterate frequently to provide what the user wants, which is a time-consuming process.
Supporting numerous technology stacks to maintain parity across all platforms requires substantial engineering effort and cost. Between iterating on your product, keeping compliant with new regulations, and maintaining multiple codebases, the required investment adds up quickly.
Ask yourself the opportunity cost of using your resources on maintenance tasks instead of core business priorities.
These are the costs incurred when your business wants to seize and address a new opportunity. The market demands can be extremely time-sensitive or seasonal so you’ll need to act urgently without any delay. A 6-12 months wait might mean losing out to your competitors.
An interesting fact to note here is that only 34% of the companies seek to get a first-mover advantage, a true competitive edge missed by the remaining 66%. If you want to move into the first group, you need to account for strategic costs on top of your existing maintenance costs.
Now that we have discussed cost aspects, let’s look at other factors such as security and compliance, scalability and customizability, etc. that you need to keep in mind when adding any feature in-house:
Since you are dealing with user-generated content, data security should be a paramount concern when implementing a feed feature, regardless of whether you choose to build it in-house or opt for a third-party vendor.
The amount and type of risk associated with these two approaches can vary significantly, making it essential for product managers to carefully assess the level of risk that is acceptable for their application, especially if leaning towards working with a vendor.
Building a feed in-house allows for greater control over data security measures. It also places the burden of ensuring compliance with various regulations and standards squarely on your shoulders.
A simple feed experience is straightforward for a small user base but complexity increases exponentially as the number increases. E.g. With every new user in the system, an individual activity feed and personalized feed is created. So, on a new post creation, all the activity feeds and the personalized feeds will be updated who are related to that new post. This will consume more computing power, more storage space in the cache, more updates in the database, and many more actions will occur in the backend which gets difficult to manage as the scale grows.
Scaling an activity feed to handle real-time updates, data consistency, and optimized performance for a large user base is a significant technical challenge that requires substantial engineering efforts and ongoing maintenance. The inability to estimate these scaling complexities can negatively impact user experience and engagement.
A core advantage of building the product in-house gives you complete control over customization, allowing you to tailor the solution to your specific needs and requirements.
Customisability is paramount because it directly impacts your ability to iterate quickly, differentiate your product, and deliver a tailored experience that meets the unique needs of your customers. Therefore, when considering external vendors, prioritize those that offer the most extensive customization capabilities for their feed solutions.
Let’s look at each of the factors that come into play when building an in-house solution but instead, now you are integrating a 3rd party solution:
Since you are not building in-house, there would be:
Instead, there would be costs such as licensing, onboarding fees, etc. Let’s take a quick look at each one of them.
Third-party vendors typically charge a recurring subscription fee, which can be based on various pricing models, such as:
Some vendors may have a one-time implementation or onboarding fee to cover the costs of setting up the software, data migration, user provisioning, and initial training.
These fees can vary depending on the complexity of the implementation, the number of users, and the level of customization required.
If you are an early-stage startup, you may not have dedicated resources to integrate the product from the third-party vendor with your existing systems and workflows. For that, you may need to engage an external agency or consulting firm.
These agencies typically charge project-based fees or hourly rates for their services, which can vary depending on the complexity of the integration, the number of systems involved, and the level of customization required.
Now let’s look at the other factors too that change when considering a third-party vendor instead of building in-house:
As we saw, while building in-house it’s a great hassle to maintain security and compliance. Partnering with a third-party vendor can remove much of that burden IF they have these protocols in place. So if you end up choosing an external solution go with a provider that has these critical security protocols in place, eliminating the need for you to invest substantial time and resources into implementing and maintaining them independently.
When evaluating any ready-made activity feed solution, look out for highly scalable and reliable infrastructure designed to seamlessly grow with your app. While maintenance would still be required, look out for a service that provides sufficient support and robust documentation to smoothly navigate scaling challenges.
Scaling your app across multiple platforms like iOS, Android, web, and desktop introduces new challenges for maintaining consistent activity feed functionality. While an in-house team may initially build a seamless feed experience for one platform, they may lack the expertise to replicate it across others.
A third-party vendor like LikeMinds can bridge this gap, providing the necessary infrastructure and support to ensure your activity feeds perform flawlessly across all platforms, enabling a cohesive user experience as you expand your reach.
With an external vendor, customisability may be limited, making it challenging to adapt the product to your unique use cases. Still, if you are thinking of going with an external vendor then a highly customizable solution will:
Note that a 3rd party solution will almost always be cost-efficient, especially for segmented offerings such as in this case, feed features due to economies of scale. 3rd party vendors serve multiple clients and therefore even though they incur engineering, server, and compliance costs, etc. these get distributed across their customer base.
By now you would have started to gain clarity on what approach works better for you. Let’s compare each of the factors and see which option ranks better as well as a few other factors that can tip the scale further in one direction:
Building an in-house solution or using a third-party vendor has its own pros and cons. In-house development allows full customization but requires significant upfront and ongoing engineering, infrastructure, and maintenance costs. Third-party vendors offer faster implementation, scalability, reliability, and reduced overhead, with costs typically limited to licensing, integration, and consulting fees.
When considering a solution, evaluate the vendor's track record, product roadmap, alignment with requirements, and long-term total cost of ownership (TCO). While in-house development may suit specific needs, third-party vendors can provide a more cost-effective, scalable, and reliable path forward for many organizations, allowing them to focus on core competencies.
Ultimately, the decision should be driven by a comprehensive analysis of resources, capabilities, budget constraints, and long-term goals. However, the potential benefits of a third-party vendor often make it a compelling option worth serious consideration.
By choosing LikeMinds, businesses can concentrate on enhancing their application's user experience and core differentiators, while we handle the complexities of scaling a high-performance, secure, and compliant feed solution, backed by cost-effective pricing and comprehensive support.
Deploy customised features on top of chat and feed in 15 minutes using LikeMinds SDK.
Schedule a demo!Get a front row seat to everything happening at LikeMinds including some curated expert insights each week, delivered straight to your inbox.
We promise to not spam. 🤝🏻
Imagine this: A customer is browsing through your app, window shopping, and then closes the app after a while because nothing is enticing. But then you add a review feed. Now, the user sees beyond the product specification. They can read the experiences of others, ask questions, and share their pre-, post, and after-purchase experiences, and suddenly you have a highly engaged audience.
You use these User Generated Content (UGC) pieces to boost your acquisition and repurchase strategies. With time you have reduced your CAC, improved brand visibility and credibility, and increased your revenue and profits.
All of this is possible by adding an aspect(s) of one feature: feed.
In this blog, we’ll dive into understanding everything that goes into having an in-app feed feature from different forms of cost to other factors that can impact the decision to build in-house or integrate a 3rd party solution and how to decide between the two. Let’s dig in!
There are a few factors that you need to consider when building in-house such as costs including direct and indirect, current vs future recurring, scaling and customizing challenges, compliances, and more. Let’s look at each one of these:
One of the key factors when considering whether to build, buy, or defer any type of app functionality is cost. Let’s look at some direct as well as indirect cost components when building in-house.
The cost considerations for building feeds in-house or buying an existing solution differ significantly. Building in-house incurs expenses that scale with the size of the development team required for the project's complexity. On the other hand, buying a third-party solution like LikeMinds involves license fees that vary based on active user count and the specific services needed.
The flip side of the same argument is that while in-house development avoids license fees, it requires accounting for man-hours, infrastructure setup, and maintenance costs, which are notoriously difficult to estimate accurately.
To help you with cost estimates of a similar solution as ours, we have prepared a breakdown outlining the estimated time and resources required to build a comparable solution:
While the above analysis gives a glimpse of the estimated engineering effort, it doesn’t include other factors such as designs and testing cycles involved in the building process (i.e. Designer, Product Manager, QA). Once you add those, the costs will start adding up pretty quickly.
The following table will give you a rough cost estimate for building a feed feature with a mid-level experienced team:
Keep in mind that a thorough evaluation of the financial implications, including potential variability and unforeseen expenses, is crucial for both approaches.
These estimates are for building in India. Don’t forget to account for PPP if you are based out of a country where manpower costs are higher and you can not ship off development to a country with similar manpower costs due to regulatory constraints.
There are a few variables that will determine the actual server costs you will incur when building in-house. Let’s look at them individually:
Every hour worked is a missed tea/coffee break. In more serious terminology, opportunity cost is what your developers could have achieved if they worked on something else.
Instead of building a feed experience from scratch, they could focus on critical business features that are unique to the business and can't be obtained from third-party vendors. They can also focus on customizing the 3rd party integration for your business goals. This allows them to deliver more value with their limited time and resources.
To prevent your solution from regressing and to keep up with evolving compliance requirements (like GDPR, CCPA, ADA, PCI, HIPAA, etc.), significant ongoing investment is needed. Estimates suggest companies typically spend $10,000-$25,000 per year on maintenance. You'll also need to iterate frequently to provide what the user wants, which is a time-consuming process.
Supporting numerous technology stacks to maintain parity across all platforms requires substantial engineering effort and cost. Between iterating on your product, keeping compliant with new regulations, and maintaining multiple codebases, the required investment adds up quickly.
Ask yourself the opportunity cost of using your resources on maintenance tasks instead of core business priorities.
These are the costs incurred when your business wants to seize and address a new opportunity. The market demands can be extremely time-sensitive or seasonal so you’ll need to act urgently without any delay. A 6-12 months wait might mean losing out to your competitors.
An interesting fact to note here is that only 34% of the companies seek to get a first-mover advantage, a true competitive edge missed by the remaining 66%. If you want to move into the first group, you need to account for strategic costs on top of your existing maintenance costs.
Now that we have discussed cost aspects, let’s look at other factors such as security and compliance, scalability and customizability, etc. that you need to keep in mind when adding any feature in-house:
Since you are dealing with user-generated content, data security should be a paramount concern when implementing a feed feature, regardless of whether you choose to build it in-house or opt for a third-party vendor.
The amount and type of risk associated with these two approaches can vary significantly, making it essential for product managers to carefully assess the level of risk that is acceptable for their application, especially if leaning towards working with a vendor.
Building a feed in-house allows for greater control over data security measures. It also places the burden of ensuring compliance with various regulations and standards squarely on your shoulders.
A simple feed experience is straightforward for a small user base but complexity increases exponentially as the number increases. E.g. With every new user in the system, an individual activity feed and personalized feed is created. So, on a new post creation, all the activity feeds and the personalized feeds will be updated who are related to that new post. This will consume more computing power, more storage space in the cache, more updates in the database, and many more actions will occur in the backend which gets difficult to manage as the scale grows.
Scaling an activity feed to handle real-time updates, data consistency, and optimized performance for a large user base is a significant technical challenge that requires substantial engineering efforts and ongoing maintenance. The inability to estimate these scaling complexities can negatively impact user experience and engagement.
A core advantage of building the product in-house gives you complete control over customization, allowing you to tailor the solution to your specific needs and requirements.
Customisability is paramount because it directly impacts your ability to iterate quickly, differentiate your product, and deliver a tailored experience that meets the unique needs of your customers. Therefore, when considering external vendors, prioritize those that offer the most extensive customization capabilities for their feed solutions.
Let’s look at each of the factors that come into play when building an in-house solution but instead, now you are integrating a 3rd party solution:
Since you are not building in-house, there would be:
Instead, there would be costs such as licensing, onboarding fees, etc. Let’s take a quick look at each one of them.
Third-party vendors typically charge a recurring subscription fee, which can be based on various pricing models, such as:
Some vendors may have a one-time implementation or onboarding fee to cover the costs of setting up the software, data migration, user provisioning, and initial training.
These fees can vary depending on the complexity of the implementation, the number of users, and the level of customization required.
If you are an early-stage startup, you may not have dedicated resources to integrate the product from the third-party vendor with your existing systems and workflows. For that, you may need to engage an external agency or consulting firm.
These agencies typically charge project-based fees or hourly rates for their services, which can vary depending on the complexity of the integration, the number of systems involved, and the level of customization required.
Now let’s look at the other factors too that change when considering a third-party vendor instead of building in-house:
As we saw, while building in-house it’s a great hassle to maintain security and compliance. Partnering with a third-party vendor can remove much of that burden IF they have these protocols in place. So if you end up choosing an external solution go with a provider that has these critical security protocols in place, eliminating the need for you to invest substantial time and resources into implementing and maintaining them independently.
When evaluating any ready-made activity feed solution, look out for highly scalable and reliable infrastructure designed to seamlessly grow with your app. While maintenance would still be required, look out for a service that provides sufficient support and robust documentation to smoothly navigate scaling challenges.
Scaling your app across multiple platforms like iOS, Android, web, and desktop introduces new challenges for maintaining consistent activity feed functionality. While an in-house team may initially build a seamless feed experience for one platform, they may lack the expertise to replicate it across others.
A third-party vendor like LikeMinds can bridge this gap, providing the necessary infrastructure and support to ensure your activity feeds perform flawlessly across all platforms, enabling a cohesive user experience as you expand your reach.
With an external vendor, customisability may be limited, making it challenging to adapt the product to your unique use cases. Still, if you are thinking of going with an external vendor then a highly customizable solution will:
Note that a 3rd party solution will almost always be cost-efficient, especially for segmented offerings such as in this case, feed features due to economies of scale. 3rd party vendors serve multiple clients and therefore even though they incur engineering, server, and compliance costs, etc. these get distributed across their customer base.
By now you would have started to gain clarity on what approach works better for you. Let’s compare each of the factors and see which option ranks better as well as a few other factors that can tip the scale further in one direction:
Building an in-house solution or using a third-party vendor has its own pros and cons. In-house development allows full customization but requires significant upfront and ongoing engineering, infrastructure, and maintenance costs. Third-party vendors offer faster implementation, scalability, reliability, and reduced overhead, with costs typically limited to licensing, integration, and consulting fees.
When considering a solution, evaluate the vendor's track record, product roadmap, alignment with requirements, and long-term total cost of ownership (TCO). While in-house development may suit specific needs, third-party vendors can provide a more cost-effective, scalable, and reliable path forward for many organizations, allowing them to focus on core competencies.
Ultimately, the decision should be driven by a comprehensive analysis of resources, capabilities, budget constraints, and long-term goals. However, the potential benefits of a third-party vendor often make it a compelling option worth serious consideration.
By choosing LikeMinds, businesses can concentrate on enhancing their application's user experience and core differentiators, while we handle the complexities of scaling a high-performance, secure, and compliant feed solution, backed by cost-effective pricing and comprehensive support.
Deploy customised features on top of chat and feed in 15 minutes using LikeMinds SDK.
Let's start!