Now Reading
Lago Weblog – Publish-mortem of our 1st YC startup: a Reverse ETL

Lago Weblog – Publish-mortem of our 1st YC startup: a Reverse ETL

2023-01-22 03:53:31

TL;DR: We thought we had made one thing individuals needed. Our first startup was truly a vitamin. 


After writing about our pivot (part 1 and part 2), we had dozens of founders contacting us, asking for extra particulars. A number of them have been working or contemplating transferring within the “Reverse ETL house”. We thought writing an in-depth autopsy can be a scalable technique to share our learnings. 

We joined YC in June 2021 (S21) pitching a “no-code information instrument for progress groups, to section and sync buyer information” (see our software here). We had no product on the time, we shipped in the course of the batch and began monetizing a number of weeks later. 

We ended up exhausting pivoting from this house six months later.

The group at Lago began rebuilding our new product: an open-source metering and usage-based billing API six months in the past. And we now have no intention to sundown this new product, this time. Though it’s technically the identical firm and the identical title (we prefer to say we’re “Lago v2” now), the educational curve and the vary of feelings was so intense, we really feel as if Lago v2 is our second startup. 

So.. what went incorrect with our 1st endeavor ? How is Lago v2 completely different?

What went incorrect

We missed key components in the course of the consumer analysis

We interviewed 130+ progress entrepreneurs, and shortly gathered a ready record of 1000+ progress of us who mentioned they needed extra “autonomy” to handle information. 

After we confirmed the product to them, and its advantages, they LOVED it. “Precisely what I needed” was a standard verbatim. That’s why we have been stunned to see how exhausting it was for them to truly undertake the product. And right here comes the important thing level we missed. 

We thought their “blocker” was that they didn’t know SQL and couldn’t question their database or their information warehouse.

We have been incorrect. 

Progress entrepreneurs needed extra autonomy to handle their information, however weren’t essentially keen to place the additional effort into: (i) understanding the construction of a database (dozens of tables), (ii) apply light-weight information modeling. 

Most of them weren’t that comfy with spreadsheets, pivot tables, vlookups, recordsdata with hundreds of rows and dozens of sheets. 

That’s what killed our consumer adoption. We recognized the issue, however our answer wasn’t answering it effectively sufficient. 

Might or not it’s answered by software program? I nonetheless marvel.

To summarize, we listened (too) “actually” to interviewees and assumed that “SQL literacy” prevented progress groups from accessing the information they wanted. The reality is what prevents them is a mixture between “information literacy” (information ideas, and the way the information is collected and saved inside every firm) and “urge for food to ramp up on information”. 

That’s why most firms find yourself hiring “mid-tech” groups (enterprise operations managers, analytics managers, who usually have an engineering varnish or background) to serve progress groups with information.

We projected an excessive amount of from our previous expertise

We had a technical progress group at Qonto (our earlier firm, a Fintech unicorn, that means the expansion group had their very own engineering group, utterly separate from the core engineering group). On high of that, the connection with the core engineering group was easy. This setup may be very uncommon.

Certainly, most progress groups we related with didn’t have their very own engineering group (therefore the worth of the no-code instrument we have been constructing). As well as, we additionally found that the engineering group is mostly very suspicious of progress of us approaching the information warehouse or the database. 

We don’t actually know if it’s a hen or egg downside, however because of this, these progress groups didn’t have the information data, nor the permissions to learn the database, or create replicas, and it ended up making the adoption very tough.

With Lago v1 (the no-code information instrument for progress groups), we’d usually have excited progress groups keen to make use of our product, whereas the CTO dragged their toes to assist the implementation: by lack of time/prioritization, or as a result of they believed the expansion group would mess up with the information, or create the incorrect automations/segmentations by lack of knowledge literacy. And we may actually relate to that.

As soon as once more, what I imply by “information literacy” is “what’s saved through which information desk”, and “how these tables relate to one another”. 

As an illustration, even with our no-code instrument, if you happen to needed the “rely of transactions” per consumer, you might need to determine 3 information tables inside dozens after which be a part of them (with out utilizing SQL, however nonetheless with a “vlookup” or “be a part of” idea in thoughts). 

We’ve seen few progress groups able to this, and once they have been, they might already be SQL proficient, or go for a “information engineering instrument” like Hightouch, Census, or dbt. 

To summarize, we constructed Lago v1 because the product we’d have beloved to make use of at Qonto, however our group was too particular (engineers reporting to the VP Progress, nice relationship between the VP Progress & VP Engineering), aka the market was too small.

We ignored the macro development

We seen the “trendy information stack” as a pure advertising and marketing idea (extra particulars here). We underestimated it, large time (sure, it sounds dumb, however every little thing will all the time look apparent in hindsight). 

It’s positively a well-marketed idea, nevertheless it additionally mirrored a greater than strong development: utilizing an information warehouse as the primary repository of knowledge inside an organization and hiring information engineers had already develop into mainstream. 

On this context, the groups that represented the biggest and booming market have been information engineering groups. These groups had extra exact use instances than progress groups, and in contrast to progress groups, that they had direct entry to the information warehouse and the database, and the belief from the CTO. 

Even worse, we shortly realized that “early-stage firms” would not often have the necessity for a complicated information instrument, as their progress groups – when there was one – primarily targeted on consumer acquisition; whereas later stage firms would rent an information engineering group that may all the time choose a devtool. 

We nonetheless managed to promote Lago v1, however we did so with the uncomfortable feeling that our shoppers would outgrow us shortly. We felt like a HR instrument for founders who don’t have a Head of Expertise but: light-weight, simple, generalist. We knew that as quickly because the “actual chief” would are available, our product can be one of many first to get replaced. 

To summarize, we constructed for the incorrect group, as a result of we have been enthusiastic about bringing information to the expansion groups, and  as a result of we missed the macro traits. In consequence, we had a low product adoption price, our “Annual Contract Worth” was capped (early stage firms) and our market was too small (progress groups which can be data-aware, however not too mature both).

What strategy may have been profitable?

It turned clear on the finish of 2021 that we should always have picked one other lane. We then evaluated many alleys.

Here’s a shortlist:

  1. A developer-first strategy like Hightouch or Airbyte (which acquired Grouparoo, an open-source reverse ETL). They’re additionally including options for non-technical customers, however began with a developer-first angle.
  2. Beginning with the enterprise instrument focuses on fixing enterprise wants, not information wants. As an illustration,’s authentic idea was a “messaging instrument”. They began with emails, then SMS and notifications, then added “workflow options”, and lately added information options. 
  3. The Product Led Progress CRM play. To be fairly direct, we spent fairly a little bit of time exploring this house, nevertheless it’s nonetheless unclear to me the way it suits into the corporate’s stack, between a gross sales CRM, a reverse ETL, and so on, as said here. The house is tremendous interesting although and attracted proficient groups and lots of funding, so we’re genuinely curious to see the way it evolves. 
  4. A verticalized play. Being the information instrument for a really particular trade, with very particular wants, just like the well being trade, monetary companies, or public companies. We’ve seen this strategy play out with Veeva (CRM for biotech/pharmaceutical firms), nCino (comparable for the monetary companies trade), Mattermost (a Slack different which had an amazing adoption inside authorities businesses). The principle concept is to select an trade with very particular wants, and be the one participant who went all-in in addressing these wants. This creates defensibility and contributes to decrease the price of consumer acquisition.

We didn’t select any of the choices above. There are numerous causes, however the backside line is that our group wasn’t excited by it (extra to it beneath).

After lots of backwards and forwards on a dozen concepts (it’s known as “pivot hell” for a purpose), just one actually clicked, as in “why didn’t we construct this within the first place?”. 

That’s how “Lago v2” was born: Open Source Metering and Usage Based Billing.

At Qonto, we had constructed and scaled the home-grown billing system from scratch and scaled it to collection D. The three back-end engineers who’ve led this on the tech aspect had joined Lago’s founding group, and we re-explored the explanations it was such a painful subject in our earlier firm. As the previous VP Progress (I owned Income), I keep in mind being very pissed off and restricted by the pricing iterations I needed to implement, and the information I needed to extract or ship from our billing system. The billing system is admittedly the golden goose by way of information: it gathers utilization information, how a lot the customers paid vs utilization, how this modified over time. 

At Qonto, we saved hiring back-end engineers to keep up our home-grown billing system as we grew, and it turned more and more advanced with time.

It was initially scoped to be a three-month one-person and one-time undertaking. The fact is {that a} dozen individuals are engaged on it full-time immediately. We had tried to make use of a third-party platform many instances, however every time we evaluated distributors, we thought their answer didn’t cowl sufficient of our edge instances to justify the migration. 

Understanding that, and having learnt from our first failed product, this time we made certain our challenges weren’t particular to Qonto, and went deep into “why firms proceed to construct a home-grown billing system, whereas billing is a nightmare for engineers”. 

We additionally revealed a simple blog post about “billing nightmares”, which utterly blew up on Hacker Information, and stayed #1 throughout 48 hours (777 factors).

See Also

This time, we additionally put lots of thought into what “answer” to this huge downside would work (once more, studying from our first failed product), and that is how we cast a deep conviction about being open supply (extra on this here).

Six months in, how is it completely different with Lago v2 (billing)?

We frequently get the query “how and when have you learnt it’s the suitable concept?”. 

I’m unsure there’s an absolute reply to this. Some firms had an preliminary product market match, after which misplaced it, as a result of they didn’t adapt quick sufficient. So.. it relies upon.

However in our very private case, here’s what occurred. We opened our Github repository round 6 months in the past. We haven’t relaunched formally but, however Lago v2 already had a traction we by no means had with Lago v1: 

  • We’ve constructed a neighborhood of believers, topping 1500 github stars on our repo.
  • Now we have discovered firms keen to pay 5-figure contracts for Lago 
  • Our open supply and composable strategy made sense to progress firms. The CTO of a collection C firm (with 5 million customers) selected Lago precisely for this angle, enabling his group to completely customise our software, and to proceed to a progressive migration. 
  • … and above all we saved having lots of enjoyable constructing this product, as a group.

It’s solely the start, however this actually is completely different from our first try: the market pull is stronger, and the match with our strategy is incomparable.

It appears easy put in bullet factors, nevertheless it actually was not. I simply wish to emphasize this if founders who’re pivoting are studying. 

Placing your first product within the trash, after which rebuilding from zero, with the urgency to ship asap, and no assure of success is horrible in your psychological well being. It’s a part of what we signed up for, as founders, nevertheless it’s robust. Particularly if in case you have batchmates who discovered Product Market Match straightaway, the comparability could be daunting. The strain from buyers may be robust as effectively. You may really feel responsible in direction of your group as effectively, whether or not it’s rational or not. It’s messy.

In regards to the “should-haves” (aka self-inflicted torture)

I used to torture myself with lots of “I ought to have recognized higher”. Perhaps. That’s why YC pushed you to launch asap by the best way. Perhaps if I hadn’t learnt from these errors, Lago v2 wouldn’t be born. We may have pivoted earlier (I ought to have recognized), or later (oh I made a very good determination). The reality is, no person is aware of, so I lastly let it go. 

What I do know is that we’d have regretted it had we given the cash again, realizing we had ample runway to re-launch and the group caught with us. 

I don’t have a secret method for overcoming this very messy interval, however here’s what made us push by, in case it may possibly assist:

  • We genuinely beloved our new product and the house. Our engineers love tech challenges and the open supply strategy. From a product perspective, there’s so many prospects that holding the product easy is a continuing stimulation. On the enterprise aspect, we needed to conquer new personas, evangelize and educate the market on pricing dynamics and billing implications. The takeaway is: be sure to actually just like the house you’re constructing in, to maintain an intrinsic supply of motivation.
  • The group. In our darkest days of pivot hell, I keep in mind wanting to seek out the following concept simply because I needed to maintain working with my present group. Not solely as a result of I employed them (and felt “hooked up” to them), however as a result of they’re simply good and I do know it will be exhausting to have such a group in one other setting. Plus, we now have lots of enjoyable collectively. 
  • I additionally had a few mates forward of me of their startup journey, who had been by pivots as effectively. It was so good and refreshing to speak to them. I assumed “they persevered and located PMF so I can do it too!”. Primary, however efficient. 
  • I discovered actions to assist me disconnect. Raffi (my co-founder) and I are the “each minute, each line of code, spec, new article, new electronic mail counts” sorts. Now we have the “sense of urgency” in our DNA. We’re nonetheless looking for a steadiness round that. I’ve solely discovered one factor to essentially disconnect: browsing. If I’m not cautious sufficient, a wave would crash on my head as a substitute of me driving it, so my conclusion is:  I’d higher deal with the ocean. Additionally, it’s one of many uncommon locations I don’t have my iPhone subsequent to me, for as soon as (I’ve seen surfers checking their emails on their Apple Watch however I don’t have one. I hope I gained’t get one for Christmas!). That is my factor, Raffi likes to go climbing together with his tent, when he doesn’t surf. I can solely encourage you to seek out your “factor” too.

When you’ve got extra questions on what we realized from constructing these merchandise, each Raffi and I are glad to reply them.


Bonus: Fast notes concerning the reverse ETL house, in case you’re not aware of it.

1/ What’s a reverse ETL ?

We didn’t even know what a reverse ETL was, once we enrolled within the S21 batch, nor did we all know our startup can be hooked up to this class both.

Our one-liner was “a no-code information instrument for progress groups, to section and sync buyer information”. 

The fundamental concept is: “Corporations have lots of information scattered throughout lots of completely different instruments. They should centralize it, to carry out progress campaigns, based mostly on customers’ habits”.

In plain English: 

  • Step 1: You might need buyer success information in Zendesk, Gross sales information in Salesforce, product information in your back-office, however to make sense of the consumer journey, you’ll want to centralize this information. 
  • Step 2: You additionally must carry out “identification decision”: i.e., making a “unified consumer profile” by attaching all of the a number of touchpoints, and attributes to the identical consumer (whether or not the touchpoint was initially saved inside Zendesk, Salesforce, or your back-office). 
  • Step 3: You then want to have the ability to section this buyer information: “customers in NYC who haven’t used the product for 3 weeks, and are on the “gold plan””. 
  • Step 4: The ultimate step is to ship this information to a enterprise instrument: Google Adverts if you wish to retarget these customers, an emailing instrument (Lively Marketing campaign, for example), your gross sales CRM (Salesforce) & buyer assist instrument (Zendesk), if you need your group to name again the inactive customers

A reverse ETL focuses on step 4, as said by Hightouch (the main Reverse ETL)

Reverse ETL is the method of copying information out of your central information warehouse to your operational instruments, together with however not restricted to SaaS instruments used for progress, advertising and marketing, gross sales, and assist.

Who performs Steps 1, 2, 3, and utilizing which instruments? 

A knowledge engineer often does, they extract information from the enterprise instruments, utilizing an ETL (step 1), rework the information (step 2 and three) in an information warehouse, and use a reverse ETL for step 4.

Our first product addressed the 4 steps, however the primary use case of Lago was “step 4”. Extra on that later.

2/ Why it’s a horny house

Having all the information on the similar place, cleaned and usable to everybody within the group, is a problem anybody can relate to. Enterprise customers all the time want extra information, Engineers hate information plumbing. 

This universality makes it an enormous market and recognized downside. Constructing in a crowded market ought to by no means deter you. Certainly, after some analysis, each market is comparatively crowded, and having a number of firms evangelizing the market generally is a good factor… and we went all-in.

Source Link

What's Your Reaction?
In Love
Not Sure
View Comments (0)

Leave a Reply

Your email address will not be published.

2022 Blinking Robots.
WordPress by Doejo

Scroll To Top