Building Integrations at Early-Stage Startups

Integrations should be prioritized

You need to stop thinking of integrations as a distraction from your core product. Yes you need to build great features that will delight your customers and solve their problems, but you also need to treat integrations as features that need to be prioritized like every other feature of your product. Companies that fail to prioritize integrations are planning to fail. 

‍

‍

The next step is to figure out where on the priority list they should fall. 

As an early-stage startup, you may not have detailed analytics yet on deals lost because you don’t have integrations, but you can determine what integrations will be crucial for your early success through interviews with potential customers, any existing customers, as well as competitor analysis. Speak with potential customers about the tools they are using today, and what they would likely need from an integration in order to adopt your product. The stronger your understanding of real-world use cases is, the less likely you are to build an integration that doesn’t support your revenue goals. 

You can also wait until you have revenue on the table from customers to build the integrations. As a small company you have the advantage of being nimble, being able to build new features (and integrations!) as they’re needed by customers. If your company has a sales-led model, you can use your sales conversations to discover what integrations would need to be built for your first 5-10 customers. If you’re operating under a product-led model, with a freemium or low-cost entry product, you can still offer integrations as a higher-level add-on that needs to be requested from you. Building on request helps to ensure that you don’t waste time or resources on integrations that don’t provide ROI. 

Once you’ve decided which integrations you need to build and when, the question becomes how can I build them as fast as possible and as cheaply as possible. After all, startups have limited funds and a pressing need to move fast. At this stage you have a couple of options: 

• Build yourself using the same developers that build your core product 
• Outsource to an external dev shop 
• Buy a tool that could help do the heavy lifting (eg. an iPaaS or a unified API) 

At Pandium, we always recommend building it yourself (with internal or outsourced devs) at first. Here’s why: 

Product Maturity: In the early stages of your startup, when your product is still evolving and your customer base is small, it's crucial to maintain a hands-on approach to integrations. Your own product may lack a mature API, and you might not fully understand customer behavior or integration requirements due to limited adoption. At this point, direct database connections or simple in-house solutions are often the most practical approach. Staying close to your own technology stack is vital, as outsourcing or relying on customer-built integrations can distance you from critical insights and flexibility. Your product may undergo substantial changes, potentially necessitating complete rebuilds of integrations. 

Reduced Flexibility: Introducing low-code tools or platforms at this stage can introduce unexpected rigidity and limitations, reducing your ability to pivot quickly. The time invested in learning and adapting to these tools might outweigh their benefits for a small number of integrations. It's important to recognize that for some startups, particularly in sectors like retail, integrations aren't just add-ons but core product features – for instance, a retail management system that doesn't integrate with Shopify might have limited value. Therefore, maintaining direct control over your integration strategy in the early stages allows for greater agility, deeper understanding of your product's needs, and the ability to rapidly adapt to changing customer requirements.

You might also consider: 

• Time: Building a handful of integrations for a small number of customers isn’t that time consuming. The time you would spend researching and learning how to use an iPaaS or unified API makes the time saving from implementing one not that significant. Remember these tools are often low-code, drag and drop platforms which have their own learning curve - and devs usually hate working with them. 
• Cost: These tools will cost you something, but again the cost compared to having a dev work on it is not so great. Especially when coupled with the time point above, the cost vs. time savings usually doesn’t work out to be that significant. 
• Vendor Lock-In: With most iPaaS and unified API tools, you don’t own your code. That means if you do start to have success with your integration usage, but run into issues with the platform you’re using (eg. costs increasing too much, lack of support for your API etc), then you’re facing the prospect of having to completely rebuild your integrations in another platform. 
• Lack of Support: iPaaS and unified API tools work by having pre-built connectors for a set of APIs. This can limit you in a couple of ways. First, as you don’t have direct access to the API, you may not have the ability to leverage all the capabilities of the API. Second, if an API is updated, or you want to use an API that they don’t currently have a connector for, then you are beholden to the iPaaS or unified API company to make the update. As a small startup, your influence over the iPaaS/unified API company is usually pretty limited, so don’t expect that your requests for updates will be acted on unless it’s requested by other customers. 

So when should you look to an iPaaS or unified API to help build your integrations? 

Once you’ve started to see traction with both your company, and your integrations you may start to notice that the infrastructure required to maintain your integrations becomes burdensome. You may also run into issues scaling as the number of customers using your integrations grows. This is a great time to look for an embedded iPaaS solution that can help do the heavy lifting. Some key signs that it might be time to bring in an embedded iPaaS are: 

• Updating and maintaining integrations becomes very time consuming - especially if you’re trying to keep up with API changes across multiple APIs. 
• Auth connections are challenging across the many customers using your integrations. 
• You need to release a much higher level of new integrations - and it’s taking too long for your internal teams to do that. 

If you’re starting to experience any of these problems, it could be a good idea to look at what options are available to help alleviate these scaling issues. For a deeper dive into the options available, read our guide on the best embedded iPaaS solutions. 

You may wonder if the problems mentioned above are still an issue once you’re ready to implement an iPaaS. In many cases, the answer is yes. Many of these iPaaS and unified API tools are built on a low-code foundation. Having a low-code foundation limits the effectiveness of your integration platform, and unless you choose a tool that doesn’t follow this model, you will undoubtedly run into issues mentioned above and more. You can dive deeper into the limitations of low-code tools in this blog post. 

At Pandium, we believe in a code-first approach. Leveraging a platform with a code-first approach allows you to realize the benefits of having your integration infrastructure managed for you, while still keeping the flexibility benefits that come with being able to write (and own!) your own code. 

‍