Lessons learned from building an infrastructure devtool

Three years ago, we started Nango: Developer infrastructure for product integrations.

Today, it powers integrations with 500+ APIs for hundreds of SaaS and AI companies.

Our journey to get here was anything but linear.

For this post we gathered some of our most unexpected lessons learned. We hope they help other teams who are also building developer infrastructure products.

1. Great abstractions are the key to great infrastructure products

As developer infrastructure, our abstractions are our product.

For instance, the interface we choose to let your app authenticate with 500+ APIs defines what we handle, the available configuration options, and how you can integrate this feature in your own application. Different abstractions lead to very different experiences.

For Nango, our abstractions must be powerful enough to solve a real problem end-to-end, yet flexible enough to accommodate diverse use cases, external APIs, and tech stacks.

In our experience, when you get the abstractions right, everything else falls into place: Tools fit like a glove, APIs make intuitive sense, and configuration options cover exactly what customers want to tune.

Building great abstractions has an element of craft, and you can see it in the tools engineers love: Linear for project management, Vercel for running apps, Supabase for full-stack products, Knock for notifications, Resend for emails, and Infisical for secrets management.

I don't think this is a coincidence. Deep domain expertise and best practices help create abstractions that truly fit. But the final touches, such as great API design, intuitive property names, and just the right amount of configuration, are more art than science.

2. To build great abstractions, you need deep expertise

Infrastructure is the foundation others build on. If you're not truly an expert in your space, users feel it immediately: abstractions are off, "obvious" features are missing, and support lacks depth.

When we started Nango, we had already built dozens of integrations for previous products. We believed we were experts, but in reality, we were probably only at an intermediate level. It took thousands of hours working in production across many different use cases for us to become true experts.

We were fortunate that customers asked us to handle more of their integration challenges. We formed an "integrations engineering" team and built hundreds of integrations for them. Although this approach was difficult to scale, it gave us direct experience with what it really takes to build great integrations. We shared what we learned from this period here.

Without this intense dogfooding, we might never have learned the deep insights needed to build truly helpful integrations infrastructure.

3. For some problems, lower level is better

We started with a high-level solution: "Outsource the problem of integrations to us, and we'll solve it end-to-end."

But while developing hundreds of integrations for customers, we realized this approach was flawed. Integrations are key product features. You can't bolt them on and magically sync whatever customers need with any external API. For integrations to succeed, each interaction must solve a clear end-user problem and fit with existing product features.

The more we abstracted integrations, the less control customers had, and the lower their success rate. For integrations, we learned that lower level is better, even if it means we can't solve as much of the problem for them.

At first, this was counterintuitive. But I think it applies to many infrastructure devtools: for some problems, control is more important than an end-to-end solution.

4. Getting the abstractions right matters more than speed

Common wisdom is to ship as fast as you can to learn in production. This assumes change is cheap, which is true for many products, but not for developer infrastructure that customers rely on for production traffic.

In our experience, taking 50% more time to get the abstractions right has paid huge dividends in speed down the line:

• Less rework of previous features = fewer breaking changes
• Good abstractions = solid foundations for future features to build on top
• Good abstractions = better intuitive understanding by customers = less support overhead

5. The path to product-market fit is not linear

Startup journeys are often presented as linear paths from start to success. But most products aren't born into PMF. They go through turbulent iteration periods where progress is more spurious than linear.

Nango was no exception. We went through at least 5 major iterations to reach our current product.

Each iteration led to acceleration as we unlocked deeper understanding, a wider customer base, and an improved product. But after a while, we'd hit slowdowns as if we'd hit an invisible tarpit. Or even a wall.

We learned not to get attached to any product iteration, but to stay focused on the problem. Which parts resonated with customers? What caused friction? Is there an approach we haven't tried?

It's hard to know if some iterations could have been avoided. In hindsight, breaking points seem obvious, and it feels like we could have been faster to detect them.

But ultimately, the only thing that mattered was not giving up. Through our iterations, we kept accruing deeper expertise about how integrations truly work across hundreds of B2B software products.

I think these insights were crucial for us to build the product we have today.

Conclusion

When we started Nango, none of the Nango founders had ever built an infrastructure devtool. Every blog post and lesson learned from others was helpful for us.

Luckily, the infrastructure devtools community is very open about sharing learnings, wins and failures. I hope this post helps others learn from our own journey.

P.s. We are hiring backend engineers.