Build vs Buy, the great internal debate every developer product has to overcome when selling to companies of all sizes. I had a great chat with Han Wang at Mintlify on how he sees Build vs Buy. Whether its docs, sdks or any part of the developer stack you will always meet great product teams that believe they should build and maintain exactly what your product does in house. Here are some takeaways 👀 ⏹ Its all about control. You're product needs to increase your users ability to ship high quality product. Think deeply about where you should blackbox vs expose controls to the user. ⏹ Quality. Do you think your product reflects the quality at which they could build AND maintain this themselves ? ⏹ Our job as vendors is to grow with companies over time. As your product matures the gap between what you can do vs what can be built in house will quickly diminish. If you're buyer of docs or sdks how do you think about build vs buy ? 👇 Speakeasy #sdks #docs #buildvsbuy
Love the thought process in this video Han Wang. Every API has a primary job/function. At our company, signNow, that job is to help embed eSignature with a bunch of options etc etc. Maintaining the API to achieve that goal is what I would call a secondary job —> providing access to & maintaining the primary. When the project cost (time, resources and actual $) of that secondary work becomes a significant portion of the total (secondary / primary + secondary), then you risk leaving the primary job under developed, under funded, under staffed… and this is when an org should seriously consider buying the docs and sdks. Let the purchase maintain the access, and send your team back to building around your primary expertise that put you on the map to begin with. It’s a balance! What’s the right percentage of this equation to shift from building to buying? Probably have to echo a lot of smart people when they say… “that depends” 😉
Product & Data Engineer @ Kestra
6mo"It depends" answer as always here 😉 I think there are three important points we should examine more closely: 1️⃣ A product without any open-source parts, or with open-source being very different from the enterprise version is often a red flag regarding maintainability, lock-in, and future costs (license fee, hard-to-find experts to work with it, future migration). 2️⃣ If the priced version of the product is inherently different from the open-source project, it should be worth a closer look. 3️⃣ Capturing how much the company is playing the "attract-extract" game is essential before you decide to purchase any software. cf recent writing on this never ending subject (here on data, but it can be extrapolated) 😅 https://medium.pimpaudben.fr/the-data-team-equation-balancing-staffing-with-provisioning-059132faf42f