Blog
Why you shouldn't be your own ICP (we aren't)

Why you shouldn't be your own ICP (we aren't)

After YC, we languished in “pivot hell.” After building the wrong product for the wrong people, investors snubbed us for our next round. 
We started looking for our next idea in all the wrong places. We looked at the hottest topics. We considered building in web3, neobanks, ecommerce... you name a trendy category, we considered it. 

We shouldn't have looked there. We should've looked at our own resumes. 

How the "secrets" of our corporate jobs helped us know what to build

Peter Thiel defines “secrets” as big, underestimated problems that look solved, but aren’t. Secrets often birth  category-defining categories. Think about Salesforce pioneering SaaS: Selling software seemed solved. You sold a license to your product, went back into development until the next version was ready and sell it again. Salesforce realized you could make more money by charging monthly and always keeping the software up to date.

These types of secrets usually aren't in classified briefings, but in lived experience from the founders. That’s how we found the idea for Lago (or, rather, the one that worked).

We were the founding team of a $5B fintech called Qonto (the Brex of Europe). Billing was such a mess that it became our biggest internal tooling team. We had to divert engineers from our core banking product to maintain our homegrown billing system. It became a bottleneck anytime we wanted to launch new pricing. We wasted engineering talent  on billing, not product.

That was our secret: Most billing solutions are  glorified PDF generators. When pricing gets complex, companies build everything in-house and only send the final data to the billing system, which just issues an invoice.

This secret let us exit pivot hell. But to get there, we had to dispense with a piece of startup advice.

Why you don't need to be your own ICP

If you saw the CEO of Toyota drive a BMW, you'd probably trust Toyota a lot less. The same applies to software. If Amazon used Google for cloud services, you'd stop trusting AWS. So a lot of startup advice dictates you should be your own best user. It’s meant to stop founders from building things nobody needs (tokenized whitelabel petsitting marketplace, anyone?). But if you only build for your current self, you’re limiting your market to early-stage startups.

That means you can't sell to bigger businesses that can pay you more and need you more. 

Take Lago. We solve complex billing. If you want to charge $10/user/month, using Lago is like using a flamethrower to light a cigarette. But as a horizontal platform, we support:

  • Real-time metering: AI companies, telcos, and utilities measure usage by the second.
  • Multiple products: More pricing models, bundles, and entitlements.
  • Layered go-to-market: Self-serve and enterprise sales.
  • Multi-geo pricing & compliance: Different laws, taxes and pricing strategies per country/region.
  • Millions of users with historical plans: Maintaining legacy pricing at scale.
  • Complex workflows: Reselling, embedding, and partner billing.

This is our differentiation: All the billing features nobody wants to build and maintain, we've built and continue to maintain—and do it in a way builders like (open-source). That's despite not using much of that ourselves (yet). Our own monetization is straightforward in comparison. And so is most startups'.

We actually disqualify many prospects that are too early-stage and which don't yet need complex billing. We could sell them Lago for simple subscription billing, but they're better off with a simple solution. 80% of the companies with these complex billing use cases are mid-market to enterprise. Had we taken the classic "Build for yourself" advice, we would've gone the  route of selling to tiny startups, then to slightly bigger startups and eventually graduated to mid-market and enterprise. But if your product is mainly useful to mid-market and enterprise, you shouldn't be a power user of your own product. That doesn't mean you should just build stuff you don't understand.

You don’t need to be your ICP, but you need to understand them

We were the ICP at Qonto. So we know the problem space well. So while you don't need to be your own best customer, you do need to know the problem first-hand. And you should want to be your own best user. So of course we do use Lago for our own billing, though we’re not our ICP:

  • We meter usage, but we don’t need real-time billing.
  • We only have one product.
  • Our pricing is simple.
  • We don’t have millions of customers (yet).

This approach isn’t new. Auth0 (acquired for $6.5B) built authentication software for enterprise—even though tiny startups don’t have tricky auth problems. They knew authentication was a nightmare at Microsoft, so they solved that problem for companies that did need authentication now.

Turning your previous job into a startup idea

We flirted with so many ideas that seemed cool and trendy. The one that worked was the most dry: Billing. That's not a coincidence. The point of a secret is that it's hidden—NOT something that you see in "top 10 startup ideas" lists. If you insist on building things you yourself need, you’ll miss billion-dollar opportunities. The best startup ideas come from problems big companies could solve but don’t.That's why great founders often solve the problems they’ve seen firsthand. The key is to step back and ask:

  • What took months to build that should have taken days?
  • What problems kept resurfacing, yet no one fixed them?
  • What internal tools were so critical they needed a full team just to maintain?

These are the "secrets" that fuel most great tech successes. Stop looking into Google Trends for startup ideas and start looking into your own experience.

Focus on building, not billing

Whether you choose premium or host the open-source version, you'll never worry about billing again.

Lago Premium

The optimal solution for teams with control and flexibility.

lago-cloud-version

Lago Open Source

The optimal solution for small projects.

lago-open-source-version