Using consulting to build a successful product

Many startups wrestle with the same question: should you offer services while building your product? We did. In fact, we leaned hard into it. This article explains why, how it helped us, and why we eventually had to pull back.

The Starting Point: The Illusion of Expertise

When we started Nango, we thought we knew integrations. We had built them in previous companies, felt the pain, and believed we understood the problem space. In reality, we had only seen a fraction of it.

Like many founders, we underestimated:

• The breadth of integration use cases across industries
• How different APIs really are in practice
• The operational challenges of delivering integrations at scale

Our core insight was that developers don’t want prebuilt black boxes, they need infrastructure and tooling. That turned out correct. But our early product was oversimplified. It couldn’t handle the flexibility developers needed. That gap forced us into a different approach.

Why We Chose to Offer Services

At first, we couldn’t get “inside the building.” Startups and mid-market companies were too busy to let outsiders into their workflows and codebases. Even offering to build integrations for free wasn’t attractive: the real cost wasn’t money, but time, risk, and subsidizing our inevitable early failures.

Things changed for three reasons:

1. Urgent customers: We found a small subset of customers with “house on fire” problems. They had a lower cost of failure and were willing to let us in.
2. A more credible product: By that point, we had iterated on the platform for a year. It still wasn’t polished, but it looked more legitimate, and that gave us some trust.
3. Proof of concepts: We put in significant upfront work to show we were serious and could tailor integrations directly to each customer’s business.

Together, these shifts opened doors. And once we got in, we took a Palantir-like approach: not just delivering a platform, but pairing it with a dedicated team that would build integrations side by side with customers. Most companies didn’t want to learn APIs anyway—they were happy to leave the job to experts.

At that point, the feedback loop exploded. Customers pinged us in real time about everything: launches, outages, API questions, new use cases. We went from outsiders to being at the very core of their product projects.

The Benefits of Service-Driven Learning

Going hands-on created advantages that a pure product approach could never have given us:

• Red carpet access: Customers treated us like teammates, not vendors. Getting into their systems felt like a privilege. It’s not easy to earn that kind of trust.
• Massive feedback: The feedback loop was immediate and constant. We didn’t just hear about problems, we lived them alongside customers.
• Hundreds of integrations: We built integrations across verticals, company sizes, and industries. This gave us an incredible map of the integration landscape: use cases, complexities, budgets, even managerial challenges.
• Deeper understanding: We saw firsthand how products structured data, how APIs failed in production, and how teams rolled out integrations to customers.
• Credibility: We weren’t theorizing. We had scars to show.

At the time, we believed this model would make us unavoidably the best in the market. If we were embedded in enough teams, working hand-in-hand on their hardest problems, we thought there was no way anyone could match our knowledge of integrations. And in many ways, that was true: those years gave us unmatched expertise.

The Downsides: When Services Hold You Back

But services came with costs we didn’t anticipate:

• Low leverage: Selling human time scales nothing like selling software.
• Operational drag: We were drowning in support, context sharing, and debugging. The team was constantly interrupted.
• Misaligned expectations: Customers undervalued the service because they underestimated integration difficulty. Efforts often went unrecognized.
• Lost ownership: Some customers stopped taking responsibility for their integration strategy, blaming us for things outside our control.

The deeper we went, the more context we had to absorb. Every integration required a detailed understanding of a customer’s business and product. That’s when we had a key realization: integrations are not an add-on. They are part of the core product.

This intensified our original insight. It wasn’t just that prebuilt integrations don’t work. Even external services can’t truly “own” integrations. They require product vision and ownership from inside the company itself.

The Transition Back to Product

Fortunately, all that embedded work paid off. By the time we realized the limits of services, our platform had grown strong enough to stand alone.

The shift looked like this:

• We told customers we’d scale back services. To our surprise, many were relieved. They didn’t want to over-share context or depend on us so heavily.
• Prospects started self-selecting into better-fit customers: teams who valued building high-quality integrations in-house.
• We realized we weren’t competing with prebuilt integration platforms. Those platforms were chasing the ~5–10% of companies willing to outsource integrations. We were focused on the 95% of teams building in-house.

That reframed Nango’s position: not an alternative to building in-house, but a better way to build in-house. Much like using React to build a website, you’re still building it, but with the right framework.

The Benefits of Pure Product

This shift radically simplified our operations and improved our lives:

• Radical PLG transition: Customers adopt through the product itself, not services.
• Higher leverage: Today, we serve hundreds of customers with just six people (though we’re growing).
• Simpler sales: Pricing is usage-based, and sales conversations focus primarily technical Q&A.
• Less support burden: Problems get fixed in the product and docs, not through ongoing consulting.
• Happier team: We focus on building interesting product problems instead of firefighting.

The leverage flip has been incredible. Instead of scaling humans, we scale software.

What Founders Can Learn

If you’re starting a product company, here’s the lesson:

1. Services can be a superpower, at first. They open doors, accelerate learning, and build trust.
2. But services will drag you down if you don’t evolve. They lower leverage and create unhealthy dynamics with customers.
3. The trick is timing. Use services as a takeoff mechanism, but know when to pivot back to product.

Our journey wasn’t intentional. We honestly believed we were building a hybrid product + service company for the long term. Only later did we realize the service was temporary scaffolding. But it was necessary scaffolding: without it, we could never have reached the level of expertise we have today.