Subscribe
Share
Share
Embed
Today, we’re joined by Ivar Østhus, CTO and co-founder of Unleash. He talks to us about the inspiration behind Unleash, why they have two different APIs in their platform, and more.
Chapters
- (00:33) - What is Unleash?
- (01:05) - Tall tale about the inspiration behind Unleash
- (02:37) - How Ivar learned about continuous delivery
- (10:04) - The two APIs in Unleash
- (16:33) - Backward compatibility and deprecation strategy
- (22:51) - Users, permissions, and roles
- (31:25) - How Unleash gets enterprise customers
- (39:29) - Ivar’s data model tip
Sponsor
This show is brought to you by Xata, the only serverless data platform for PostgreSQL. Develop applications faster, knowing your data layer is ready to evolve and scale with your needs.
About the Hosts
Queen Raae wrote her first HTML in 1997 after her Norwegian teachers encouraged her to take the new elective class.
Around the same time, Captain Ola bought a Macintosh SE for his high school with the proceeds from the school newspaper he started.
These days, you’ll find them building web apps live on stream and doing developer marketing work for clients. They are both passionate about the web as a platform and the joy of creating your own thing.
Visit queen.raae.codes to learn more.
Creators & Guests
Host
Host
Guest
What is Data in the Wild?
Learn from your favorite indie hackers as they share hard-earned lessons and tall tales from their data model journeys!
Brought to you by Xata — the only serverless data platform for PostgreSQL.
[00:00:00] Ola: Welcome to Data in the Wild! Discover data model tips and tricks used by our favorite indie hacker devs with Queen Rae! I'm your co host, Captain Ola Vea, and this podcast is brought to you by Xata, the serverless data platform for modern web apps.
[00:00:21] Benedicte: And today's guest is the great and powerful Ivar Osthus. He is the co founder of Unleash. Welcome to the show.
[00:00:30] Ivar: Thank you so much. Glad to be here.
[00:00:33] Benedicte: So let's start with what problem does Unleash solve? So we know what your company does before we dig into the data models.
[00:00:40] Ivar: Yeah. So we are the open source feature flag system. So we help engineers to run faster and still keep control on what they built.
[00:00:51] So simplifying lives for all developers on the planet.
[00:00:54] Ola: Yeah. I like it.
[00:00:57] Benedicte: You practiced that one. That was like, that was sharp.
[00:00:59] That was sharp.
[00:01:01] Ivar: Yeah, that's what we do.
[00:01:04] Benedicte: I like it.
[00:01:05] Ola: So do you have a tall tale?
[00:01:08] Ivar: Yeah, I do actually. And this is actually what inspired me, why it's so important to simplify life for developers, because being a developer is super hard.
[00:01:16] And I remember back when I was fresh out of the university, super eager. I was a consultant. I don't know why you allow a fresh graduate to be a consultant, but I was working for this big financial institution here in Norway, building stuff. I was super excited, kind of getting it front of actual users.
[00:01:36] And the way we were releasing software back then, this was many, many years ago, 15 years ago, was to kind of create this zip file. Send it on email to another company in Denmark, another kind of a company who didn't know what we were doing because they were responsible for production. And we had to build this release script, like you have to unzip.
[00:01:57] That was step one, always unzip. And then you had to kind of click this button in this application server to upload. And then you had to kind of yada, yada, yada. If something went wrong, what happened? They canceled it. They started reverting everything they did and you didn't get the stuff out. And the next time you had an opportunity to actually improve the application and for users was two months later.
[00:02:24] That's crazy!
[00:02:25] Benedicte: So the opposite of continuous release or continuous integration.
[00:02:29] Ivar: Absolutely. And the opportunity to improve anything, get feedback on what you do was like zero.
[00:02:37] Benedicte: So where did you learn kind of the opposite or like, when did you learn about another way of doing this?
[00:02:44] Ivar: Yeah. So for me, it started with multiple things.
[00:02:46] Obviously I understood that working in this environment is what maybe not the most sophisticated way to work with software. So I started to become very interested in agile in general. Like that's a better way to work with how we plan and build software. So I was part of the Agile conference. I was the host for that multiple years in Norway.
[00:03:10] And use that as an opportunity to learn from better people, better teams than the team I was on. The team was great, but kind of the environment was not.
[00:03:20] And then I obviously progressed. I moved into a different company. I started for Finn.no which is the leading marketplace or classified marketplace here in Norway.
[00:03:30] And here I joined at a very exciting times. It was very technology driven. They had this goal to start doing continuous delivery. It was kind of management type of goal. At the time when I joined ,they were still doing kind of these quarterly releases but I was then part of that journey to be able to go from quarterly releases what do we need to do to get to monthly releases? And then what do you do to get to bi weekly releases? And then we tried to do weekly releases, but it was just so much work that we decided to do the next step needs to be daily releases, and then you really realize what you need to do and automate.
[00:04:09] And it's actually a super fun journey to be part of that and learn what it takes to take a whole organization from that weird place of never releasing almost, to releasing all the time.
[00:04:22] Ola: You release daily?
[00:04:23] Ivar: Yeah, we but even more. So when I quit Finn to do only full time, we actually released 2, 500 times per week.
[00:04:31] Ola: Wow!
[00:04:32] Benedicte: Well, that's also. That's, wow! I feel like that qualifies like a very positive tall tale. Like, that is super. So then you're just, every commit goes into production basically then, or?
[00:04:45] Ivar: Yeah, basically. And you commit all the time and you divide your features into smaller pieces, very small pieces. And you allow each piece to kind of individually flow out to production. And obviously you would need to then start thinking differently. You will work trunk based. You will use feature flags.
[00:05:04] Everyone was using Unleash, of course. And using Unleash to kind of facilitate, because obviously, not all individual commits actually make sense for your end user. And when you have millions of end users, you just don't want to ship something that they cannot really use yet. But you still wanted out there to get feedback from the production environment, get feedback on.
[00:05:25] Are there any cases that we didn't think about? Does it really work the way we think it works? Can we test it with some real production data? Is the firewall open even? That can be a challenge sometimes. So having the ability to put your new functionality into production, but not necessarily turn it on for everyone immediately. It's a superpower that at least for me, I saw the real potential at Finn and I realized that many companies in this world had this problem.
[00:05:53] And I also learned that from the open source and a lot of users of the open source, of course.
[00:05:58] Ola: Cool. So did you get any pushback?
[00:06:02] Were there any other developers who were like, "Dude, why are we doing it this way? It was much better before."
[00:06:10] Ivar: Yeah, you always have those. So it's like developers are humans do.
[00:06:14] So some developers are kind of very early on the hype curl, maybe too early. I may be one of those, at least back then. I matured. And then you have kind of the big chunk of people who were kind of, they will be skeptical at first. What is, why should we release every day? That sounds a bit often. But then when they see the value, they will come along.
[00:06:36] And then you have, we always have those laggers. It will come after they will like, "yeah, it was so much better before it was like, then we could properly test it. And now we actually, now we have to do so much and all of that." But I think that's kind of just the nature that people are different and people have different expectations. But in general, I think everyone after kind of learning the new way of thinking, learning about how we can ship features more gradually and kind of incrementally and experiencing that first time. When you see that over time, you see how it actually simplifies. Then of course, even the laggers will come along eventually.
[00:07:20] Ola: So before we get into your experience with data modeling for Unleash, could you quickly run through your tech stack?
[00:07:27] Ivar: Yes, so Unleash is mostly written in TypeScript. The API, the front end is written in React. We use a UI tool called Material UI to kind of build our components, UI components. But then that's kind of the Unleash service itself. And then to really use feature flagging in your system and in your application, we also build SDKs for all the major programming languages.
[00:07:59] And these SDKs would obviously be written in Python, in Ruby, in Java, in NET, whatever. And also obviously for the front end, like Android, iOS, Swift, of course, and also JavaScript, pure JavaScript and React wrappers on top of that. And yeah, they are there. So we do a lot of programming languages at Unleash.
[00:08:20] Benedicte: On the Unleash service side, I guess you, so you said the application was a React application. But what.
[00:08:28] Ivar: For the front end, yeah.
[00:08:30] Benedicte: And what's the backend? What kind of database and that kind of thing do you use?
[00:08:33] Ivar: Yeah, sure. So it's written in TypeScript. We use Express for simplicity and we use Postgres. And to connect to Postgres, we use a very easy kind of mapping layer called Kinect. So it's not an ORM or anything like that, but it just simplifies building your queries basically.
[00:08:53] Benedicte: Okay.
[00:08:54] So what data model has changed the least for you since launching Unleash?
[00:09:00] Ivar: That's a good question. I think, the most stable part is actually the feature toggle model. Kind of the metadata part of the feature toggle.
[00:09:14] What has evolved slightly is obviously the, how you can, the configuration that comes to it. Like how the rules on how it should be enabled in certain environments and such. That has. change slightly more, but again, it's quite stable. And the reasons for this is kind of it needs to be quite stable.
[00:09:34] It's kind of the fundamental of what we do. It's kind of what you integrate into your application through the SDKs and all of that. So changing that has a huge cost for us. And we are very careful on that.
[00:09:47] Benedicte: So what kind of meta, what information is that in that metadata? So the toggle is this feature on or off?
[00:09:54] Ivar: Yeah, you toggle the name, the type. And obviously there is but on and off has slightly changed. But it's kind of, there is obviously on and off.
[00:10:04] And then you have, and this, we will probably move more into the details of that, but we or I because I created this, made very early on a very clear distinction that how you administer Unleash kind of how you define feature flags and how you configure and kind of working with kind of defining stuff is a separate API than the API that SDK needs to connect to in order to retrieve the configuration kind of the read API for them is different.
[00:10:37] And this has actually allowed us to build quite a lot of advanced capability on top of this, but still keep the API for the SDKs. Very stable. So what does then the future flag actually define? And it depends on, are we talking about what we kind of serve for the admin API? Or are we talking about what the SDK needs to know about?
[00:11:01] Because an SDK has limited scope. It will always run in a certain environment. It doesn't need to know about multiple environments. So for an SDK perspective, we only have a very flat structure like you're either you are unable or disabled and then you can have activation strategies.
[00:11:18] Activation strategies can say it should be a gradual rollout. We should be sticky on the user ID or a tenant ID or something else to make it consistent user experience and that could be multiple variants defined like it should be If it's on, it can be red, it can be blue, it can be green, whatever. And these type of rules has evolved slightly but it's still kind of very simple.
[00:11:39] But then if you look on the admin API side of things, it has kind of exploded with the different versions because suddenly you support multiple environments and we had to add that into that. And you have so much more contextual information that you want to convey when you administer the flags. Like you have tags information, you have the project it belongs to, you have a lot more information that is useful when you're administering but for an application perspective, they have no value or little value.
[00:12:10] So that's why we try to limit what we expose to the SDK and the applications.
[00:12:15] Benedicte: As you said, the application through the SDK only kind of needs to know like, is this on or off for this user or for this like,
[00:12:25] Ivar: Yes, in a certain because an application always run in an environment, usually. Usually an application doesn't serve production and development at the same time.
[00:12:34] Benedicte: So it then knows, so it's only in that one environment. And if it's running in a, I don't know if you have this, but like you might have something like turn it on for certain browsers or turn it off for certain browsers.
[00:12:43] Ivar: Yeah. Yeah. That would be part of the rule set.
[00:12:46] Benedicte: And so it only needs to kind of get the, yeah. Just get read while the admin API is configuring all of this.
[00:12:53] And there you need to like tag it so that you, cause you can end up with quite a few of these feature flags. So I'm guessing the tagging is more for organizational purposes.
[00:13:02] Ivar: Yeah. Or convey some semantic context could also be, so tagging can be used for a lot of things. It could be also used for automation, right?
[00:13:09] You would tag certain flags that belongs together, and then you can use the tag to scope what you want to update and stuff like that. Yeah. Tagging is some kind of grouping or semantical context beyond just the definition of the flag. But then you also have obviously projects is also another way to organize the flags in Unleash.
[00:13:27] And then with the project, you might have different members of the project and you have permissions control on top of that. So it's quite complex when you think about it. Admin side of things, but from an application side of things, it's quite simple.
[00:13:42] Benedicte: So you do not expose the admin API. You have to go through the.
[00:13:46] Ivar: No, yeah, no, no. We do. So what we do is that we have a React app that's running directly on top of our admin API and everything in the admin API.
[00:13:55] Benedicte: You dog for the admin API and the other one, I guess.
[00:13:59] Ivar: Yeah, yeah, of course. And we also have open API specifications for all of that. So it should be possible to generate for your programming language. We do see that generating a client stub for, it works for some languages, but not for all. It's not that easy to generate for all it's kind of our learnings. It seems to be quite complex problem to do auto generating clients for certain programming languages.
[00:14:27] Benedicte: Oh, this is a whole different, this is another, we need to do another podcast on this, on that topic.
[00:14:33] But I'm sorry, I think I cut you off. You were saying you have a React application that is then running on top of your admin API.
[00:14:40] Ivar: Yes, exactly. And you can, and what we actually do inside of our, and we are quite, because we built a tool for developers, so we want to help the developers to automate.
[00:14:50] So when you do something in the UI, we actually show you on the right hand side, the API command to do the exact thing through the API so that you can start automating because obviously developers like to automate and just make it easy for developers to do that.
[00:15:05] Benedicte: So they don't even have to go through your or your admin site at all?
[00:15:10] Ivar: No, they can, but obviously they don't have to. And in certain cases, it's more efficient to not use the UI itself.
[00:15:18] Benedicte: So how did you make that decision of making two different APIs? Do you feel like it was, was it a gut feeling? Did it feel weird at the time? Like thinking?
[00:15:28] Ivar: Yes, it felt very awkward. So I made this decision quite early on and it was like in the beginning it was the exact same data. It felt like this is silly just to kind of have this. But then again, I was thinking, and I was, I actually was leaning into because in my kind of day job at the time, this was when Unleash was still an open source project and only that. And I already kind of knew kind of this read write type of separations and way to think about things.
[00:15:57] And I had this gut feeling that the needs for the client SDKs will be slightly different over time. But of course, when I did it initially, it felt just stupid because it was just the same data. It was the same data model. It was very simple. Very, very similar. And the only difference was obviously some permissions, but that would be simple to solve kind of with a middleware.
[00:16:22] So it felt a bit weird in the beginning. But it also felt right like, "okay, but what if I need to scale the read side differently?" Which is actually a real case today when we serve in a cloud.
[00:16:33] So hundreds of very demanding customers, it's kind of good to have the option to scale the read slightly different from the admin API.
[00:16:41] Benedicte: And also, as I imagine you say, like it will, they will evolve at different pace so if you do a change to the admin API, you don't have to re or create a new version for the read SDKs or the consuming SDKs. And that makes it more stable for the client's apps.
[00:16:59] While you often have more control over your admin side. While over your apps, like you don't want to be updating libraries all the freaking time as a developer.
[00:17:09] Ivar: Exactly. And also that there is another part to that equation, like at least on the customer side, we are working with some very large organization around the globe and their ability to update the SDK might actually not be matching our require, our needs in terms of innovation and adding new functionality.
[00:17:30] And we see it can actually take 6 to 12 months for some companies to be able to upgrade the SDK in all their applications. So we need to be very stable on the SDK side of things. But on the other side in the admin API, you can have much more. So still we want to be backwards compatible. We don't want to just break stuff and we are falling somewhere. And if we decide to change stuff, we will deprecate.
[00:17:57] For instance, if we create a new endpoint, that's a tactic that we sometimes use. If we slide, if we totally change our data model, like when we went from not having a concept around environments to actually have it. Suddenly the old feature flag API needed drastic changes. So we decided, "okay, we just keep it." It would default of one environment, but then we create the new API that actually take in environment as part of the consideration. And then we can have a clear deprecation strategy for the old API. We can communicate it clearly.
[00:18:29] We can provide hints when you use that API that this will go away in the next major version of Unleash. And we do roughly just one major version a year, but that's our opportunity to take away stuff. But then we can communicate that very clearly to our users that you're now using a deprecated API, it still works as before, you will obviously lose out on the new features, then you need to use the new API. But over time, you should progress your code to the new API. And we can also monitor the usage. So obviously everyone using our cloud, we can monitor who's using the old and we can inform them that probably time to look at the new API soon.
[00:19:09] Benedicte: And I guess this follows your idea about feature flagging, because then they can incrementally adopt a new. They can keep pushing features with the old one and, or they could keep, they can push features using the new API and then upgrade the old ones and just keep on pushing to production.
[00:19:26] While if you pull the rug under them, you kind of have to change the whole app before you can push to production. And that's against their philosophy as a company and as a person.
[00:19:37] Ivar: Yeah. You should think about feature management that like it's a feature, how you build software in general. To me, it's more like a continuous stream of small improvements. That's how you should think about it. But obviously over time you will learn that how you thought of the world is not exactly matching your new needs or new capabilities that you discovered. So obviously you need to clean up sometimes because maintaining all of those old way of doing stuff can also hinder you or making it very complex.
[00:20:07] Just both from understanding how your API works, but also in terms of just building new stuff, if you have to always consider how people did that two years ago, so at some point you just need to clean up and take stuff away when you are progressing.
[00:20:22] But I think kind of having this like, well thought through and not just break stuff because we discovered a better way to do stuff. That's kind of part of the cost of building a stable API is that you actually have to think about what does it really mean to do it slightly different? How can we be backward compatible?
[00:20:41] But because often you can, at least to some degree, support the old way and the new way in parallel. Obviously there are trade offs. But it's not like you have to always think, "no, no, you just need to do, use the new stuff and the old stuff is gone." It's huge or some cases, yes, there will always be exceptions to everything. But I feel like if we try a bit harder, we will always find kind of compromises where we can actually do both in parallel for a while.
[00:21:10] Ola: So what data model has changed the most for you since you launched Unleash?
[00:21:14] Ivar: I'm trying to think about it. I think, yeah, there is a few things.
[00:21:18] So I think how we think about users has changed quite a lot since I started the open source and how it is today. And users and users with permissions and groups and all of this has changed a lot.
[00:21:33] And in the beginning, when it was just an open source project, it was super simple. It was like, "yeah, you can just log in and you have an email and that's it." Why bother? Like you can do stuff if you log in. But obviously, building an enterprise version on top of this, there is quite a lot of needs in terms of RBAC.
[00:21:52] And it turned out that the first model wasn't very fit for that. So we had to iterate quite a lot on the data model around how we do users, but also how we do permissions, how we do groups, how we do roles, and how this fits together to actually work in a proper enterprise environment in terms of SSO and where you have the other roles and how can you do mapping of those and automate all of this.
[00:22:18] That has been quite a journey for me to kind of figure out a model that actually fits or is flexible enough, because it also turns out that enterprises tend to also have different expectations of how this should work. So you kind of need to find this balance where it's kind of usually can get to do what they want to do with this.
[00:22:37] Benedicte: So what have you landed on? I don't, I mean, I don't expect you to know exactly the table names and columns and stuff. But what kind of things, you've been talking about users and groups and like what does those things mean and what is a permission in your case?
[00:22:51] Ivar: Yeah.
[00:22:52] So what we are learning now is like you have users, of course. They have an ID, they have a name, they have an email or a username and stuff like that that kind of identifies them and other kind of meet the data attributes about the users.
[00:23:07] But then you have what we call a permission. So permission, anything that you do in Unleash will have a permission like creating a project or adding a feature flag to that project could be a permission or all of this is a permission. And so to do anything, you will need a permission to do that thing.
[00:23:25] Then we have roles. A user will always take a role and we have two levels of roles. So you have roles on the global resources. So global resources will be that you can create a project because that is not tied to a specific project. But it could also be creating resources that spans project. Like you can define a context field that is available inside of all projects.
[00:23:54] To do those things that is controlled by a root role. And then you have the project. So projects can also have what we call project specific roles. So you can be a member of a project that gives you certain permissions inside of this project.
[00:24:09] But you can also then customize that through custom project roles so that you can, maybe you're not allowed to update the configuration in production, but you might be allowed to update the configuration in development, for instance, through the role that you have and the roles kind of defines the permission.
[00:24:27] So a project specific roles will then define the project specific permissions. While a global role will have the global permissions.
[00:24:35] And then you have groups. So a user can also be inside of a group, but that is just a collection of users again. And a group can be added to a project and together with a role so that the entire group will then inherit the permission of that role that is matched to that group. So it's getting somewhat complex, but that's kind of high level.
[00:25:03] Benedicte: So I'm guessing a group can then be a company, but it can also be a division within the company. So you'll have like a hierarchy. So, yeah.
[00:25:09] And then you were saying with SS, sorry, with SSO. So they have their own login credentials and they're coming with their kind of authentication.
[00:25:17] And then you have to map that to your, then authorization models through the permissions. I guess, like if I get my word in.
[00:25:24] Ivar: So you can do, you can define these rules in part of configuring SSO. You can define either you can just default to a standard root role, or you can map the user to a certain group that already has a root role defined.
[00:25:39] And you can also pick up the groups from the group information from the SSO token itself. There are ways to kind of facilitate these mappings. So that you can automate it slightly more. And typically if you are big, big enterprise, you would like to like everyone or you want to standardize that in your identity provider, who belongs to which group, and then you can just automate so when they log into Unleash, they will be assigned the correct group and the groups will then have the roles that gives you the permissions that you need.
[00:26:13] Benedicte: I was thinking back to all our episodes and I feel like the whole podcast series about data models in the wild could just be like user modeling, payment, and permissions is a pain. Like that's what I'm getting from all of these conversations.
[00:26:30] Ola: But that might be because we've been interviewing everybody.
[00:26:34] It's like, it's not like. They're not like actually what I would call a startup, like in the Norwegian sense, they're all like small companies with big users, with big, big customers. And maybe if we had interviewed somebody who was.
[00:26:51] Wait a minute, no, no. This one lady had like actual consumers.
[00:26:59] Did she also have the same problems? Yeah, she did.
[00:27:04] Benedicte: She had some of those issues to begin with, but I think you're correct in the way, like the same way your project started out as an open source and then kind of what we would call indie hacking. And now you're kind of graduated to a proper company.
[00:27:18] And I guess when you're like more playing around, you're like, "well, I just need a user, like it's fine." And then you don't think about the enterprise implications of your choices. But I'm guessing if you're like VC backed from day one, like maybe you think enterprise from day one, cause you know, that's your end goal to get enterprise customers.
[00:27:41] But yeah, it's been interesting to see that that's like or is it because we think it's easy? Do you think it's because you think about feature flagging like this is very complex. Like I need to get this right. Like this is my core product. This like admin stuff, like how hard can it be?
[00:27:57] And then you get to it and you're like, "Oh, it's hard."
[00:28:00] Ivar: No, I think I learned it quite early on that to succeed with kind of when we start exploring kind of is it possible even to build a company on top of Unleash? We learned early on because we were just talking to people who reads out actually, and within a year, we talked to more than a hundred companies.
[00:28:20] And we learned very early on that you kind of not having these enterprise features, that then it was not possible to sell to them. You're like, you just have to have that. And they were interested already with what we had in the open source, but kind of the feedback they always gave us like, "yeah, this is nice. But we need this SSO stuff."
[00:28:39] We need this permission stuff. We need to have RBAC. We need. And it was very easy. And I, of course, I understood, but I was like, I remember like telling them when we started for real, it was like, "okay, then first year we probably mostly built enterprise features for the first year." Like that's where we need to focus because it's not that they, that's not why they actually, or that's why they can buy your product if you get all of that right.
[00:29:06] And then they can talk about if what you actually offer sells an important use case for them. But if you don't have the other stuff, it's really hard to kind of buy your product. So it kind of, it's a license to sell. It's almost like the same thing for compliance stuff, like SOC 2 and all of that.
[00:29:22] It's super a lot of work for us to kind of document all the policies and doing all that stuff. But it's kind of a validation that we actually care about this stuff. And it's making the buying decision so much easier.
[00:29:34] And this is just, "yeah, we have it. We have a external auditor. It's all green. It's everything is checked out and you can check it here."
[00:29:42] Then we don't need to have that conversation. It's like, "yeah, it's okay."
[00:29:45] Benedicte: And then you can have the proper sales conversation, which is, "do you need this?"
[00:29:49] Ivar: Exactly. Which problems are we going to solve for you with this tool?
[00:29:52] Benedicte: And are you ready for this tool? Which I guess is also something they need to figure out after procurement has said "okay" on every, on all the enterprise stuff and you get through that.
[00:30:04] Ola: But then that could actually be a product and people could sell. So you could have started out, like when you started out, instead of talking to all the companies, you can just made a phone call to somebody who knew how to set it all up.
[00:30:18] And then just basically they could have told you, "yeah, you need to do this with permissions and blah, blah, blah."
[00:30:24] Do you think? Would you have been interested in that or would you have been thinking, "Hmm."
[00:30:29] Benedicte: I think those, I think those services do exist. I've seen some.
[00:30:33] Ivar: Yeah, they probably do. But I think, it can also be slightly different for everyone. And for us, this was also to learn about the market. What is the willingness to pay? Which type of companies?
[00:30:44] And obviously we were, if kind of the market for us was more SMB and smaller companies. And we see that already. We also have a lot of SMBs using our product and obviously their needs are a lot simpler in mission systems.
[00:30:59] Benedicte: Fairly large SMBs can have like, "Oh, we'll just share one login credential. It's fine."
[00:31:04] And I'm always like, "it's not fine." Like you should all, you should have the team members, like this is not okay. But like they're like, "yeah, it's fine. We'll just share this one login. That's good you know."
[00:31:13] Ivar: We're saving dollars.
[00:31:14] Benedicte: We're saving $50 a year. So we're just going to have one login credential. It's like, don't save on that, but that's yeah. That's different. But yeah, they have that.
[00:31:23] Ola: I'm not going to ask this now, but that would be an interesting conversation.
[00:31:25] You know, how do you actually get in touch with these enterprise companies?
[00:31:30] Ivar: Yeah, so I think, it depends. I can answer shortly, but at least in the beginning for us, because the open source were already out there and known, it was kind of inbound basically.
[00:31:40] So people were Googling "Unleash Feature Flag." They were not googling "Feature Flag", they were Googling "Unleash Feature Flag." They found our webpage and they reached out. That was kind of, for the first year, that was how we did sales. We didn't have marketing, we didn't do anything. They just called us and wanted to buy.
[00:31:55] But obviously now the
[00:31:56] Ola: Because you had open source out there.
[00:31:59] Ivar: Because of open source and already thousands of companies were using the open source in production. We have the main people knew about us. They have experience with the tool. But obviously now that we are scaling, we now have a marketing, VP marketing and we are doing marketing.
[00:32:14] We're trying to do more out on them. Obviously that's super hard. That's kind of finding the right people, finding companies with this problem that matches kind of our value prop. And obviously we haven't nailed all of that down. I have to be transparent on that. It's super hard. There are tools out there to help you actually.
[00:32:33] It's fantastic. It's tools that you can basically enter like, I want to have a company with complex deployment scenarios. I want that those companies to have hybrid cloud, and then you can find companies that actually matches those criterias. It's super fantastic. And then you need to kind of figure out and do all your research are they in the modus? Who should we talk to? And then you need to just go talk to them. It's a lot of, that's called outbounding.
[00:32:58] It's a lot of work, but actually works if you just know what you're doing.
[00:33:04] Benedicte: It's doable, but you got to do the work.
[00:33:06] Ivar: Yes. But we are lucky because we have the inbound stream from the open source still.
[00:33:11] So it's kind of, that's just to fuel the growth even more, of course.
[00:33:15] Benedicte: So to tie it back to, I guess you kind of mentioned that early on, but what would you say is your proudest accomplishment in your data model journey?
[00:33:24] Ivar: Yeah, I think it's that distinction that we did on the admin API and the client API, I think actually to emphasize one more thing around this and what's possible when you also really think hard about backward compatibility and forward compatibility.
[00:33:41] There is actually one really proud moment for me. And we were building a new capability called segments. And segments is a way to define some reusable groups of people with some rules. Like it should be, maybe you would have a segment, everyone in Oslo could be a segment and you would define that as a segment of the segment, know how to target that. And you could reuse that across feature flag configurations. But when building that, obviously to really make it scale kind of the SDKs needed to know about segments to make it really work, because if not, how would you be able to use this?
[00:34:17] And obviously then to use this new capability, we have to tell all our customers and users to actually upgrade. Unleash. But what we figured out, because we were building segments on top of a construct that we already had, which is called strategy constructs, where you basically could do similar things, but kind of with one off rules in the configuration itself.
[00:34:37] So what we figured out is that we could build this so that And we added information in your SDKs if they supported segments or not, they would tell us when they connected back to the API. And if we detected that an SDK didn't support segments, we would rewrite that to strategy constraints on the fly when sending the configuration down to the SDK.
[00:35:00] Obviously, that has limitations because it can very easily explode in terms of the payload that you have to send down. So we Also had very restrict kind of limits in the beginning, but this allowed us to start validating the new capability called segments. Without having to even tell customers to upgrade their SDK, we didn't even have to implement support for this in all SDKs immediately so we could validate that this new capability was working, that it worked the way we wanted it to work.
[00:35:29] We could re uh, do better releases, enable it for some customers, get feedback on it. I mean, we were confident we could build purpose support in all the SDKs. We could then publish those and we could actually wait until. We had a good enough adoption of a new SDK before we actually started to remove some of those soft limits that we had in first so that you could have bigger segments, you can have more segments and all of that.
[00:35:56] Benedicte: Wow. That sounds, you've, I like how intentional you are. Thinking through these things. It's very, I'm a little jealous. And I love that we can learn.
[00:36:09] Ivar: I have a great team, it wasn't just me.
[00:36:12] Benedicte: No, but like a little bit from the beginning, and like taking the time, it feels like you then also as a team, take that time to think things through and not just be like feature, feature, feature, like you.
[00:36:24] Like there is an intentionality behind the way you work and the way you think that I think is very admirable. And I think, you know, you are seeing the benefits of now.
[00:36:36] Ivar: But we have to, because our tool is controlling. Companies production environment. So if we mess this up, a lot of things is going to be off out there.
[00:36:47] Benedicte: Yes, but I have met people who sell similar, not the same, but to the same kind of people with more of a, what's it called? Is it the less unfair, like you know, with, with less of a feeling of responsibility or like less.
[00:37:04] I don't know what that one is, but like there are companies selling to enterprise and who don't take that responsibility as serious I guess was what I was trying to say.
[00:37:15] Ola: Yeah. So if you could time travel back in time, what would you undo with your data model?
[00:37:22] Benedicte: Like if there's something that was, would have been easier to have just done right from the start. You can say nothing if that's true.
[00:37:31] Ivar: Yeah, there are some smaller things, but I think kind of in general it's always things that could be better, I guess.
[00:37:40] I think if I were going back, I think it's very small things like, Oh, we, for instance, we have this concept of variants and we decided to put that on kind of the feature flag level. Like a flag has multiple variants and there was an intentional thought around this, that this belongs to the flag and it should always be the same across all environments and all of that.
[00:38:08] 'Cause it's easier, I thought. But then we saw that it actually took away a lot of flexibility. So we are actually now in the next upcoming release, we are actually moving that or deprecating that way of doing it. We will still support it for the foreseeable future, but we are moving that into the configuration itself because then you can be even more specific on how you target the variants so that you can have like, for people in Oslo, I want them to have the red version while people in Stockholm, they should have the blue version and kind of moving it into the configuration itself allows us to have the ultimate flexibility also for variants.
[00:38:47] And obviously doing this right from day one would make it a lot easier now, but obviously we were able to implement it anyway, but now we have to support both ways of doing this for a very long time, because people already use this in production. So we cannot, and there is no easy way to also, sometimes we think about, can we just migrate it directly in our database to the new model, but then there are certain things that will be different.
[00:39:13] So we might just have to support the old way, at least on the configuration side of things forever, I think. But maybe we'll stop allowing you to do that in the UI, in the API, even in the future. I don't know, but for now you can do both. So we have to see the adoption first.
[00:39:29] Ola: So do you have a tip or a trick to offer from your real world data model experience?
[00:39:37] Ivar: Try to keep it simple, KISS. It kind of always comes back to me when we try to do very smart things too early. Allow yourself to play with stuff, allow you to have experiments and particularly when you're building something entirely new, often that is a new API. And the trick that we use is just all new API endpoints.
[00:39:58] We are working and we just tag it with the experimentals. If you look at our open API specification and you see something experimental, you should expect that to change at any time. So you shouldn't depend on that. But then get it out there. Just try it out. Don't try to think of all the edge cases up front.
[00:40:14] What is the simplest thing you can do to model something that gets the job done? And then you can get a feel of it, get feedback on it, kind of try to use it in the scenarios you think it's going to be used in.
[00:40:28] Then you will learn maybe there are some weaknesses that you can improve and then you can do this as a more kind of. Again, I think everything should be incremental because you will learn more after you learn more about the problems you're trying to solve and then you can take the liberty when you make it kind of this is now official, then you can do the really proper kind of modeling for it.
[00:40:49] Benedicte: 'Cause if you come up with a, like the simplest model you can think of to make it work, you push it out there and then people start saying, "but what if and what if? Or but what about this case?" And then you can see, do we need another model? Do we need to like, how can we solve these edge cases, but while still keeping it fairly.
[00:41:08] Ivar: Exactly. And in my experience, when our team works like this all the time, and they tend to be that very simple first model that tends to be very close to where we land. And it's simple to build and it's simple to use because it's simple.
[00:41:22] Benedicte: And then it's simple to explain.
[00:41:24] Ivar: Yes. So I think simplicity and not try to be too smart always.
[00:41:29] I think that's kind of a fallacy and can actually just put you down the rabbit hole and it's super hard to build and it's super hard to understand. And it might even have bugs that you didn't foresee.
[00:41:42] Benedicte: I also read somewhere that somebody called it read me driven development, where you write the kind of the documentation first, like how are you going to explain this?
[00:41:52] Because then very soon you realize that your smart way of doing it is just going to be too hard to explain. So if you try to like write the documentation in your case for the end point, but you know for other situations, other things, like there might be an end user and you're trying to explain to them that this doesn't work because of some database constraint they shouldn't know about.
[00:42:14] Then okay, then we need to rework, like we need to rework how we're doing this because it's not understandable for those who will use it if we did it that way.
[00:42:23] Ivar: Yeah. And that would also allow you to actually get the documentation because that's hard. It's easy to neglect the documentation in the first place.
[00:42:31] So we don't do that. We do something similar though. So we a rule that we can, when we build new stuff, at least we cannot make it kind of official what we call general available before the documentation is also written. But we don't usually don't write the documentation up front. So maybe that's something we could try on some new features.
[00:42:50] Benedicte: Yeah. Don't tell your developers I said that because I feel like that's going to backfire.
[00:42:57] But I guess that's kind of it for this episode. So we're wondering where can folks find out more about you and Unleash?
[00:43:07] Ivar: Yeah, so for Unleash, go to our GitHub. Github. com forward slash, backwards slash something slash, Unleash.
[00:43:14] And for me, I'm usually ivarconr on all the social media.
[00:43:22] Benedicte: Cool. And you can check the description for those links. And thank you so much for sharing your data model stories with us today, Ivar. I've learned a lot. It's been a lot of fun.
[00:43:34] Ivar: Thanks for having me. This was fantastic.
[00:43:36] And I like your hat, Ola.
[00:43:37] Ola: Yeah! Isn't it great? Isn't it great?
[00:43:40] Ivar: Yes.
[00:43:41] Benedicte: So for the people listening, both Ola and Ivar is wearing their Unleash hats.
[00:43:47] Ola: It's just a coincidence.
[00:43:49] So welcome back later to Data in the Wild. We don't really know when it's going to be, but it will be! And it will be data models, tips and tricks used by our fave indie hackers, just like today.
[00:44:05] Benedicte: See you around the interwebs.
[00:44:06] Ola: Bye.
[00:44:07] Benedicte: Bye.