This is an extremely solid financial statement. $150M in revenue, growing ~100% per year; I'd project a valuation between $3B and $4B.
Twilio, Mulesoft, and MongoDB are probably the best comparables here -- open-source and dev-tools based SaaS IPOs. All of these were very successful at IPO and afterwards, and even compared to these, Elastic looks great.
* They're growing at almost 100% per year which is incredible. Twilio filed for IPO growing at 70% per year. Mulesoft was growing at 60%. Mongo was growing at 50%
* Losing $50M on $150M of revenue. (Net margins of -33%). This is pretty reasonable and in line with Twilio and Mulesoft. MongoDB was significantly worse at -60% net margins.
With that kind of growth I'd imagine something like a 220M ARR when they actually IPO, and valuation of 15-20x that.
Any time there is an IPO filing, I immediately come to the comments on HN, because there is always someone well versed in reading these things that can provide an excellent summary. Thank you!
Now we are just missing the <pedandic explanation of why the technology isn't really all that great if you are a super hacker, but completely missing the point of creating a product that solves peoples problems and marketing+supporting it well> comment like...
"It's really just a wrapper around Solr and a management layer bolted on top I don't understand all the rage!"
To be fair, their documentation is terrible. Trying to set up filebeat feeding into logstash and figuring out custom GROK patterns requires forensic-level Google-fu to sift through vague blog posts and grab small nuggets from forums because the official docs basically say nothing of value.
Honestly, SaaS is a relatively easy sector to value, since valuation tends to be a pretty straightforward multiple of ARR (with the exact multiple tending to be based on growth rate and (un)profitability). Throw in comparables of other IPOs with similar product types, and you can pretty reliably estimate how much a company will IPO at.
I see several responses that mention MongoDB for purposes of comparison and seem to conclude Elasticsearch fares favorably.
It should be noted:
[1] Unlike MongoDB (which is a ground-up build), Elasticsearch is basically an API layer on top of Apache Lucene. This is relevant because they haven't built and don't maintain, control, or own the source of their primary IP.
[2] Unlike MongoDB (General Purpose) Elasticsearch is a single purpose database and good at/used for one thing and one thing only. It searches text fields for text.
So its potential use cases and thus marketshare is far more limited.
Lots of people use it for analytics (checkout their aggregation/time series queries) as well as analyzing huge logs. Some people are starting to use it for machine learning use cases too.
Anyone that's tried to build anything non-trivial using ElasticSearch's aggregation API and MongoDB's aggregation API will just laugh at the idea of using MongoDB over ES. The ElasticSearch APIs are just so much nicer to use than MongoDB APIs.
MongoDB aggregation feels like writing code in assembler.
No one owns Lucene. If everyone stopped developing Lucene, Elastic could devote resources to it which they already do. I don't think that is a potential risk at all.
[1] You don't understand their IP if you think it's Lucene. It really, really isn't.
[2] It's not single purpose anything. I've used it for search engines, event buses and as document stores. It's multi-purpose and more dependable at scale and under duress than Mongo thanks to sitting on top of the JVM.
[3] Stackoverflow stats don't mean anything. What are you trying to imply?
At this point Elastic is a lot more than a wrapper around Lucene/Solr as they have acquired many companies to build out their product offerings. That isn't necessarily a good thing, in my opinion they need to trim down their product from a hodgepodge of APIs to something that can be more easily put to use. The amount of work involved with getting something useful out is about the same that it would take to build a custom solution off Lucene/Solr.
I think calling it just an API later over Lucene is a bit dismissive. I’ve worked with search products built directly on Lucene vs ElasticSearch and there’s significant value add even without the API. In particular, sharding, replicating and managing indexes is trickier than you’d expect and took up a lot of dev time. ElasticSearch made that work go poof.
It is perhaps worth noting that the bulk of Mongo's operating losses were only paper: vesting stock options. I don't know why they wanted to keep that a secret from Wall Street, but it means that they got 6+ years' operating capital from the sale, not just 2. Keeping the secret meant they were motivated to shed people vesting too much, to make their apparent losses look smaller.
Its really surprising there isn't more activity in this area. For instance Postgresql could really use some attention on its text search capabilities such as BM25 and TF*IDF and become a more capable competitor.
I'm surprised that nobody mentioned cratedb (crate.io) in this thread. It is built on top of Lucene (and IIRC ElasticSearch), provides similar scalability, and fully supports SQL (both for inserts/updates and queries). They got a Series A a few months back.
Jepsen showed elasticsearch was pretty bad at partition tolerance. It was a pretty early version, but it would have been nice to see how much they fixed with another Jepsen run.
And distributed SQL of any complexity doesn't really scale. As soon as data that a join depends on is on other machines/nodes, you need quorums and dependent network I/O. Granted with high-speed networks that is getting to be less of a burden speed-wise, but the reliability problems still exist.
Hemorhaging money is not justified by the fact that 'others did it'.
WeWork and Uber can justify it by pointing out unit costs in stable markets, and say 'look we are profitable there, so all of our losses are due to growth'.
Elastic cannot say the same.
In fact Twilio and Mongo have also been hemorhaging money since the start, and it's going to take a hell of a lot of growth, then massive profitability for them to break even.
Venture Captial is now back to the dot-com bubble game of 'who's going to be the fool holding the bag' - basically, raise a pile of money, give away that money for free by selling at a massive loss, and then get naive retail investors to buy into the myth.
What if I raised $100M, bought some lumber, and sold it at a 50% discount to builders, gosh, I'd have a lot of customers! and then did an IPO -> look at the growth!
Twitter is what, 10 years old now?
They just reported their first profitable quarter ever! And guess what, userbase is shrinking!
They're billions in the hole, i.e. billions away from breaking even - they are a massive net financial loss for investors overall; the trick is of course to be an early investor (make money) and not a later investor (dupe).
This game is not designed, it's just a natural dynamic of a market with bad information and or dupes.
Just like the financial crash of 2008 could not happened if dumb German and Japanese banks were not buying up crap bundles thereby enabling local American banks to re-capitalize and go out again and make more bad loans (i.e. the system would have stopped because banks would have quickly run out of capital unable to sell their first batch of crap mortgages) ... in the same way, this VC game would not happen without rube investors somewhere who will actually pay a fortune for a stock like Twitter. There are many more reasons for this obviously.
Unfortunately, when there is shadiness, low-interest rates, not market interventions etc. - the name of the game is 'leverage' - not 'innovation' really. So it makes much more sense to buy your way into a market, than build yourself into it.
And by the way, this is not to take anything away from Twilio or Mongo as products - that's entirely separate issue. Maybe they are great, maybe they are crap, but we don't know because they are being given away at massive discounts so it's very hard to tell.
Sadly, in shady game of leverage, often 'it's the only way' because if you don't - someone else will. WeWork for example is leverage to the max with 0 wiggle room for risk. If there is a market correction and tenancy drops in any major market, they are wiped. Same for any company that's dependent on crazy valuations.
Companies going IPO while losing tons of money, without clear path to profitability ... is not necessarily a good sign.
Losing $50M on $150M of revenue. (Net margins of -33%). This is pretty reasonable and in line with Twilio and Mulesoft. MongoDB was significantly worse at -60% net margins.
Why is a -33% net margin “reasonable” instead of just being “less unreasonable”?
The rule states that a "sane" target for annual growth rate + profit margin is 40%. At a 100% YoY growth rate and -33% profit margins, Elastic is sitting at 70% -- making it pretty solid!
What is the 40% based on? Because there isn't a hint of justification in that post.
If customer acquisition costs are really high, then they're throwing good money after bad.
All of this talk of 'solid financials' while a company is losing money every quarter and whereupon there's no evidence of profit at the unit level ... is scary, it feels like one of those reddit ico pump-it-up chats.
It's all very highly speculative, is what it is. So let's hope it's a great company, with a solid offer and they manage the growth effectively.
Market likely will be assessing them on billings and then afterwards looking for FCF expansion, and finally tracking Non-GAAP op. margin. At ~80% Y/Y FY'18 billings growth investors probably focus on that metric.
Just to be clear, $100M is what they are looking to raise, not their valuation. Their last valuation was about $700M in 2014, so presumably, they are looking for a valuation that exceeds that, most likely in the low billions.
$100M is likely a placeholder amount. They're filing to go public and can adjust that figure later, it's not that strange to do so. I don't think $100M means much there, and relative to their overall valuation if $100M is all they wanted they'd likely have other options.
> We have incurred losses in all years since our incorporation. We incurred a net loss of $52.7 million in fiscal 2018, $52.0 million in fiscal 2017 and $18.6 million in the three months ended July 31, 2018. As a result, we had an accumulated deficit of $233.4 million as of July 31, 2018.
Thanks for posting these. These numbers and loss margins seem typical for a company in this line of service (cloud or self-hosted distributed databases or data services.) See similar recent IPOs for MongoDB, Cloudera and Hortonworks.
Another useful section related to revenue in the paragraph just before the one you posted:
> As of July 31, 2018, we had over 5,500 customers across over 80 countries and in a wide range of industries, compared to over 5,000 and 2,800 customers as of April 30, 2018 and 2017, respectively. Our revenue was $159.9 million and $88.2 million in fiscal 2018 and 2017, respectively, representing year-over-year growth of 81% for fiscal 2018. Our revenue was $56.6 million and $31.6 million in the three months ended July 31, 2018 and 2017, respectively, representing period-over-period growth of 79%. Subscriptions accounted for 93% and 90% of our total revenue in fiscal 2018 and 2017, respectively. Subscriptions accounted for 91% of our total revenue in the three months ended July 31, 2018. In fiscal 2018, revenue from outside the United States accounted for 39% of our total revenue.
The formula for SaaS companies is generally growth + net margin should equal 40%. If they’re growing 100%, even a negative 50% margin leaves them in the clear by 10%.
Beambot has the source. The general idea is its ok to lose Money if your net (growth minus losses) is higher than your cost of capital. (VC
money expects a 30-50% rate of return) In general SaaS companies have high fixed costs so it’s a race to get big enough to cover them. The rule of 40 flags companies that are too unprofitable or not growing fast enough.
Like all financial metrics (PE ratio, etc) it’s still just a crude guide.
If you aren't incurring losses, it means you are throwing away potential income by growing too slowly, and inviting competitors to take up the slack.
In case of a market or tech hiccup, you might find yourself without "sufficient cash flow", and collapse, but that would be the investors' problem. The investors are assumed to be able to absorb the loss and disappointment without undue discomfort, and so they are. Risk to your dreams takes last place.
I understand a lot of silicon valley is funded in this manner right now but please re-read this command and realize how silly it is. It's proper to say that taking a loss for long term gain is sometimes the right measured decision but saying that failing to lose money constantly is a failure is just ridiculous.
I think they are transitioning from license/support to SaaS. Also looking at their statement SaaS is taking over in revenue. License 25 Million, subscriptions 123 Million in FY 18.
Subscriptions do not imply SaaS, though Wall Street often equates the two. It’s just a different licensing model that’s replacig the up-front perpetual license + 25% annual maintenance that is the old school enterprise software model.
The majority of that subscription revenue (they make this clear in other statements in the S-1) is enterprise deals running Elasticsearch & Friends on enterprise datacentres or clouds where Elastic isn’t providing a managed service - they’re providing traditional enterprise software support.
This isn’t unique to Elastic. Splunk, Pivotal, Mongo, MuleSoft, all are similar. Wall Street mostly cares about the revenue model, but there’s a nuance to it.
Subscription includes on-premise installations; it’s just another licensing model. It is common to move away from perpetual license up-front followed by maintenance models to a more spread-out revenue model and better predictability for Wall Street (plus potentially better quarterly deal volitility insulation because of more deferred revenue, especially if they’re doing up-front multi-year subscriptions).
They also say that the majority of their revenue is from enterprises running their own instances.
Anyway, the point is mostly moot for an investor, but it is interesting as a technical person to observe that many SaaS plays aren’t entirely or even mostly *aaS, they’re open source software sold as enteprise software subscriptions (priced at enterprise or SaaS levels too, not a bargain basement OSS support contract)
Elastic is a company I’ve been following from the start when they just had elasticsearch opensource project. Watching this company grow to this point has been inspirational. I really want to meet / talk to the people who made this company. They made open source work.
I’m happy to use their products, filebeat, kibana, elasticsearch, and their cloud offering has been top notch. They got a lot of things right.
Now elasticsearch even supports SQL as a query language.
This is a company that you don’t hear often in the news, but they just kept their focus and shipped the goods.
As you can tell by now I’m a hardcore fan of Elastic.
I'm also a big fan and I'm really very happy for them and their success.
I was using elasticsearch 7 years ago in production already. And just for me, from the outside, it always looked like a crazy trip. I knew there was something going on when nearly half of my twitter timeline tweeted "am working for elasticsearch now". (they renamed to elastic later)
I was chatting in early 2017 with Shay and along the way he mentioned they were almost 500 then and now ~18 months later they are +800. Crazy!
> They made open source work.
Yes!
They have built and still build impressive (open source) projects and they managed to still earn money :) - this is the real big thing!
"We support SQL on our distributed data platform" has to be the new big lie of distributed systems salespeople.
I'm not saying that computing joins, aggegates, sorts, etc can't be done in a distributed fashion, it just takes time, a lot of network reliability/reattempts, and understanding of the approximate nature of results if there are ongoing "eventually consistent" updates rolling through the cluster(s).
Interesting. My initial instinct is to compare them to MongoDB which IPO'd about a year ago. They seem to be doing quite well since, but then again, who hasn't in the tech sector?
I will say I very much enjoy Elastic's suite of products, I can't say the same for MonogoDB.
There are key differences between MongoDB and Elastic.
MongoDB (the company), has been very strategic about defending themselves from Amazon. Likely due to the AGPL licensing on MongoDB (the database), Amazon doesn't offer a hosted MongoDB - you have to buy MongoDB Atlas which runs on multiple cloud providers, including AWS, GCP and Azure. Coincidentally, Atlas subscriptions are the fastest growing part of MongoDB Inc's revenue, which is why investors are bullish on the company.
Elastic (Apache licensed) has actually had their lunch eaten by Amazon to a much larger degree. Many businesses are purchasing hosted ES instances directly from Amazon via Amazon Elasticsearch service. The problem is bad enough that Elastic Inc had to write a marketing blog post about it [0].
Say what you will about MongoDB (the database), but MongoDB Inc. is the most successful open source software-based company since Red Hat. You can see it in the outperformance of $MDB compared to similarly timed open-source IPOs such as Hortonworks ($HDP) and Cloudera ($CLDR).
I can't speak for others, but I was looking to set up a quick elastic search cluster and Elastic's hosted offering beat the pants off of AWS ElasticSearch in terms of usability, polish, ease of getting started and security-by-default.
Now, I don't have a lot of data in the cluster, so we'll see how performance is when that happens, but would definitely recommend Elastic's offering.
Elastic Cloud runs in either AWS or GCP. You get to choose but it's just between those. Unless you mean you were using AWS's ElasticSearch service... which is known to not be all that great.
You could build ES clusters on AWS directly on EC2 and it would be cheaper than Cloud, unless what you're really looking for is that support contract.
I spent a few months of my life learning ES inside and out and would choose this option every time. One of the best tech investments I've ever made.
> You could build ES clusters on AWS directly on EC2 and it would be cheaper than Cloud, unless what you're really looking for is that support contract.
Or you are willing to trade money for dev time. Setting up and running the ES cluster on EC2 will take time and energy (source, I did it ). Whereas setting up the ES cluster on either the Elastic Search hosted service or AWS ElasticSearch is really just clicking some buttons.
However, I'm sure the right solution also depends on the amount of data you are using and the problem you are trying to solve.
I can largely agree with the last statement. The problem I find with the hosted services is that people just tend to throw data at it without really knowing anything about cluster/node/shard performance. This typically blows up in their face at some point and even though Elastic Cloud has nice sliders in place for spend-more-money, they still have to go through the rebalancing pains (if they didn't write-lock the cluster outright). That should never happen.
If you have strictly time-series data and are willing to make compromises around retention window, hosted elasticsearch is an easy conclusion. Invariably though, I find that where performance is a real concern, you have to carefully plan what data you're indexing and that requires operations knowledge around elasticsearch. At that point you almost might as well host it yourself anyway.
Also if X-Pack was something I _had_ to have, and tbh there are free alternatives for all of its good features, I would consider Elastic Cloud.
I'm even a customer of theirs on some clusters, but lackluster support and pushy upselling experiences have made me want to move out of it.
An issue I had with AWS was that even after they launched VPC ES clusters, they still hid the node IPs in the API output(I guess they patched ES?!). Our use case as a data lake meant that we had severely degraded performance with the hadoop/spark drivers than one would expect form it.
> Elastic (Apache licensed) has actually had their lunch eaten by Amazon to a much larger degree. Many businesses are purchasing hosted ES instances directly from Amazon via Amazon Elasticsearch service. The problem is bad enough that Elastic Inc had to write a marketing blog post about it [0].
Also the reason Redis Labs made the controversial decision to change their licensing (and they reference Elastic in it) [1].
> Cloud providers have been taking advantage of the open source community for years by selling (for hundreds of millions of dollars) cloud services based on open source code they didn’t develop (e.g. Docker, Spark, Hadoop, Redis, Elasticsearch and others). This discourages the community from investing in developing open source code, because any potential benefit goes to cloud providers rather than the code developer or their sponsor.
It's a big deal for a lot of companies to be able to pay the cloud bill in one place. Elastic used to provide the availability to pay for the Elastic cloud subscription through AWS' Marketplace. Elastic stopped this when they changed their pricing at the beginning of 2017 and we (my last employer) were negotiating a contract with them at the time. AWS billing was a hard requirement for us because it made it a lot easier on us from the finance side. We walked and I know a lot of others who did too.
It’s a business decision of course. Forge your own path or be beholden to your revenue model dictated by AWS.
Big Enterprise will not require billing through AWS (disclaimer: employed at a large enterprise, buying ~$900k software license currently). They’ll have an accounts payable department, a procurement process, and someone to cut a check or ACH to Elastic monthly/annually.
I totally get that. I don't dispute that. But if you must choose between "please sir, can I have some more?" and controlling your own revenue destiny, it is clear why some would choose the later.
Would you want to be beholden to AWS' whims? You might as well be a Walmart supplier at that point, constantly dragged out to Bentonville having to make your case for every penny of your costs. Amazon has proven its model (all about scale), how it operates (your margin = our opportunity), and you partner with them at your own peril.
I'm suggesting the thought process to shift from, "Ahhh, those Elastic guys and their bad decisions!" to "Hmm, well, tough decision to make [forgoing revenue through AWS] but I understand why they made it".
Can someone explain why a company would pay a cloud provider extra to manage an open source API for them when they could just run it in the cloud themselves?
Another thing to note, along with sibling comments: AWS Elasticsearch is limited in its capabilities. For example, you are blocked from relying on custom ranking models to rank your documents.
There are a lot of limitations with Amazon's hosted offering. Mostly you will find out about them when your cluster needs maintenance (upgrades, outages, etc.). Elastic cloud is a much better product in terms of features, support, performance, documentation, price, etc. I've used both and ran my own clusters as well. Elastic Cloud is my default option these days.
Can you say more about these limitations? Right now I'm using a pretty big custom ranking function to rank my documents in Elasticsearch (using a function_score query), but maybe I'm misunderstanding.
I setup a 3 billion plus document ES cluster using AWS Elasticsearch Service. As a whole it works really well, and it's nice not to have to manage individual EC2 instances. With that said, there are some very annoying things. Previously if you modified the access policy of the ES cluster, it would completely rebuild the entire cluster (create all new nodes and copy all data), which can take many hours.
Recently I turned off some slow query and slow index advanced logging options, again AWS completely rebuilt the entire ES cluster when these options surely should be able to be applied without copying all data.
With that said, there are some very annoying things. Previously if you modified the access policy of the ES cluster, it would completely rebuild the entire cluster (create all new nodes and copy all data), which can take many hours.
From what I can tell, it still does. I can’t comment on the length of time though. I did it before I had many documents and it was a very small Dev instance.
Really great reply - thank you for sharing. I was just researching the company more for investment. I agree also with regards to Horton/Cloudera. They had so much promise - but felt out of favor.
The results for ElasticSearch are from 2015, curious to see how relevant they are now especially given that the team has been working on addressing these issues in the interim.
Also elastic back then was used as a place where you copy your data, not your main data store. (Their positioning changed later) MongoDB was supposed to be used for your primary data store.
We pay them money but I have to say.. there are aspects to the model which freak me out -Like the relative paucity of good R hooks, the abortive attempt at an interface via dplyr basically died. Right now, its curl. Its http sucking and no real way past pagination.
Or, how hard it can be to intuit the json you need, as a naieve user. Back porting from kibana is silly.
Or how easily you can deploy a naieve cluster which hangs bigtime on large data. This thing is like PostGres and ZFS: you really can't fake it, you have to understand it.
I used to put together deal documents similar to this when I worked in finance. It was literally my job to think about potential risks and then list them out.
"Hey boss, this investment has possible earthquake risk, but that seems very remote; do I have to put that in?"
"Yeah, put it in. No one reads the document anyway unless it goes to court and in that case, you can get dinged for leaving out stupid risk factors, but not for having them in."
Just read somewhere about research somebody had made regarding the risk statements (established) companies put out. The result was that statements getting changed correlated with stock price taking a hit in near term.
Did not read the study itself. My explanation would be that since companies are not changing these for fun, they are probably changing them because they see some previously unexpected risk possibly manifesting itself and want to cover their back.
Unfortunately, I can't find the pointer to the study or the article.
I like to see open source backers going public, they give a boost to open source community who want to share but do not want to just spend energy where they cannot get something out of it (money/fame/recognition or just a satisfaction of doing good). I am sure the people are proud of their work. Good luck with the IPO!
Interesting that JOBS act took so much care about executive compensation :
"
Implications of Being an Emerging Growth Company
We are an “emerging growth company” as defined in the Jumpstart Our Business Startups Act of 2012, or the JOBS Act. An emerging growth company may take advantage of specified reduced reporting requirements that are otherwise applicable generally to public companies. These reduced reporting requirements include:
the requirement to present only two years of audited financial statements and only two years of related management’s discussion and analysis in this prospectus;
an exemption from compliance with the auditor attestation requirement on the effectiveness of our internal control over financial reporting;
reduced disclosure about our executive compensation arrangements; and
an exemption from the requirements to obtain a non-binding advisory vote on executive compensation or shareholder approval of any golden parachute arrangements."
And it all started with Shay Banon attempting to build a cooking app for his wife who was a chef.
> JAXenter: You started Compass, your first Lucene-based technology, in 2004. Do you remember how and why you became interested in Lucene in the first place?
> Shay Banon: Reminiscing on Compass birth always puts a smile on my face. Compass, and my involvement with Lucene, started by chance. At the time, I was a newlywed that just moved to London to support my wife with her dream of becoming a chef. I was unemployed, and desperately in need of a job, so I decided to play around with “new age” technologies in order to get my skills more uptodate. Playing around with new technologies only works when you are actually trying to build something, so I decided to build an app that my wife could use to capture all the cooking knowledge she was gathering during her chef lessons.
> I picked many different technologies for this cooking app, but at the core of it, in my mind, was a single search box where the cooking knowledge experience would start a single box where typing a concept, a thought, or an ingredient would start the path towards exploring what was possible.
> This quickly led me to Lucene, which was the defacto search library available for Java at the time. I got immersed in it, and Compass was born out of the effort of trying to simplify using Lucene in your typical Java applications (conceptually, it simply started as a “Hibernate” (Java ORM library) for Lucene).
> I got completely hooked with the project, and was working on it more than the cooking app itself, up to a point where it was taking most of my time. I decided to open source it a few months afterwards, and it immediately took off. Compass basically allowed users to easily map their domain model (the code that maps app/business concepts in a typical program) to Lucene, easily index them, and then easily search them.
> That freedom caused people to start to use Compass, and Lucene, in situations that were wonderfully unexpected. Imagine already having the model of a Trade in your financial app, one could easily index that Trade using Compass into Lucene, and then search for it. The freedom of searching across any aspect of a Trade allowed users to convey this freedom to their users, which proved to be an extremely powerful concept.
> Effectively, this allowed me to be in the front seat of talking and working with actual users that were discovering, as was I, the amazing power that search can have when it comes to delivering business value to their users. Oh, and btw, my wife is still waiting for that cooking app. Now, 10 years later, it is the basis of Elasticsearch.
Slightly off topic: this quote from the SEC filing document:
"Immediately prior to the completion of this offering, we intend to change our corporate form from a Dutch private company with limited liability (besloten vennootschap met beperkte aansprakelijkheid) into a Dutch public limited company (naamloze vennootschap) and change our corporate name from Elastic B.V. to Elastic N.V."
As far as I know, Elasticsearch has no headquarters or offices in The Netherlands. I assume the company is only registered in The Netherlands for tax avoidance.
If my assumption is true, despite that I like their products, this makes me a little sad.
EDIT: my bad. I missed the tab Europe and Asia. They do seem to have an office in Amsterdam.
> As far as I know, Elasticsearch has no headquarters or offices in The Netherlands.
According to their contact page, their European headquarters are in Amsterdam (https://www.elastic.co/contact), so they do seem to have some kind of presence there. And if you look at their careers page, it seems that most of their engineering team is distributed/remote.
Isn’t the founder from the Netherlands? I’m fairly sure they also have a small office in Amsterdam, but most of their engineering is done by people working remotely.
Twilio, Mulesoft, and MongoDB are probably the best comparables here -- open-source and dev-tools based SaaS IPOs. All of these were very successful at IPO and afterwards, and even compared to these, Elastic looks great.
* They're growing at almost 100% per year which is incredible. Twilio filed for IPO growing at 70% per year. Mulesoft was growing at 60%. Mongo was growing at 50%
* Losing $50M on $150M of revenue. (Net margins of -33%). This is pretty reasonable and in line with Twilio and Mulesoft. MongoDB was significantly worse at -60% net margins.
With that kind of growth I'd imagine something like a 220M ARR when they actually IPO, and valuation of 15-20x that.