Things I Wish I Knew Before Building My First Integration: Lessons From a Developer

Developer Hal Zeitlin shares the lessons he learned from building his first native integrations and shares tips for other first-time integration builders.
Written by
Lindsay Sayre, Director of Marketing
Published on
May 15, 2024

Is your company planning to build integrations soon? If so, stop what you’re doing and read this post to save yourself a lot of time and frustration.

We recently sat down with developer Hal Zeitlin to discuss his experience building his first product integration. Hal walked us through all the ups and downs of developing a native integration from scratch and shared the lessons he learned along the way. Plus some advice he would give to other devs starting down the path of building integrations for the first time.

Some Background

Before diving into the learnings, we need to set the stage for why Hal’s team started building integrations in the first place.

Several months ago, Hal noticed a pattern with his enterprise customers. They wanted to be able to send data from their websites into Salesforce. However, existing solutions were either too complex, reliant on third-party tools, or simply inadequate for upmarket customers. Instead, users wanted a native integration experience.

As a Webflow partner, Hal saw an opportunity to fill this gap. So, his team started building a native Webflow to Salesforce integration.

The project ended up taking longer and being more complicated than Hal expected. But he learned a ton along the way that he wanted to pass on to other developers tackling integration development from scratch for the first time. 

The good news is that even though it was a difficult project, knowing what he knows now, Hal says he “still would have definitely taken it on because I believe in the strategy. I believe in this opportunity.”

So, without further ado, here are the top things Hal wishes he would have known before building his first integration.

Things Developers Need to Know Before Building an Integration for the First Time

Integrations Take Longer Than You Think

According to Hal, the number one thing he wishes he knew was that “building our first integration was going to take a lot longer than I expected and to be okay with that. Building integrations is not a casual project that you just take on. It needs to be taken as seriously as building your core product. And that means really building out proper specs and timelines and tracking them.”

This can be difficult to do during your first integration project because you might not be familiar with the tools and technology necessary for building. And you don’t have a benchmark for how long integration projects typically take. Plus, you need to learn new APIs, and oftentimes (like Hal’s team faced with Salesforce), those APIs can be very complex.

Be sure to allocate generous timelines and prepare for a steep learning curve. Leave yourself extra time as a buffer to address unknowns that will inevitably come up. Remember that integration development is a marathon, not a sprint.

Resource Allocation is Key

You shouldn’t think of building integrations as a side project. Hal says, “You really want to dedicate quality developer time to this instead of having it fill in the gaps when other projects are paused.”

Quality development time is non-negotiable. This task demands dedicated, skilled developers who are given time to focus on it. It can’t just be squeezed in "when time allows." It's essential to prioritize integration projects appropriately.

Be Prepared to Hit Roadblocks

As you dive into integration development, expect to hit roadblocks. In Hal’s case, authentication posed the biggest challenge. He said, “When you're working with authenticating a lot of different tools, having an infrastructure to store them safely takes a lot of time and research. I literally ended up hiring two consultants for this project to try to get all that right.”

If you don’t want to spend a ton of time troubleshooting yourself or having to hire consultants, Hal’s advice was to consider using a tool like Pandium to help.

“I think [Pandium] is great because it solves that out of the box. Users don't need to hire a consultant. Not only do you have the critical details documented, but also it's built in a way that a literate, experienced developer can pick up and get building.”

Embrace Product Management

Hal says, “You have to think of this like you’re building a product. If you want a smooth end-user experience (i.e. you don't want to frustrate your customers), you should have a product manager on the project. The risk of building a half-baked "almost helpful" integration is real. We've all seen those integrations before!”

Even if you have great developers, if they’ve never built an integration before, there will be a steep learning curve. You need someone acting as a product manager to hone in, push things along, and allocate time to finding and resolving issues.

“The more senior your product managers are and the more self-driven your developers are, I would chart a direct relationship to a greater success velocity and fewer bugs you're going to have when you're building out all these vast integrations,” said Hal.

You Need to Have Skilled Developers

Hal said, “I wish I had allocated more of my senior developer resources earlier on in the project. That would have been quicker and more effective.

Your more senior developer leading the integration project should ideally be very experienced with the tech stack required for your integration. I know it sounds obvious, but it's worth saying!

For example, we had one developer who moved very quickly in building out the APIs for the Webflow Designer, but leading the backend portion would have taken more time if he was placed in that role.”

Many companies think building integrations from scratch is work that any junior developer can do. Unfortunately, that's generally not the case unless you leverage a tool like Pandium to reduce complexity. 

“For Salesforce, for instance, there's all these different objects, the way they're related, so many edge cases come up. But you can't just throw in the towel when you have a challenge or make a mistake. You have to be able to troubleshoot it and fix it.

And when you don't have a tool like Pandium, you kind of have to self-discover roadblocks. And you just have to allocate a lot of extra time to discover those,” said Hal.

Hitting roadblocks and finding workarounds requires a more skilled developer. Even though that might be more expensive per hour, it's still the best choice because problems get solved quicker, and you save time on the overall project.

Build the Right Foundation

After some trial and error, Hal found a formula that worked. Use senior developers to build solid foundations for integrations, then tap in more junior devs to update and maintain things later.

“I would suggest having your more trusted developers build out the early parts of your integrations. The foundation, have them own that. And then, deploy more junior development talent on top of that foundation once it's already established.”

Hal said this is the framework he’ll use for all integration moving forward.

Prioritize Wisely

Not all integrations are created equal. It’s essential to look at your company’s growth and channel strategies to determine which integrations will have the highest impact. 

Quality Over Quantity

Consider prioritizing quality over quantity when selecting the integrations you develop. Especially during the early phases of your tech partner program. 

Rather than aiming to develop hundreds of integrations, focus on the critical ones that meet customers' needs, address primary use cases, and connect to the tools they use in their day-to-day. 

This approach will guarantee that your development efforts are genuinely valuable to your customers instead of merely expanding the collection of logos on your landing page.

Consider Complexity

It’s also vital to consider complexity. Hal suggested companies rate the integrations they want to build “by difficulty and complexity.”

“Some integrations are way more challenging and expensive to solve than others. Like Salesforce Objects vs. HubSpot Lists. Salesforce's data model for mapping form data into objects is much more complex than a more 1:1 HubSpot forms API integration.” said Hal.

Assess how doable or practical building an integration is by looking at the ease of mapping between the two applications you're trying to connect. Also, determine if they are legacy or API systems. 

Assessing technical compatibility upfront will help identify potential issues with integrating and long-term maintenance.  

Consider Timing

Time to build is also a significant factor to consider. Hal said his team “Spun up the V1 Slack and Airtable connections pretty quickly. That was a streamlined thing to do. But Salesforce has been a way bigger lift.”

Pick a deadline for when you’d like to launch your first integration, and then work backward to identify which integration(s) you can realistically finish in that timeframe.

Commit Fully or Not at All

It’s essential to do proper research and planning to decide if building integrations is the right move for your company. But once you decide that it is, Hal says to go all in. “If you ​​believe that these integrations are a key play, then take it seriously. Don’t do it half-heartedly.”

If you’re going to commit time, energy, and resources to an integration project, make sure the leaders and teams in your organization are aligned. It’s not the type of project you can start and stop. Or the kind of project you want to drag out due to shifting priorities. 

Prioritize it, then go full steam ahead.

The Fastest Time to Market is How You Win

Hal believes building integrations gives some companies “an unfair advantage right now.”

Whether you’re a legacy player looking to keep your stronghold on the market, a high-growth player looking to overtake the incumbent, or a niche player trying to carve out your corner of the market, you need to consider how competitive your integration strategy is. 

“There are certain ways to compete that are more powerful than others. And for some companies, an integration strategy at the right point in time can be a very powerful place to invest and compete. You need to find the most efficient way to get live and claim market share,” said Hal.

That’s where a tool like Pandium can come in and help. It streamlines so much of the process that engineering work is reduced by 70%, and you can get integrations to market up to 6x faster.

Parting Words for Developers

If you're trying to grow and want to be a leader in your company for your integrations, you need to be adequately equipped. Have a framework and understand different kinds of integrations. Which ones are easier, quicker, tricker?  

Which ones are going to provide more ROI and growth? As Hal says, “That level of strategy is really important for validating and earning an ROI on building integrations.”

And if you need support at any stage in your integration journey, from planning to building to go-to-market strategy, Pandium is here to help. It might be your first rodeo with integrations, but it's definitely not ours.

Pandium newsletter
No spam. Just the latest releases and tips, interesting articles, and exclusive interviews in your inbox every month.
Read about our privacy policy.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Latest

From the Blog

Check out our latest content on technology partnerships, integration and APIs. Access research, resources, and advice from industry experts.

Introducing the Pandium CLI: Further Streamlining Local Integration Development

Our new CLI enables even faster integration development with the Pandium platform. Now, customers can build, deploy, and manage integrations directly from the command line.

Native vs Third Party Integrations for B2B SaaS Customers: Examining the Benefits and Drawbacks

Discover the benefits of native and third-party integrations for B2B SaaS. Learn how they add value to a B2B SaaS business and what to consider when implementing them.