My personal Build vs Buy strategy

Type
Blog
Published
September 16, 2024
Author
Chetan Agrawal
In this post, I am trying to discover my thoughts about investing in software and some of the biases that I have towards it. This is in-spite of me understanding about how the software businesses work and scale and make money. Later I share some changes that I am trying to bring about in my thought process around build vs buy software for personal usage. This post can be extrapolated to think about the strategy in principle for a business use case as well.

🤔 How I think about buying software subscriptions

The engineer in me always gets biased around buying a software service. I find it hard to justify the cost and ROI. Till date I possess very less number of subscriptions for software products. The only ones I have are GSuite, Apple pay and Canva. The first 2 are mostly for cloud storage via phone. And Canva is still something I am trying to experiment around and justify the cost.
I spend a lot of time to find the open-source version of the software and see if the software is already available for free. I maintain a list of softwares that can either run for free on my machine or can be hosted on a cheap cloud like Hostinger. I don’t use Docker or AWS or GCP to host these. 🤑🤑🤑
I also want to define the scope of personal usage as that may mean so many things for so many people. I try to do a lot of very small scale experiments regularly. Most of them are unfinished and never published(something I am not very proud of and have been meaning to change). This can be small scale software projects, personal branding, a content marketing idea or a simple affiliate program that I want to run on the internet. You can classify most of the usage as trying to build a small scale 1-person business. Hope this helps set a context.

Why buying a software is a good decision & building one is not

Here is how I understand about how the software businesses work. Apart from solving a niche problem, which they have to solve for to stay relevant, they also have to operate at high efficiency in terms of cost of building and related operations like sales and support. Which is also hard to achieve for an individual, even if we ignore the sales and support side of things.
Following is how I think why a buying a particular software works.
  • 💰 Cost Efficiency When you buy, the seller can often offer the solution at a cheaper price due to economies of scale. By selling the same solution to multiple customers, the seller spreads out infrastructure and development costs, making it more affordable for everyone.
  • 🎯 Focus on Core Problem Building solutions in-house can be time-consuming and resource-intensive, especially when the solution is not part of the core problem at hand. Purchasing a pre-built solution allows you to focus on what you do best and avoid distractions.
  • ⏰ Faster resolution (read Time-to-Market in business tone) Buying often means you can implement the solution immediately, while building can take months, if not years. In fast-moving industries, getting to market quickly can be a huge competitive advantage.
  • 👨‍🔬 Access to Expertise Vendors specialize in creating their solutions, which means they’ve refined and perfected their product over time. By buying, you gain access to their expertise without having to hire or train a team in-house.
  • 🛠️ Continuous Improvements When you buy a solution, you're often getting access to regular updates and improvements. Vendors stay on top of industry trends and technology advancements, ensuring your solution remains competitive and up-to-date.
💭

Example businesses to run above factors as thought exercises.

  • Using Salesforce, Zendesk or Freshworks instead of building their own CRM for cost and efficiency reasons.
  • Using AWS, GCP or Azure and not build an entire suite of cloud services.
  • Using OpenAI APIs and not building an AI of your own.

Why buying software is not a good decision

While all the above points make it very plausible to make the buy decision, a lot of it also depends on few other factors that most likely is to drill a hole in your pocket or not sit well as you scale in the long run. Doesn’t mean that we should now build one, more on that later.
While most of the impact mostly affects in terms of cost, there are few cases around how you would want to consider the impact of solutions offered by software services. Also, most of them will also become more relevant with changing scale and requirements. So there is real right or wrong, only factors for consideration.

Cost related impact

  • 📈 Scale with increased usage Consider pricing structures carefully, especially team vs. individual plans. Opt for flexible, pay-as-you-go models when possible to manage costs and scale efficiently. This approach prevents overpaying for unused features and allows adjustments based on real-time needs, ideal for personal projects or small-scale experiments with varying requirements.
  • 💰 Long-term Cost Implications of Build vs Buy Decisions When evaluating software solutions, it's crucial to consider the long-term financial impact. While building a solution might seem cost-effective initially, it's important to factor in ongoing maintenance, updates, and potential scalability issues. Conversely, buying a solution may have higher upfront costs but could prove more economical over time due to vendor-managed updates and scalability. Careful analysis of both options over an extended period is essential for making an informed decision.
  • 🥷 Bundled Services and Hidden Costs Software packages often include extra features that can unexpectedly increase costs. For example, a basic CRM might seem cheap, but add-ons like analytics or automation can significantly raise the price. Carefully assess bundled offerings to avoid paying for unnecessary features.
  • 🔓 Annual Subscriptions and Vendor Lock-in While discounted, annual subscriptions can lead to vendor lock-in. Switching solutions may become costly due to data migration, integration, and retraining. Consider long-term implications and exit strategies before committing. Month-to-month plans or ensuring data portability can mitigate these risks.

Feature related impact

When evaluating software solutions, consider how well they align with your specific needs. Off-the-shelf options may include unnecessary features, leading to feature bloat and increased costs. Conversely, they might lack essential functionalities, requiring workarounds or additional integrations that complicate your workflow. It's crucial to find a balance between comprehensive features and streamlined efficiency for your particular use case.
  • 🛂 Customization Limitations Off-the-shelf solutions often have limited customization options. This can be problematic if your workflow requires specific features or functionalities that aren't available or can't be modified in the pre-built software. Example - Things you can do with no code tool Softr.
  • 🧩 Integration Challenges Some software may not integrate well with your existing tools or systems. This can lead to data silos, inefficient workflows, or the need for complex workarounds, potentially negating the benefits of using the software. Example - Tally(Accounting software) integrations.
  • 🔐 Data Privacy and Security Concerns Using third-party software often means entrusting your data to external providers. This can raise concerns about data privacy, security, and compliance, especially if you're dealing with sensitive information or operating in a regulated industry. Example - Every cloud service provider.

When building a software is a good decision

  • Build for Cost Efficiency As your project grows, developing custom solutions can become more cost-effective than paying for increasingly expensive software subscriptions. This approach allows you to tailor the functionality precisely to your needs and avoid paying for unnecessary features.
  • Build to Customize and Optimize Workflow Consider building your own solution when off-the-shelf products don't quite fit your unique processes. For instance, creating a custom task manager allows you to design a system that perfectly aligns with your personal or team's workflow, potentially boosting productivity and efficiency.
💭
Thought exerciseA CRM is a customized task manager for a sales team.
  • Build to solve a niche If you've identified a specific niche problem that existing solutions don't adequately address, building your own software can be a strategic decision. This not only solves your immediate need but could potentially evolve into a marketable product, opening up new business opportunities.

Build and sell - possibly your own micro saas service

When building, you are solving for a particular factor as listed above. And this same problem may be faced by other people as well, which opens an avenue to sell the software service that you built. Check the factors list above for the newly built software and if all checks out, you can sell the software as a service for a small premium. This helps you optimize running your software solution and also create a business vertical of its own.
This do comes at a cost of split focus. You may be moving away from your core expertise and solve for a tangential problem. Also, there is added nuance of supporting another business vertical operationally. If this is not a priority for you or your business, and still demands time off you, this is something better to delegate or pay for.

Alternative Mental Model for Build vs Buy Decisions

When contemplating whether to build or buy software solutions, consider these alternative mental models to guide your decision-making process:
  • Fail Faster Approach: Embrace the concept of rapid experimentation. Buying solutions allows you to quickly test ideas and pivot if necessary, without significant time investment in development.
  • Time as a Valuable Resource: Consider the following time-related factors:
    • Research Time: Evaluate the hours spent searching for the perfect tool. Sometimes, the time invested in finding the right solution can outweigh the cost of purchasing a readily available option.
    • Maintenance Overhead: Factor in the ongoing time commitment required for maintaining a custom-built solution versus the typically lower maintenance needs of purchased software.
  • Leveraging Free Trials: Take advantage of free trial periods offered by many software providers. This approach allows you to thoroughly test solutions before committing, helping you make more informed decisions without immediate financial investment.
  • Scalability Considerations: Assess how well a solution can grow with your needs. Purchased software often offers scalability options that might be challenging to implement in custom-built solutions.
  • Total Cost of Ownership (TCO): Look beyond the initial price tag. Consider long-term costs including updates, support, and potential customizations for both build and buy options.

Summary

Key Considerations in Build vs Buy Decisions
  • Buying software offers cost efficiency, faster implementation, and access to specialized expertise.
  • Building is ideal for unique workflows, niche problems, or micro-SaaS opportunities.
  • Consider long-term costs, including maintenance, updates, and scalability for both options.
Drawbacks of Buying Software
  • Limited customization and integration challenges.
  • Hidden costs and bundled services may increase expenses.
  • Vendor lock-in through subscriptions can make switching costly.
Alternative Decision Models
  • Use the "Fail Faster Approach" for rapid experimentation with existing solutions.
  • Evaluate Total Cost of Ownership (TCO), including long-term costs like support and customizations.
 
Disclaimer: A lot of the content above was elaborated with help of an AI, but the broader points are written with my own thoughts and understanding.