Building vs. Buying In-App Chat

Building vs. Buying In-App Chat: The Ultimate Guide to Weighing Cost, Risk, & Other Product Roadmap Decisions

The choice between in-house chat development and today’s vendor solutions is highly consequential. The following considerations belong at the core of any feasibility analysis, cost approximation, or product roadmap.

Here are the high-level build vs. buy factors every product team should examine: 

• Evaluate Your App’s Goals, Priorities, & Core Value Prop 
• Weigh Dev Team Opportunity Cost 
• Compare Costs: Estimating the Financial Investment to Build or Buy Chat 
• Cost to Develop Chat Functionality In House 
• Calculating Initial Chat Development Cost 
• Calculating Maintenance, Improvement, & Scaling Costs 
• Estimate the Cost to Buy an In-App Chat Solution 
• In-App Chat as a Capital vs. Operational Expenditure 
• Evaluate Time to Market & Time to Value 
• Competitive Advantage & Time to Market 
• Select Critical Chat Features: Best-of-Breed vs. MVP 
• Core In-App Chat Features for an MVP Offering 
• Advanced Chat Features 
• Real-World Example: Feature Depth & Reliability with TaskRabbit 
• Identify Risks Involved with Building vs. Buying Chat 
• Security & Compliance 
• Data & Storage Ownership 
• Decision Ownership 
• Scalability 
• Reliability & Performance 
• Technical Debt 
• Cross-Platform Development 
• Vendor Lock-In 
• Make the Final Build vs. Buy Decision
  

The decision to build or buy chat functionality can’t be made lightly. It plays a direct role in your product’s ability to delight users and solve their problems, driving engagement and retention. The decision also has significant financial implications, with an impact on budgeting and prioritization of engineering resources. It’s a decision that must be made with your organization’s unique value proposition, customer base, goals, and requirements in mind. Paired with these factors, the analysis above should help to produce an exhaustive list of pros and cons of building or buying in-app chat functionality, supporting a carefully informed decision. 

For many organizations, the advantages gained in up-front cost, total cost, time to market, and feature depth will make a chat API or SDK solution the logical choice. Still, for others with enough cash and development resources available or with a completely revolutionary vision for how chat looks and functions, in-house development may be worth the investment.

Reference: https://getstream.io/blog/build-vs-buy-chat/

Book Summary - Scrum: The Art Of Doing Twice The Work In Half The Time

Book Summary - Scrum: The Art Of Doing Twice The Work In Half The Time

My key takeaways:

• Scrum needs involvement and alignment from all stakeholders to bring value to the project as early as possible
• Scrum is based on the people they work with; and also it completely varies between the pods and scrum teams
• Clearly define the roles of the team, Scrum Master, Product Manager, Product Owner, Development team along with the QA, etc
• Product development also follows the Pareto Principle: 20% of the requirements represent 80% of the product's value. Thus, the objective is to prioritize the items for the current sprint
• MVP and delivering smaller chunks of product backlog without no major risk to the current production capabilities is the success of scrum
• PDCA cycle (Plan, Do, Check and Act)
• Have a clear way of defining DoR (Definition of Ready) and DoD (Definition of Done) for your scrum team
• Follow your suited sprint ceremonies to get the most out of your scrum outcomes, such as Sprint planning, Sprint, Daily scrum meeting, Sprint Review, and Sprint retrospective
• How fast the daily raised impediments during the scrum standup are getting resolved would define the agility of your scrum team
• Make sure to provide a clear vision, and refine the product backlog so that the sprint backlog is very clear to the scrum team

Reference:

http://amazon.com/Scrum-Doing-Twice-Work-Half/dp/038534645X

When to use Airbyte along with Airflow

 When to use Airbyte along with Airflow?

Airflow shines as a workflow orchestrator. Because Airflow is widely adopted, many data teams also use Airflow transfer and transformation operators to schedule and author their ETL pipelines. Several of those data teams have migrated their ETL pipelines to follow the ELT paradigm. We have seen some of the challenges of building full data replication and incremental loads DAGs with Airflow. More troublesome is that sources and destinations are tightly coupled in Airflow transfer operators. Because of this, it will be hard for Airflow to cover the long-tail of integrations for your business applications. 

One alternative is to keep using Airflow as a scheduler and integrate it with two other open-source projects that are better suited for ELT pipelines, Airbyte for the EL parts and dbt for the T part. Airbyte sources are decoupled from destinations so you can already sync data from 100+ sources (databases,  APIs, ...) to 10+ destinations (databases, data warehouses, data lakes, ...) and remove boilerplate code needed with Airflow. With dbt you can transform data with SQL in your data warehouse and avoid having to handle dependencies between tables in your Airflow DAGs.

References:

Airbyte https://github.com/airbytehq/airbyte

Airflow https://airbyte.io/blog/airflow-etl-pipelines

dbt https://github.com/dbt-labs/dbt-core

dbt implementation at Telegraph https://medium.com/the-telegraph-engineering/dbt-a-new-way-to-handle-data-transformation-at-the-telegraph-868ce3964eb4