When building a digital product, the choice between integrating a solution and coding something yourself is often the choice between fast-paced growth and dragging behind: a 🚀 vs. 🐌 thing.
In case you’re creating a new product, time matters. On the way there, it’s essential to focus on values it will create and ways to market those values, not the infrastructure around. We concentrate on this mindset when developing a new feature or shipping a product and explain why we do that in this article.
The choice of a development culture has a massive impact on how you manage resources, your growth rate, and your company’s success. Setting your mind to a degree of abstraction where you decide which parts of your big picture are “Not invented here” is an excellent exercise. You then start looking at your product as a collection of building blocks. You pick an integration for one and build another.
However, there are many tech-oriented Product Owners and CTOs out there who faithfully follow the do-it-yourself code. While this works for core product features, platforms and integrations exist for everything else. It’s easy to underestimate the real resource cost needed to build out something which won’t add up to your value propositions. Building blocks are fantastic and here’s why.
Every extra minute spent in development is another minute where you’re not in the market. You also get maintenance as a natural consequence of coding something from scratch. It steals attention from shipping something new or implementing product changes driven by analytics. There also is competition waiting for a moment to swoop in and beat you to the punch.
Now, let’s get back to the developers treating writing their entire codebase as almost a religious duty. The intent is understandable: developers are good at coding things, so why not grab their talent and craft something customizable to fit every need of your product. However, every time your project involves coding, keep in mind 66% of software development projects overrun on cost and 33% overrun their schedule. The figures might look placeholdery, but those are real.
APIs and platforms save resources and add value to your product. When you’re trying to quickly get to the market or decide whether or not your product is heading in the right direction by testing some hypotheses, integrations speed everything up.
However, integrations are not a silver bullet. You also need to spend time in development to get set up. You want a platform that you won’t need to fork and customize to a large extent. While the thorough customization is most probable with open source, there are many paid products requiring the same effort. So pick wisely and mind the maintenance costs.
If you choose to go with the build option, you risk creating a product that’s difficult to maintain in the long run. Having a proprietary codebase means you alone are responsible for it. Your code can (and will) grow to eventually demand more resources to refactor, rewrite or simply keep it running.
Integrating APIs and platforms, developers will work with a set of building blocks, focus on the task and their particular set of skills. You won’t spend resources maintaining some code that doesn’t power any of your core features or infrastructure. The great thing about platforms is they usually provide SLAs, do the heavy lifting in their area of expertise, and give you virtually infinite room to grow.
Of course, there’s an upside of having a proprietary codebase. It’s yours. At the end of the day, the platform you integrated may cease to exist. Much more likely, the development of that integration might go wrong. So, it’s always helpful to clearly understand the roadmap of each product you analyze.
You can minimize such risks by discovering a couple of similar products to be able to migrate there. What’s certain about any integration from such a set, they allow you iterating a product at a much faster pace.
Platforms help businesses test their MVP or hypothesis faster. Through off-the-shelf components and frameworks, you will be able to assemble and iterate your apps at a much faster pace. That’s how Uber did it: they patched together best-in-class APIs to carry out their platform’s most essential functionality. When you insist on writing every line of code, you’re doing work that’s already been done for you.
Even essential app functions like ingesting and processing files and data can require highly detailed levels of infrastructure that can’t be built overnight. Users have come to expect apps that function correctly the moment they’ve hit their browser or device. If your handmade equivalent of a popular API offers a poor user experience, it can make your product seem like a second-rate solution compared with other apps.
It’s good to mention that paid platforms also vary in terms of their UX quality. Run some tests with different products around your staging area before deploying the experiment winner to production. You should establish a clear workflow for testing integrations: create a culture of using platforms that suit your product in the long run and will give you room to grow.
Create the culture of growing fast
The culture of a fast-paced growth is not about trying to squeeze eighty hours of productivity in a working week. When you can draw mind from every aspect of your product, you get more time to focus on your data insights and other important things. Once everyone on your team is set up to have more time to focus, you get better vision and goal alignment.
That approach helped us build a product trusted by some of the world’s largest companies to upload, moderate, store, transform, and ultimately deliver content. We’ve described it in detail, but we understand it’s just a building block, that’s in our hearts and mindset 💛
We know developers love the challenge of building their own solutions from scratch. But when you turn on the empathy and design the best way to help your customers, the resource savings offered by APIs and platforms outweigh the intentions to craft every piece of your product.
Make sure your integration candidates won’t require much development resources to set up and maintain, are reliable, and will grow in the right direction.
Building your version of an API function might seem like a time saver, but it’s often a time mortgage, driving you slow and trading time in the short term that eventually needs to be paid off in the long run.