Realm

Check out our open-source Feature Flagging system - Flagsmith on Github! I'd appreciate your feedback ❤️

Episode Transcript:

Bjarne, thanks so much for your time. We’d love to get a little bit of an idea about what you do and what your product does.

I’m in San Francisco, I’m originally from Copenhagen, Denmark. I’ve always been into tech and taught myself to program when I was 10, 11 years old. Long story short, I ended up at Nokia in Copenhagen, which was the largest R&D site outside of Finland. It was doing a lot of low-level embedded software development. Ventured more into internal development of developer tools and spent twelve years there. It’s a good experience. From there I got this unique inside view of the rise of the iPhone and found that exciting.

I had a closer look at the first generation of mobile applications for that platform. At that point, I started to talk to one of my childhood friends. We talked about how we envisioned the future of mobile. What should you be able to create as a developer for this platform? One of the things we realized was these mobile devices are not connected devices. They’re semi-connected devices. They go in and out of connectivity and you have a different expectation to the user experience compared to the web world. The experience that we saw back then, derived from the web era and developers transitioned from the web world and would bring their development stack into the mobile world. It’s very cloud-centric.

We felt that the mobile application deserves a much better data model so we set out to build that and ended up pretty much reinventing your basic data structures in C++. First of all, I make them highly efficient for most operations and then we started to bring in a lot of the functionality you have from their traditional database world. Bringing that much closer to your programming language and this technology, we could pretty much plug into any programming language. It was just a small library.

Based on that core technology, we wanted to start a company and we could have started something out of Denmark for sure but realized that if we wanted to have the opportunity to have an immense impact, Silicon Valley is the place to be. I’ve always been super inspired by everything that goes on all year and I’m a big fan of the Y Combinator program. We felt that was a good path to try to get into that program. We applied to Y Combinator and I got it back in 2011.

{{divider}}‍

That’s a very different organization then compared to now.

You can say it’s like the original setup with all of the original partners. It was the largest batch at the time. We were 62 companies. They went from 40 companies to 60 companies. That was a big leap but it was still before they started to split it out into groups. Now, there are hundreds of companies in each batch. We got the original experience while it was still headed by Paul Graham. That was exciting and interesting in the way we got plugged into the core of Silicon Valley. That enabled us to build some good relationships here in Silicon Valley and also a good seed round, probably one of the best seed rounds from some of the top-tier institutional VCs in the Valley.

We hadn’t launched anything. We had some interesting core technology. Also, this was back in 2011, so still very early on the mobile side. I remember Facebook was still debating internally or whatever if they should build a native app experience but with the HTML5. I think this started with HTML5 but quickly realized that they needed to go all in and build a more superior experience.

{{divider}}‍

Did you have a proof of concept at that point when you were still at YC?

We have the core technology worked out too. We could do the benchmarks and we could plug it into any programming language. You could complement your existing data structures in those languages. They had an idea that mobile was going to be huge and that would be an interesting market to go for. At that time, we were still building out the core technology. We started to do some pilot projects. One of them worked with some of the companies in our batch where we could plug into. Ruby was one of them and it improved the performance when it came to data handling within the application and would affect several thousand.

They were operating based on JSON-RPX. There was a lot of serialization, deserialization and all those things we could just skip. We were kind of cheating in that way. There was no copying and moving data around. We worked on the data directly in that format. We didn’t have to develop or have to move data from our isolated system into your local data structures. You could use it directly. That was exciting. You could then take those data structures and they’re persistable so there’s no reason to move them over to an external database.

{{divider}}‍

It’s so that it’s clear to people, it behaves like a regular database on the client but it’s doing behind the scenes syncing when it has network access.

I would flip it around. We focused on the data structure part and we mimicked the interface of your local data structures. Whether you’re working with Objective-C or Python, it looked like your local data structures. In reality, everything was happening in our library that you added to your application. We went from there and enhanced the possibilities you had with those data structures. You could take those data structures and they were faster. Depending on how complex your data structures were, the more complex, the more advantages we could give you in terms of performance. In a lot of cases, even in a language like CSE C++ we could improve the read and write performance with a factor of 80, which is crazy.

We would take that and plug it into any programming high-level language even doing a lot of work with PHP back in the day. Speaking of Facebook, Zynga was one of our very early users and that just needed some better data structures in these high-level languages. We said, “What if you could go from there and not having to move the data into an external database?” This was still the embedded database part. Further down the line, the whole data structures were designed to take that model and move to the server-side but that came later on. That element was what we were focusing on for the first few years.

{{divider}}‍

Was this code open-source from day one? Did that happen later?

We open-sourced behind. The language bindings were open-sourced but not from day one because we were in stealth mode for a few years before we made anything public. Once we publicized what we were working on, we would open-source our language bindings. At that point, we decided to focus 100% on the mobile use case. Making developers somewhat easier and better when it came to handling data within the application. Some of the first use cases were useful like offline caching and things like that. Handling that in a more efficient and better way or coping with performance issues. It’s super easy to do multithreaded operations directly on the data structures.

{{divider}}‍

Was this before SQLite was being shipped with iOS and Android?

SQLite was shipped with all embedded devices from day one. That’s the only alternative. That’s essentially what we went up against. It’s a better alternative to SQLite or any of the ORMs that sits on top like CoreData. Everything is built on top of SQLite unless you’re using Realm or flat files.

{{divider}}‍

You don’t have to start thinking about database when you’re working. There’s no ORM or SQL. You’re just storing effectively.

It looked like you’re manipulating the local data structures while in reality we did some deep integrations into the programming language. When we were about to launch, we were watching the WWDC and that’s when Apple announced Swift and said, “We can’t launch this new mobile database technology for mobile without having support for Swift.” We wanted to start with iOS first because we’re in Silicon Valley. That’s the primary mobile platform. We said, “Let’s delay our launch until we have support for Swift.” We recognized that as a huge marketing opportunity. We decided to start a meetup group for Swift. That same day we registered.

A couple of weeks later we gained some experience integrating into Swift. There wasn’t a lot of flat documentation so there was a lot of like groundwork. The first meetup we held was not about us. It wasn’t a secret that we were sponsored by http://Realm.io but it was about our experience working with this new, exciting language. We built a strong developer community around Swift. That gave us a lot of credibility and trust. We’ve got a lot of mobile developers both from larger companies. We were down the road from Groupon which was pretty big back then.

{{divider}}‍

The language bindings were open but there was a core blob of code that was proprietary that you’d been working on for years. That was what ships into the device. What happened next?

It was interesting before we launched our Series A as well. We were talking to a lot of investors back then and they were challenging us on, “What does this enable that you couldn’t do before?” “What’s the Keeler app?” That was hard to invent some functionality. The best thing we could come up with was offline first and being able to use your applications while you’re not connected to the internet. There were challenges on that. They would ask like, “Won’t we all be connected all the time pretty soon? We’re already starting to see connectivity when we’re flying. Is that going to be a big problem?” We didn’t know. That was the best we could come up with.

We focused on a couple of different things. First of all, the ease of use like frictionless, a small library, super easy to dump into your IDE and focus on making developers lives somewhat easier and better when it came to handling data within the app. Also, awesome documentation and support around the technology. There’s the developer community that recognized what it was that we were working on because it wasn’t a secret at that point. We just didn’t want the community to be about our commercial life company.

That brought us into Groupon where our developers recognized the value of Realm and the ability to fix some of the problems he was facing in his daily life. It’s grown from there. We were using anything from small hobby apps to sizable apps. We then got into Starbucks and McDonald’s, all the big retailers and it went global as well. We got a request for encryption very early on from the largest bank in Finland. We built that, got into that app and then it took off from there. We supported developers where they wanted to take the technology.

{{divider}}‍

You let the market lead where it went.

We were forced to like, “You have to be very specific and be able to guide developers more.” We were focused a lot on the ease of use. Once you start to use it, there was not much new to learn. There was no new language or syntax. We added some functionality and on top of what you already know.

{{divider}}‍

At this point, the data is not leaving the device. Is that right?

That’s correct. We made it easy to pull the data out. We worked seamlessly with JSON-RPX but there was no backend service at this point. It’s entirely focused on the in-app experience.

{{divider}}‍

Around then the pause was big. Google bought Firebase and started pushing that quite hard and they still are. At what point you were like, “We need to start thinking about that.”

We did Y Combinator together with Firebase, Parse and Meteor. All three companies were built on top like MongoDB, which was interesting in their approaches and products became hugely popular. We took a different route where five days in Parse made super nice APIs on top of an existing database architecture which was smart. We flipped it around. We never directly competed with Firebase and Parse. We supported that developer growth. Within the first year, we reached over a billion installs on the client-side. Parse’s mobile like our mobile scaled and that says something about us. At that point, we got into Netflix and it all adds up. It’s a super-strong developer community and we built a good brand around the company.

{{divider}}‍

What was your revenue model at that point?

It was very clear for us that the client-side was always free and open-source developer adoption just focused on making developers’ lives somewhat easier and better. We would later introduce the same data model to run on the server-side. This is optional but if you’re already using Realm on the client’s side, all you had to do to take advantage of the server. Our technology was change one line of code. Rather than pointing to a local handle, you will give it our URL and we’ll give you a synchronization with the backend with seamless synchronization with fine-grained conflict resolution.

We could enable developers to build a functionality that they wouldn’t be able to develop like all the approaches because you had a disconnected model using SQLite on the device and then had to get it into some JSON format or SQL format. There’s a lot of information lost in that translation. Whereas with Realm, we could offer seamless synchronization with fine-grained conflict resolution. Essentially enable developers to build a new class of functionality within the app. A true real-time collaborative functionality that also works when you’re not connected to the internet. That was the big value add. That was always super clear and by default, the plan was to lead with a SaaS offering like a freemium so developers could ease into the commercial product.

We also realized that if we wanted to build a huge company, and this is back in 2013 to 2014, we knew that we had to end up with a hybrid model to both have a SaaS offering but also have traditional enterprise sales. At least at that point, SaaS was definitely proven as a valid business model but not to the point that it was feasible to generate hundreds of millions in revenue solely online on SaaS and getting money from developers essentially. That was always clear. We raised a $20 million Series B based on our developer adoption and used that money to bring the commercial product to the market. It did end up deciding to lead with an enterprise sales model. We also looked at Firebase as a pure SaaS approach. Those starting to figure out, “What’s the enterprise offering?” That wasn’t clear at that point and we were a little bit scared about, “How much money can we make developers pay this in full?”

{{divider}}‍

It’s quite a big bet if you’re investing at that point because you’re not quite sure how willing people are going to be to hand over money. It’s fickle and you’re never quite sure what people are prepared to pay for. If they are prepared to pay for it, how many zeros are there?

From our perspective, as bankers, we had zero experience with enterprise sales but at least we realized that. We took on a lot of advice from advisors and investors. We took out on that learning curve like, “What does that look like?” We knew that that was a proven business model and we were already into some big companies that were used to buying infrastructure technology and enterprise products at 6, 7 figures. We knew it was possible and that we had a tremendous value add.

We were very confident that we could get that to work. It did turn out to be a lot more challenging than we anticipated. We had to transition the company from being 100% developer-focused and driven to be sales-driven. That was a mindset shift in the company. The other thing was that we realized we needed to bring in some more enterprise experience and bring that DNA into the company. We started to look at that before we had our enterprise product shaped up.

That was a role that’s hard to hire for especially if you haven’t done it before and you don’t have a product and a playbook. It’s a very specific persona you’re looking for at that state. Also, we as founders wanted to be involved in the whole sales process and we learned as we went. The biggest challenge was we found ourselves having to educate the market on what they should be building. What does that mean for an eCommerce business like Starbucks or Macy’s that the developers have a super easy time building real-time collaborative functionality within the application? All the developers loved talking to us so we got into talks with all these companies but then we had to invent this functionality.

That was our biggest is the limitations. Rather than coming from developers having a fair chance to explore the synchronization part of the product and figuring out if does it make sense to build. We did have a few examples where developers recognized that this might be able to solve some of the synchronization issues they have with the backend but that was an abnormality. Usually, we had to brainstorm together with the developers.

The other thing was that mobile app developers loved our technology, a huge star there but they were not the buyer. We had to talk to the DevOps team and in a lot of cases they didn’t even know where these guys were sitting. They were just focusing on building that app experience and add some defined APIs to the backend. When we finally got the chance to talk to the backend guys, it was an uphill battle to convince them that this was safe to put into the server room.

{{divider}}‍

You had the server component as part of the SaaS product but you were selling private installations or on-premise installations.

It was all on-prem.

{{divider}}‍

How did you go about managing that? Everyone’s infrastructure is slightly different and their approaches are different. Their tooling and orchestrations are different. It’s becoming a bit more standardized now but you had to do it one by one.

The use cases that we ended up solving could decouple that use case so they didn’t have to integrate into other database solutions, at least initially. From an installation perspective, we offered darker images and stuff like that. Otherwise, there was some handholding to get them up and running but we tried to make that installation process as seamless as possible.

{{divider}}‍

The mobile engineers at Netflix were using your client-side library and was that for free. Was it hard? They didn’t have to go and find someone with authorization to spend $50,000 on something which is hard and they don’t know how to do that.

I don’t think that was the biggest problem because the mobile app developers were able to bring their managers into the conversation. We did get a chance to talk to higher-level people and they were very interested. If this technology could give them an edge or a superior experience to the end-users, they’re willing to spend the money. That was frustrating. We could see that the money was there. You’re right, we were started by developers and had to navigate the organization. That’s not something you should take for granted but if you have something compelling that can give them an advantage, then it is possible to find the money.

{{divider}}‍

At what point did you start talking to Mongo?

First of all, we’ve always been super inspired by Mongo. Especially back in the day, the ability to build a developer community. There are companies building their companies on top of Mongo and then we ended up selling our company to Mongo in a full circle. They were from an era where back then they didn’t want to offer a host solution. We have companies in our batch, a company called MongoHQ that was renamed Compose and then sold to IBM which was offering Mongo as a service. We were struggling with enterprise sales and we built a sizeable organization.

We were starting to burn some cash even though only 1/3 of our firm was in Silicon Valley. We had 1/3 of our team located in Denmark and the last third was spread out in South Korea, Japan and Australia. Still, a significant firm with 68 employees to support our developer adoption. We had to raise the next round and revenue didn’t come in as quickly as we had anticipated or hoped for. At that point, we had interest from some of the biggest companies in this space. They had an interest in acquiring us for an array of different reasons. For pure technology or potentially converting into their proprietary server-side solutions because they admired the apps, we got to work our technology into.

None of those offers made sense for us. We had some good investors who said, “We believe in it.” We’re a little bit behind so it’s hard to attract a new lead investor. We took a hit on that. We raised the next round and it was a smaller round. That meant that we had to scale the company down. We reset the company and scaled it down to 24 or 25 people from 68. That was an interesting exercise and got everything stabilized and managed to find the right hit of sales.

Also, we talked to the board about bringing in more senior experience to the C-Suite. Someone with more enterprise experience. We’re doing an internal search for about a year until we found a good match with a new CEO who came in. My cofounder was the CEO at the time. He was here with his wife and three kids and they’re all ready to go back to Denmark. He was happy getting back more into the technical product aspect.

{{divider}}‍

He had enough of the sun.

That worked out. We then got the new CEO in and got him on the right track. I decided to move on to figure out what I wanted to do next. It was helpful to get a new perspective and fresh energy. We’ve been going on for eight-plus years at this point with some ups and downs. It’s a long journey. I also ready to figure out what my next thing would be and support the company from the side.

The new CEO took a good stab at running the company. We didn’t see any exponential growth on the revenue side but it was definitely going in the right direction. At that time, right before I left, we launched our own SaaS offering. That was the missing piece to give this natural transition from the open-source product to the commercial product. With a somewhat limited headcount, we had a hard time giving it enough resources and attention while focusing on enterprise sales.

We went down that path and I believe that was the right focus to continue on. That worked out. He grew revenue because a year after he came in, Mongo came to us and gave us a reasonable offer. They wanted to break into the mobile space. I think they recognized how hard it is to build the right technology to make that move. Also, they recognize the developer brand that we had established. That bought into the bigger vision that they had.

We felt that was a good fit. It was pretty straightforward. Everyone agreed that this was a good landing place. Back then, we were open that we could take it significantly further. I don’t think we, by far, reached Realm’s full potential but this is definitely a good setting for the product. It’s still an independent product. After we got acquired in early 2019, I heard more and more people recognizing or discovering Realm. If you’re already using MongoDB for some web development, go up to the website and say, “What is this mobile offering? Maybe I should have a look at that.” That’s exciting. They put a lot of resources and effort into pushing the bigger vision forward.

{{divider}}‍

It’s interesting that Parse, Firebase and you maybe work in a slightly different segment. I remember a few years ago we built a big application on top of Parse and then Facebook announced they were going to shut it down. They cost us a fortune. It’s ironic that it now survives as an open-source product that people still use. Firebase went off and got acquired by Google. They’ve all come into different resting places. Did you ever feel like you were competing with each other? Did they stop sending you Christmas cards when you told them you were going to do the server-side stuff?

No. I know that we were very close especially with the Firebase guys. They’re definitely interested in doing some collaboration at some point before we launched because they could see we had a superior way of dealing with data within the application but couldn’t come up with a good way to make that happen. Never mind the hostility.

{{divider}}‍

You never considered joining forces. It sounds like it would have been a nicely complimented merger, maybe earlier.

Google had some level of interest in acquiring us. They recognized the enterprise-level application that we’re into but still early when it came to that conversion from the open-source client-side only users to using our back-end service. That was the biggest hurdle for them to figure out a reasonable conversion rate either to running Realm on the server-side or to converting into Firestore or some of the other microservices. There’s a level of interest. We’re close to them so they had a close eye on what we were up to.

At that point, we raised over $40 million, so that was a threshold as well. For us to sell out at that point, it had to make sense financially. Even after the C-round, our investors would have continued to deploy more money. We always had that option, which is a little bit behind on the commercial sign and playing this catch-up game. The motivation was high. Internally, we built a super-strong team and we were on this mission. We still had more fuel and oxygen in the tank. An acquisition had to make sense on all levels not just financially.

{{divider}}‍

Is that core library code open source now? What did Mongo do with it? At what point did you open it?

We open-sourced it when we announced our server-side.

{{divider}}‍

Did you feel the value was more on that side of things?

Yeah. That was always our strategy to open source behind us. We had talked about whether or not we should, at some point, open-source the synchronization. We had a lot of plans for building additional solutions, products and technology on top. That synchronization product was a huge leap but it was the endpoint to say, “This is it.” There’s a ton of potential in the areas we could move into as well.

{{divider}}‍

Did that make it more difficult in a way that you had such a flexible tool that you’re not sure who your target customer is?

Yeah. Even before we launched, we weren’t sure if we wanted to bet everything on mobile. We were looking into the IoT space and analytics. Some of the pilots we had before we launched were not in the mobile space. We took a bet on that, which I’m happy with it. When we announced our open-source product, it was hard not to push it in a specific direction and lift it to developers to figure out where it makes sense to use the technology. That’s the mindset we had when we launched our commercial product and that’s reasonable initially that you’re in this discovery phase. We grew into a broader way of companies, anything from banking, healthcare, eCommerce and entertainment. The only area we didn’t have a big footprint in was the gaming industry. Besides that, we had good adoption in a lot of developer sectors.

{{divider}}‍

Surely, you’re perfectly aligned with the performance requirements of games. Do you know why that was that it didn’t get?

A large percentage of games are built on platforms such as Unity. Unity is out of Denmark and we had the founding CEO on the board as well. It’s a huge inspiration. Luckily, we were fortunate to be able to bring David Helgason into our board of directors when we raised our B-rounds so that has a tremendous value at building developer tools and a healthy business around it. We did have conversations about getting into Unity and that would have happened at some point. We had to focus. You had a lot of native games but that’s a special era where that’s a lot of custom solutions. Developers never pulled us in that direction.

{{divider}}‍

Did you let the communities guide you and provide that guiding light rather than the other way around?

When we started selling our commercial product, it was all outbound. We had some interest. We had a good idea of some of the big companies that were using us and got ahold of the developers. We talked to a broader way of potential commercial users and closed some good deals. We’re still in the phase where we were identifying these patents and maybe we should have honed in on a specific use case and vertical.

It’s something we were focusing on. We felt we need a little bit more data point to make those investments or maybe we’re not good enough at recognizing those patterns with our lack of enterprise sales experience. That might be the case as well. It’s hard to limit yourself in that sense to say, “This technology is for this specific use case and you should only use us if you’re a financial app,” for instance. That seems very limiting.

{{divider}}‍

Are you still involved in that core open-source project at all or not?

No. Once I moved on, I started the company on the underside. I started to look into what would be my next thing.

{{divider}}‍

What is that?

It’s still in stealth mode but it’s not super-secret. It’s based on the same fundamental insights that we had when we started. This time, I’m addressing the broader internet of things. I’m focused on the industrial internet of things of use cases, at least in the foreseeable future. Since I got a lot of experience selling into traditional industries, I could see a huge appetite for getting on this digital transformation and having a broader need than a better mobile experience.

I spend a lot of time digging into that space. It’s a bit of a crowded space but I see the same pattern and then I see the internet of things as an extension of mobile. You can flip around to see mobile as the first mainstream device to enter the internet of things. With the traditional internet of things, you send up all raw data to the cloud. There’s a hot cloud dependency with traditional IoT solutions. That’s where you have the primary decision-making.

That’s great for running some analytics and you can build some beautiful dashboards based on that. That adds some level of business value. The main value in the industrial internet of things is to be gained much closer to the origin of web data being generated. That’s also the reason why everyone is talking about it, compute and start to see compute cycles getting pushed back up to the edge. I had to see most of these solutions as expanded solutions for our de-bundling problems so that’s what I’m addressing.

At a high level, what I do is enable this wireless sensor network to operate truly autonomously and make smart decisions while it’s not connected to the internet with a primary interface being a mobile device. You can see it as a cloud-independent IoT architecture so there’s a cloud connector. You can take advantage of cloud computing, build dashboards and things like that. I’m focused on pushing intelligence down on the microcontroller level.

{{divider}}‍

I don’t think I’ve considered industrial IoT or B2B IoT because people were constantly talking about retail products. How big is the industrial market? I bet it’s bigger than I imagined.

It’s huge. I did a lot of market research. It’s hard to gauge. It’s early and it depends on how you look at it. Are you counting the anticipated number of IoT devices? Are you talking billions? Are you talking about financial value? It’s hard to do a bottoms-up. How much legacy equipment do we have in industrial settings where it makes sense to add a level of intelligence? If you’re into asset tracking logistics, how many things are we shipping around? I struggle a lot on nailing the true market opportunity. It’s huge and there’s room for a lot of different players in that space. There are a few companies that have done reasonably well but I still don’t see the internet of things have taken off. We haven’t seen any big winners. There are a lot of reasons that account for that. In the last several years, there have been some good lessons learned. The internet of things is ripe for probably taking off and being disrupted.

{{divider}}‍

Did you have anything else you wanted to talk about?

No. We run well.

{{divider}}‍

It’s a fascinating journey. You didn’t apply to YC again?

I thought about it.

{{divider}}‍

Has anyone done it twice?

Yeah, lots of companies.

{{divider}}‍

Any individuals?

There are two different companies from my YC batch where the founders have come together and started a new company. I’ve got the name of it. They both got acquired and they did Y Combinator again. I thought about it but I’m so far. I built out the core technology. I at least have this warm fuzzy feeling around the go-to-market strategy and line of sight of the first use cases, pilots and stuff like that. I have a solid plan. I’ve been able to bootstrap the company to where it is. That might be something for part two, my take on the go-to-market strategy on this journey because it’s different than Realm but highly inspired. I take a lot of the lessons learned into account from Realm. That might be a good segue into part two if you’re up to doing another interview.

{{divider}}‍

For sure. It sounds good. Thanks for your time.

Thank you for having me on your show.

{{divider}}‍

Thank you. Cheers. Take care.