Building a developer infrastructure team

Nango is a developer infrastructure company for product integrations. We are about three years old, went through YC W23, and today we are a team of seven serving hundreds of companies. This article shares how we approached building our team. It is only one story, not a playbook, but we hope it’s useful as a data point.

Startup basics still apply (sometimes even more for infra)

Developer infrastructure tempts you to break the usual startup rules. The systems are complex, scale happens faster, the users are engineers who notice gaps, and the expectations for reliability and security are high. It’s easy to believe you need a big team, a lot of capital, and a polished product before you can even get started.

In our case, we discovered that the basics still applied. We did things that didn’t scale, we stayed scrappy, and we started small.

When we launched on Hackernews, we only had an open source repo and faked a cloud offering: users would signup on a Typeform, then we would manually spin up a Render server & database for each, and email back an API key to our user (yikes!). The launch went well and in 24h we had about 200 VMs running on Render. Their CEO eventually reached out to us about it. It was fragile, but it worked long enough to show traction.

Our codebase was shaky, often with no tests, and we shipped features before they were fully ready to test appetite. The customers who gave us a chance early on were usually smaller startups, sometimes people who had felt the pain of building integrations themselves. They believed in the vision even when the product wasn’t polished. The bar was not to build a great product, but to build something better than what they were going to build in-house.

We also learned to narrow scope. Early versions of the product tried to do too much and weren’t polished enough. Pulling back and focusing on smaller pieces helped us iterate faster. One trick was offering lower-level primitives rather than full abstractions. For example, we let developers write their own integration code in their IDEs and deploy it to Nango. That gave them flexibility and let us not have to build our own online editor, AI co-pilot, etc.

Looking back, we didn’t always follow these rules intentionally, sometimes we were just forced into them by circumstance. But it turned out that the basics of staying scrappy and narrow worked, even for infra.

Innovation comes from the front lines, so hiring quality is everything

Once we had some traction, hiring became the biggest lever. Our first engineers were generalists who could move fast and live with the uncertainty of early-stage product work. Later, we shifted toward what we called "platform engineers".

These were T-shaped engineers, but with both axes extended: wide exposure across many systems and deep expertise in at least one. They often had 15+ years of experience, with time spent in both startups and larger companies. That mix mattered. Startups taught them ownership and speed; scale-ups taught them scalability, reliability, and how to anticipate long-term needs.

Our first two platform hires made this clear. One had built the custom ingestion pipeline at Algolia, the other came from Netlify, both experiences being very relevant to running untrusted customer code like Nango is doing. Both had also been through smaller startups earlier in their careers. They brought with them a combination of foresight, practical scars, and empathy for developers that we could not have replicated internally.

Why does this matter so much in developer infrastructure? Because developers are building for themselves. They are both the builders and the users. That creates opportunities for dogfooding, empathy, and autonomy. It also means that the best ideas tend to come from the engineers closest to the work, not from management or PMs.

One concrete example: for a long time, our integration configurations were defined in YAML. An engineer proposed migrating this to a full TypeScript interface, with proper model types, linting, and editor suggestions. It was a big project, but it improved the product in ways a top-down plan never would have captured. That kind of innovation came from the front lines and made a true difference in the developer experience.

We realized the management challenge wasn’t to direct every detail, but to build conditions where engineers had the context and trust to make these kinds of decisions. That raised the bar for hiring, but also made the case for keeping the team small and selective.

Remote-first hiring was essential for this: by looking across the US, Europe, and LATAM, we widened the pool enough to be very selective.

It is possible to stay lean

Infrastructure is often assumed to require large teams and big funding. Our experience so far suggests it doesn’t always. With seven people, including four platform engineers, one solutions engineer, and two founders not coding, we’ve been able to support hundreds of companies and 7-figure ARR.

We don’t have a dedicated go-to-market team. Founders still handle sales, and all engineers do support. That works because adoption is product-led: we don’t do outbound (anymore), about 20 percent of users come from word of mouth, more than 50 percent from search, and even large customers often start self-serve.

Velocity for us hasn’t come from a hard-core culture. It has come from making the right infrastructure decisions, which avoid repeated multi-month migrations. For example, we adopted Temporal for orchestration, then switched to an in-house Postgres-based scheduler, which was a two-month transition but has been running reliably for over a year and a half. Similar stories repeated with our runtime, customer-facing logs, data syncing engine, etc.

Each time, thoughtful decisions extended the life of the system. That’s what velocity looks like for us: fewer big rewrites, more durable systems, less incidents. And that’s only possible with a small team of high-context engineers who can take the time to get it right.

In truth, we expected we would need more engineers, more operation hires, and more capital by now. Instead, we found that staying lean has been a strength. It forced focus, kept communication simple, and let us be extremely selective about who joined.

Takeaways

Looking back, our main learnings were:

• Startup basics still apply, sometimes even more in infra. The temptation to scale early is strong, but staying scrappy and narrow paid off.
• Innovation comes from the front lines, so hiring quality is everything. Developers building for developers make the most important decisions. The job of management is to create the conditions for that to happen.
• It is possible to stay lean. A small, selective team can go a long way, even in developer infrastructure.

We’re often hiring staff-level backend engineers. If this way of working resonates, you can find open roles on our careers page.