{"id":3321,"date":"2020-08-20T15:35:33","date_gmt":"2020-08-20T15:35:33","guid":{"rendered":"https:\/\/mbaoutcome.com\/the-true-costs-of-building-vs-buying-a-product-or-app\/"},"modified":"2020-08-20T15:35:33","modified_gmt":"2020-08-20T15:35:33","slug":"the-true-costs-of-building-vs-buying-a-product-or-app","status":"publish","type":"post","link":"https:\/\/www.varshabi.com\/MB\/2020\/08\/20\/the-true-costs-of-building-vs-buying-a-product-or-app\/","title":{"rendered":"The True Costs of Building vs. Buying a Product or App"},"content":{"rendered":"

[et_pb_section][et_pb_row][et_pb_column][et_pb_text]<\/p>\n

At MB&A<\/a> our customers often ask us for advice on building versus buying. One of the most appealing aspects of Salesforce is that it\u2019s an easy platform to use for building, extending, and reconfiguring to suit organizational needs and preferences. Here at MB&A we do a lot of building, but it\u2019s mostly on our product line, not custom development for things we use internally. It may surprise you to learn that, despite our development resources, our default mode is to buy before we build.<\/p>\n

The \u201cwhy\u201d is important here. Why would a company that \u201ccould\u201d build just about anything choose to buy instead?<\/strong><\/p>\n

This comes down to three factors:<\/p>\n

    \n
  1. Today\u2019s needs vs. tomorrow\u2019s wants.<\/strong> We always look at the market first, because what we need today is simple. By investigating the products in a given space, we\u2019re more likely to anticipate what we\u2019ll want tomorrow. On a deeper level, we gain a window into how complex our needs and wants really<\/em> are.<\/li>\n
  2. Maintaining organizational focus. <\/strong>Although it may seem obvious, it\u2019s worth emphasizing that anything we build now puts us on the hook to add features, maintain existing ones, and reconfigure them for use over time. Essentially, this means we\u2019re running a mini product team that includes development, support, and professional services. This can become a major distraction that limits your ability to focus on whatever the specific focus of your organization actually should be.<\/li>\n
  3. Hidden complexity = hidden costs. <\/strong>If there are already products available in a space you\u2019re thinking about building in, you can bet that there is a level of complexity you aren\u2019t seeing or considering. The mere act of building adds complexity to your organization, not to mention costs. Customization requires maintaining features, integrations and services that would otherwise be handled by the vendor.<\/li>\n<\/ol>\n

    At this point, you may be wondering: Is it ever worthwhile to build? My short answer is a resounding \u201cyes,\u201d and here are a couple of really good reasons to do it:<\/p>\n

      \n
    1. Unique requirements. <\/strong>Sometimes what you require is so unique that there are no products that satisfy your needs. In fact, we built our commissioning system supporting our sales process because I wanted to extend it from simply sales to gamification of behavioral rewards across our company. It\u2019s good enough at this point that we\u2019re considering making it a product.<\/li>\n
    2. Simple needs, low costs. <\/strong>Sometimes what you want is so simple that the product version would be overkill and carry disproportionate costs compared to overall value. This was the case with the time keeping system we use to track the time we spend against different activities. Since our needs were very simple, we figured that we could get by with a small feature set for years (and we have).<\/li>\n<\/ol>\n

      Balancing out my \u201cresounding yes\u201d just above, I\u2019ll offer a word of caution. Potential customers sometimes tell us that they have unique requirements, and, understandably, choose to build in the compliance product space. However, their unique requirements tend to come with an enormous price tag and without guarantees. From our \u201cwhat could go wrong?\u201d file, prior to working with us, one of our customers originally spent $9M in pursuit of their uniqueness<\/em>, only to end up purchasing from us when they couldn\u2019t get their custom solution to the field. For that price, they could have gotten 15 years\u2019 worth of our app for their use case.<\/p>\n

      Of course, they didn\u2019t get to $9M overnight. This number rose after two years of trying to get into the field (with an initial projection of six months). Remember those features that were so unique? It turns out they weren\u2019t as unique as our customer originally thought. Yes, we will probably need to build some custom extensions to fill in their gaps and meet all of their needs, but this work will take weeks (not months) and thousands (not millions) of dollars.<\/p>\n

      More recently, they have also gotten to experience one of the biggest presents that comes with having a product instead of a custom build: the \u201cfound feature.\u201d When they found out that we were planning to release our Remote Virtual Inspection (RVI) module later this month, they told us that even though they hadn\u2019t anticipated needing it, the RVI will have a significant impact on their ability to get into the field and perform inspections throughout the pandemic.<\/p>\n

      This is huge fringe benefit of buy over build. Said another way: You get to benefit from the fact that product companies listen to all of their customers, and their features consistently reflect that over time. We often find ourselves having just built the thing a customer is asking for, because \u2013 quite simply \u2013 the need isn\u2019t unique.<\/p>\n

      The other thing we hear a lot from potential customers is that their use case is \u201ctoo simple\u201d and they don\u2019t need all the \u201cbells and whistles.\u201d We\u2019ve seen legitimate cases where folks have had a very narrow use case, where we simply needed to build a custom app and that helps you achieve a business objective. In fact, this is what Salesforce does best; it enables you to rapidly extend the base platform to simply add the information that you require to get the job done.<\/p>\n

      While you\u2019re assessing how simple or complex your need is today, I would advise you to give some thought to the future. How stable is the data required for the process? How stable is the process? In my experience, data stability is a good proxy for overall<\/em> stability. In most organizations, technology changes rapidly, processes a bit more slowly, and data is the slowest of all.<\/p>\n

      Consider filling out a job application. The job description and information a specific employer is looking for probably hasn\u2019t changed much in years. The role or processes may have changed a bit, but probably not much. But the way that information is captured, stored, and shared has likely gone from paper through several iterations of technology to its present form.<\/p>\n

      Now, apply this same mentality to your simple app. If you don\u2019t think the data you need or the process or people will change much in the next 12-24 months, you are probably in a good place to make a decision. Alternatively, if it\u2019s evolving, you might want to think about a product that may be better suited to meet both today\u2019s and tomorrow\u2019s needs.<\/p>\n

      Interested in learning more about our products? Check out:<\/strong><\/em><\/p>\n