In this episode of Build to Succeed, we sit down with Lucas Josefiak, founder of Widgetbook, to discuss how Flutter teams can improve design collaboration through scalable design systems and better developer tooling. Lucas shares how Widgetbook helps teams align on UI and design decisions, reduce friction between design and engineering, and “shift left” to catch UI bugs earlier in the development cycle. The conversation highlights the ROI of investing in tooling that speeds up iteration, improves quality, and enables more consistent, cohesive product experiences as teams and apps grow.
Transcript
David DeRemer (00:00.046)
All right, Lucas Josefiak, thank you for joining us today. It’s pleasure to have you on the podcast.
Thanks for having me, David DeRemer.
David DeRemer (00:25.838)
Awesome. So I always like to start by asking what is something you like to do outside of work outside of your day job outside of technology that brings you back and helps you to be better with technology and on the job.
So what I actually really like to do in my free time is to stay away from technology and to really immerse myself into nature. And also I’m doing sports. Ideally, I’d like to combine both of them. So basically, one thing that I really like to do is, for example, hiking up some peaks and summits. That’s something I really enjoy.
So you live in Germany, Correct. And you grew up in Germany and play soccer and hiking. Does that give you sort of like a competitive spirit that you think has kind of helped you in the startup world?
Yes.
Lucas Josefiak (01:20.302) Yes, definitely. I mean, in Germany, soccer is by far the number one sport and I grew up already as a small kid playing it. And if you are doing any sports competitively, you like to win and you like to get better. So it teaches you discipline. and you have to train a lot. also, especially in soccer as it’s a team sport, it also teaches you that
being a team player is quite important. It might help you if you yourself, you have a bad day, your team might be able to help out. But also if other team members don’t have the best day, maybe you can shine and you can make your team win, even though your team members might not have the best day. So I really think that sports is something really, really helpful for everyone, especially as a kid learning.
to be competitive and being disciplined definitely helps.
wonderful. There are so many business books and people are constantly looking for advice. When you read LinkedIn, there’s all this inspirational stuff about how to be better in your startup or in your business career or whatever. And one of the interesting trends I think is what really seems to help people is just actually not doing work sometimes, you know, getting out in nature, doing something else competitive that you can learn from and bring into it. I think that’s cool. One thing you must be really good at headers because I know it’s not obvious a lot of times from the virtual videos and stuff, but you’re quite a tall guy.
which I think is something that is surprising when people meet you in real life for the first time. that’s always must’ve been a nice advantage.
Lucas Josefiak (02:59.82) Yeah, that’s true. mean, I’m so I’m nearly nearly two meters tall or six six. And yeah, that’s, was quite an advantage growing up. And I mean, I’ve, I’m used to being tall pretty much my my entire life, but especially in the age about 15. I grew like 30 centimeters in six weeks. Whoa. And basically, after the age of 15.
I stopped growing, fortunately, so I think I’m tall enough. But basically, I’m familiar or I’m used to being tall pretty much my entire life.
30 centimeters in six weeks talk about like the hockey stick growth curve.
Yeah, it was quite tough.
Yeah, tell us a little bit about who you are, your personal professional journey and how you got to be doing what you’re doing today.
Lucas Josefiak (03:51.566) Yeah, so I grew up always excited about exploring new stuff. I mean, we mentioned, hey, I like to do sports. I tried all sorts of sports. I really liked being in nature, tried lots of stuff there. And that also basically went through my entire childhood. So I was always very curious. But simultaneously,
I’m also competitive, trying to always get to the edge and trying to get to the best extent possible. after high school, I wasn’t really sure what I wanted to do. I always knew, hey, I would like to have quite independent life because I always wanted to be the person in charge of my own life and basically being able to decide what I want to do.
And that’s why entrepreneurship was something that struck to me quite early on. And I decided, hey, I want to study business, something that is going to be important anyways. But very quickly during the studies, noticed, okay, only the theoretical part. not everything. And I learned quickly, I don’t want to only be the person selling stuff, but I also want to be the person that can
in the end build products. So I taught myself how to code as well. And pretty much at the beginning of my studies, I had a great course at our university, which was a corporate entrepreneurship seminar. So a big enterprise came to the university and they brought 20 engineers to the university and they basically mixed our group with 20 people from that enterprise with 20 students.
And we should solve a problem for them. And then in just two days, we came up with a solution for the problem, pitched it in front of board of directors. And they really liked our solution. And they also liked me personally. And then they were like, hey, Lucas Josefiak, why don’t we incorporate that adventure and have you you join the team? And I was really excited about it. Back then I was 19, 20 years old. And yeah, I was immediately hooked.
Lucas Josefiak (06:14.862) by it and was like, perfect. I mean, that’s exactly what I want to do. I want to build products from there, from the ground up. In the end, unfortunately, that parent organization went into financial struggles. And then they decided, hey, no matter how successful we were, we’re just going to spin the company in. So it’s not going to be a spin-off, even though we were already profitable with what we were doing. But then I decided, okay, I’m 20 years old. I’m not going to work for an enterprise.
So I’m going to basically pursue my own stuff. And then I started building various side projects. But at some point I met my today co-founder and CTO Jens. And Jens basically brought me to Flutter. So in that corporate startup, but also in other projects, I used to do web development. And on the web, I always did develop in
And so it was mostly React. at some point I did some client work and we got a bigger client eventually. And it was already together with Jens, by the way. that client eventually needed not only an MVP, but like the real web app. then we were like, okay, we need to build something maintainable here. And then we stumbled upon the concept of Storybook.js. And that was quite exciting for us.
We really liked it and the customer liked our work. And eventually that very same customer needed a mobile app as well. And we tried to React Native. We didn’t like it that much, but Flutter was still super early. But Jens was like, hey, let’s risk it. Jens, I don’t actually know how he found out about it, but he stumbled upon some article probably was very early 2020.
We tried Flutter and it worked well for what we wanted to do. Worked a lot better than React Native. And then we switched to Flutter and our customer liked it. And then we’re like, okay, perfect. And we could learn something new here. So basically me always trying to explore new technologies was satisfied. The customer was satisfied. So perfect match. Yeah. And then that’s how we basically emerged in the Flutter ecosystem.
Lucas Josefiak (08:40.654) And then because we knew Storybook.js is a great tool in the JavaScript and web ecosystem. then eventually that client that already had a Storybook for the web with us was also now sure, the mobile app should not only be in the MVP stage. So basically they committed to the app for multiple years and then it was clear,
Storybook solution would make a lot of sense here. And there wasn’t a storybook solution for Flutter. So we were like, hey, let’s build that ourselves. And when we decided to build it ourselves, we then decided to give a presentation at a local meetup and basically presented what we are doing. Now, we back then it was still like the storybook for Flutter that we are doing. And people really liked it. And we’re like,
came up to us after the presentation and were like, hey Lucas Josefiak, can you share it with us? And that was the moment where we then decided, okay, perfect. Let’s do it. Let’s open source it, make it available to other developers as well. And that was basically the foundation of Widget book. And as a side note, in Flutter, David DeRemer, you are very familiar with that. In Flutter, everything is a widget.
And that’s where we decided to then call it Widget book.
That’s that’s awesome. Can you give us a quick for maybe for people who haven’t encountered Widget book or storybook, the general sort of overview of the product and sort of like who would use it, why they would use it, and the benefit they get.
Lucas Josefiak (10:20.782) Yeah, a Widget book or also a storybook, in the end, both are open source packages. So storybook is for the web versus Widget book is for Flutter. And the concept is that developers can build all their widgets or, in the beginning, their core components in isolation. And the great thing about building components in isolation is that you can build them without
thinking about any outside dependencies. So usually if you would build a new widget, you would have your simulator fired up and you would build the widget directly in the screen. And the issue is if you build it into the screen, the screen itself already has some dependencies and that can be quite cumbersome to still build it reusably. And the benefit then of having a widget book
is Widget Book is your new, basically like a preview environment for you. You can really focus on building just this widget without any outside dependencies. And then we have some concepts in Widget Book that are called knobs and add-ons that allow you to test the widget basically in every single possible configuration it could have. So you could test every different, or you could preview, first of all, every different state that the widget has.
And then you can build it in a way that you can easily on the fly dynamically change all the widget parameters. For example, if you have a primary button, the primary button has, for example, required text property. And then you could configure it in a way that you can dynamically override this text element in the widget book preview environment.
to test, example, how does a primary button look with a longer text input or with a shorter text input, but you could then also test it in other global properties. So, for example, on different device sizes, different text scale factors, different themes, different locales, and much more. So, in the end, it really allows you to build your components in isolation. And while you’re building your components in isolation, all of those components
Lucas Josefiak (12:45.038) are getting cataloged. And that’s why Widget book is being used mostly by teams that want to build their own custom design system, because it allows you to, first of all, build the design system components, but to then also keep the overview of all these design system components, because in the end, what you receive is kind of your own Flutter design system. And if you then extend it even with entire pages, you can also catalog all your app-specific
widgets in Widget book and that helps in the end your developer to build quicker and build maintainably. But it also helps all the other stakeholders like designers, QA testers, product managers, to really keep an overview of everything that is being developed.
Nice. So to restate that and replay that a little bit, make sure we’re all on the same page. you in Flutter, everything is a widget, right? So when write your code, like technically everything’s a widget. But really, for our purpose here, we’re talking about like user experience elements on the screen, a button, an input field, anything that you would want to display and have like a reusable component that you’d use throughout your application. Right. And you mentioned the word design system. And I think that this is another interesting word for us to like really define well and make sure that people are aware of.
I think designers and sort of people at scale have this context of design system, but maybe a small independent development team or one or two developers maybe aren’t thinking about this idea. And so how would you define a design system? What is its value? And maybe like, why should we build them even if it’s just like a one or two person team?
Yeah, so a design system is, in the end, one consistent common language that you establish for your entire product team. And a design system is not only a list of components that’s quite important. It’s basically a few different things. So usually, you start with your
Lucas Josefiak (14:48.59) Usually you start defining your styles in your design system. Once you have your styles, with styles, mean stuff like your font that is being used, but then also, for example, your colors. So basically all your assets or from a design language speaking, all of your tokens. And then once you have your tokens defined, then you can think about your components.
And once you have your components defined, and here usually the term that is being mostly used is the atomic design principle. you are starting with atoms, and atoms are basically the smallest unit possible of your components. in chemistry, where an atom is the smallest unit.
in your app, your smallest unit of a component would then, for example, be a primary button. And then once you have your atoms, you basically compose multiple atoms together into a molecule. And the molecule could then be something like a cart, for example, so where you have multiple atoms.
that then compose together to one molecule. And then you have organisms, which are multiple molecules. And then you get to entire pages. And that’s usually how you structure your design system.
Very cool. if I so Who is the primary as you mentioned designers and developers and QA people and stuff and so like people that might be familiar with all these tools that are out there there’s like Figma and the whole Adobe suite of things which ironically those made it maybe were meant to be one thing at one point but they’re not anymore. You have obviously your code and a developer might just be writing this in their in their software directly right. Doing these things and then you have QA and
David DeRemer (16:56.12)
concept of golden test and all that. So what’s like the workflow, generally speaking around how a team uses widget book and where does it sit in the ecosystem of all these products?
Yeah, perfect. We actually wrote an article about how you can build your own custom design system as a Flutter team. We can maybe link it in the show notes. But first of all, basically to go through that workflow, usually the design system process always starts with the designer. And the designer, I mean, you mentioned Figma already. Figma basically made it.
I don’t know, David DeRemer, if you still have customers with VGV that are not using Figma. I doubt it. Basically, everyone is using Figma right now. Usually, it starts with the designers who are creating the design system in Figma. Here, I mentioned they will start with tokens, but then also with their components. Then the next step would then be, we need to do with the design handoff.
And here, Figma launched a great solution last year, which is called Figma Dev Mode. So finally, as developers, we also get a real seat in Figma now. And with the Dev Mode, the designers can mark certain sections as ready for development. And that’s then how we as developers get…
and notified it and then know, okay, perfect. That’s exactly what we can implement right now. And once that is done, then it’s on the developers to build the design system in Flutter. And first of all, what we would do then is we would create our style foundation. So I was talking about the Figma tokens earlier. So it would then be the job of the developers to basically translate those Figma design tokens into Flutter code.
Lucas Josefiak (18:55.04) And here, I mean, we can go into a lot of detail on how you could do it. You could basically generate some Figma tokens. You could basically generate the theme extensions based on Figma tokens. If you’re interested in that, just check out the article that we have. I think it would go a bit too far for this podcast episode. But then basically you would end up already with your own style foundation. And once you have the style foundation,
You’re in the perfect spot to then build your components or you build your component library then in Flutter. And that’s something that you can do with Widget Book. And Widget Book here is an open source package, so it’s free to use for Flutter teams. And you would then use it to build all of your components in isolation. And by building your components in isolation, you would then basically receive this catalog.
of widgets. what is great about WidgetBook is that we built WidgetBook in a way that you can mirror the Figma naming to Flutter. So all the concepts that we introduced in WidgetBook basically mirror our concept in Figma. So just quickly naming it. So everyone that is already familiar with WidgetBook will quickly realize it.
and the ones that are at least familiar with Figma, then know, hey, we have the equivalent, basically. So in Figma, you have a concept of variance where you, for example, have a primary button, but this primary button has a few different variants. For example, default, disabled, pressed. These would be three different states, and these would then be three different variants. And in WidgetBook, you could have different use cases for that. So that’s the concept that we have.
Then in Figma, you have something called variables, where in Flutter, you have theme data. In Figma, you have variable modes, whereas in Widget Book, you have add-ons. In Figma, you have component properties, whereas in Widget Book, you have knobs. And that really allows you, together with your entire team, to really speak the same language there to make sure that every stakeholder really gets quickly familiar with Widget Book and also really, feels at home there.
Lucas Josefiak (21:17.208) So that is basically the core of how you would build your design system initially. Afterwards, we will probably talk about that later. But otherwise, we could also talk about that now is you would not only build, but you would then also try to maintain your design system long term. Because usually, as we all know as software developers, it’s quite easy to build something initially from the ground up.
but to then ensure that we can maintain it long term, that’s usually quite a challenge.
Right and that’s where it gets complicated if you’re embedding your UI in the code itself having these components all over the place now somebody comes and says hey we want to change the buttons from being rectangles to being rounded rectangles and you’re like okay now I need to go find every place where I created a button and do that but if you have your design system well established you’ve got your figma the designers are making changes in figma that connects into your components in Widget book you can really easily do that and then when you make those changes boom
they’re spread throughout everywhere a button is used and that’s how your design system works to play. So question that there’s been a lot of talk over the, over the last year or so around the Flutter team’s decision to remove Cupertino and Material from the core framework. And I think the idea that they’re talking about is largely what you’re getting into here, which is these types of tools like Widget book and building a design system is very important. If you’re the type of company that wants to build your own design language for your application, where maybe you don’t want to just mimic the
material design spec or use just the default iOS design system that they provide. This is its own thing. So how do you feel about that decision that Flutter has done? how can companies really start to think about this idea of building your own design system and design language to drive your app and brand experience?
Lucas Josefiak (23:05.214) Yeah, so I think, honestly, it’s a great decision for multiple reasons. Reason number one is it really allows the Flutter team to focus with the team’s resources that they have on the most important stuff. And If we’re talking about the value proposition of Flutter, is really you build it once, and then you can ship it everywhere. And the value proposition of Flutter
Therefore, you have the same user experience across every different platform. It’s something that is very hard to achieve with other frameworks. And to my understanding, it’s a great benefit of Flutter. That’s why teams choose Flutter. And that’s why we should really play to its strengths. So with Flutter, we should not try to make it basically as native as possible.
on every various device, but we should basically say and be very confident about the app that we’re building. Hey, we believe that’s the best user experience that we want to offer our customers. And that’s why we build our own design system that is custom. And no matter if our user is using iOS, if he’s or she’s using Android, if it’s web, if it’s desktop, basically whatever platform you can imagine.
We always want to achieve the same user experience, the same outstanding user experience. And that’s what you can do with Flutter really well. But if you want to do that, you have to build your own custom design system. If you would rely on material, for example, on Android, and you would then have to rely obviously on Cupertino on the iOS side, you would have two different user experiences. And that really, to my understanding, goes against
the whole purpose of Flutter.
David DeRemer (25:04.684)
Yeah, I agree. I My joke about React Native is that the value they always claim about using the Native components or even with you know, KMP and all these things of like, no, no, the the design the presentation layer is using Native components. Like, well, the problem with that is the Native part, because actually, this is where you get a lot of variability, you get a lot of extra maintenance overhead.
You also get things where, for instance, like, let’s say we’re using Native components in a cross platform framework. Well, now all of sudden I have to worry about all the different variations of the operating system going back as far as I would support in terms of like, maybe Android has changed their native design language over the last 10 versions of Android. If I’m supporting all of those, I’m going to have to worry about what does my app look like nine versions ago in Android because I’m using the Native components.
If I’m using Flutter and my own design system, my own branded design ecosystem, and since Flutter ships its rendering engine with the app, it’s going to look the same everywhere, regardless of what version I’m on. And I think that’s an incredibly powerful strength that sometimes people point out like, if you don’t use Native tools, you’re not going to get the latest iOS design language. And I would argue like, yeah, that’s a, that’s a feature.
Yeah, exactly. It’s even go as far as it is not a feature. It is kind of the feature. Yes. Yeah.
Totally agree, totally agree. So I think that’s a really important concept. And I think that’s one of the most like, know, liquid glass comes out and the whole React Native community is like, you know, you’ll never get that with Flutter, Flutter, you know, and it’s like, but you’re missing the point. You’re kind of comparing apples to oranges. And I think there are definite reasons why you’d use React Native and you have to be aware of the pros and cons of that. And there are definitely reasons why you’d use Flutter and you have to be aware of the pros and cons. And these things are not, you know, exactly comparable. They’re quite different.
David DeRemer (26:56.302)
I’m curious, a widget book, right? When you think about these design systems and you’re saying like build once run everywhere, ship it everywhere. I think that’s an important concept because we also tend to default to like the idea of just mobile. Like I’m using Flutter or react native or any of these tools to build a mobile app. And I’m going to get the same app, you know, and some efficiencies and code, but we all know that Flutter can also run on all these other places from desktop and web to even in the dashboard of a car.
or an embedded device in all these different places. Does Widget Book also help a team who’s thinking about broader picture? I’m gonna take my Flutter app to all of these different places. Does it also scale with those?
Yes, we do support those cases and basically how you can envision it. mean, all of you, could go to demo.widgetbook.io to see a demo of WidgetBook yourself. And then you would see, and we have a view pod add-on. And that view pod add-on basically allows you to preview your widgets across a variety of different devices. And the primary devices.
that we support are Apple iOS devices in the end. We also try to support every Android device, but as you can imagine, David DeRemer, there are quite a lot of options. That’s why we introduced the concept of basically allowing the user to add their own devices as well. But then you basically have the chance to test it on every device size that you like. So you could preview your widgets on
whatever mobile device you like, could preview it on a desktop device, on a web device. So basically, we even have customers that are using WidgetBook for their smartwatches. So basically, any device type is supported.
David DeRemer (28:53.262)
That’s amazing. And I think that really gets to the real power that I think we’re still trying to educate the world about what Flutter is really capable of. And I think it’s obviously there’s a huge benefit by one get one free for iOS and Android. But when you think about the idea that I can build just components even like what you’re describing design system. And now all of sudden when I want to go off and do something totally wild I want to build a smart thermostat. You know I can use the same components and see how they work and just build for something totally different on a
Raspberry Pi or whatever it might be. So I think that’s super cool. In terms of we I think the designers and developers and those types of people who are listening there, you know, probably really getting this pretend now we’re talking to a business stakeholder, you know, the CEO of a company or chief digital officer or something like that. And someone’s coming to them with a, you know, with widget book and saying, hey, we really need this. And they’re going to start asking like, ooh, you know, what’s the ROI, you know, what kind of improvements, what is the cost benefit analysis? I’m going to get out of this. What
What do you, from a business perspective, what do teams get out of this besides the, the overall sort of improved developer experience?
Yeah, so basically what is important to state here as well is so far we’ve talked about the open source widget book. So what you can do with that to build your design system. But then when it comes to maintaining the design system, it’s sometimes quite tricky for teams. And especially what you mentioned earlier, David DeRemer, you basically said, hey, we might change components over time. then
We, for example, changed the border radius of our button. And as developers, we might really know, on the homepage, I know it changed. On the profile page, I know it changed. But, I forgot also the checkout page was affected as an example. And that’s why what we do as well, we offer Widgetbook Cloud. And Widgetbook Cloud is a visual regression testing platform.
Lucas Josefiak (30:58.162) for Flutter Teams. So you can basically imagine it’s like managed golden tests. golden tests allow you to take snapshots or screenshots of your app states. And you can then run a regression test to compare if a widget in the past basically changes over time. So you basically take
the base build. You take a screenshot of the base build and then you get the head build and you take a screenshot of the head build and then you run these UI regression tests to then figure out if there was a change, yes or no. And what we do then with Widgetbook Cloud, you just use Widgetbook. You don’t need to write any additional tests, so you don’t have to write golden tests anymore. And we automatically generate these golden tests for you.
And we then are integrated in your Git providers. We support any major Git providers, so like GitHub, for example. And then we are integrated in your pull request and we automatically run a GitHub check there. if your widget, if there was any visual change, we would basically have a pending check there for you. You could then…
Select this check on GitHub, you would be navigated to Widgetbook Cloud and you would then see a list of all the visual changes that were affected by this one change that you made. So in our case with this primary button change where we changed the border radius, we would then see, first of all, just this component. If it would be included in some molecules, we would see the molecules. If we have entire pages that are affected by this change, we also would see all of these pages.
And that is basically the other product that we set on top of the open source package. So I think that’s important just to give some context for the RIS. David DeRemer, do you think that was clear or is there something that we should clarify further?
David DeRemer (33:09.88)
I think so if I understand so designers in figma, you know, they’re doing some updates to the design, you’re maintaining your widget book, and then a developer is making changes in the application and they try to push a build. And widget book will help us to catch like hey, a developer changed something in the settings or in the in the code, or the theme or something like that that has changed that now Widget book and my code are not in sync anymore. And it’s going to actually demo that or show me that so that I can
you know, figure out who is right and what changes do we need to make to get it back into the thing. So we’re really kind of identifying sort of widget or component theme based UI bugs and helping to catch those that otherwise might shift to production.
Yes, yes, exactly. Yeah, perfect.
Do you have any numbers on like how much time you think this saves teams or anything like that?
Yes. Yeah. So the great thing with Widgetbook is that we are already live now for, so with Widgetbook Cloud as well for well over a year and we managed to already grow to profitability with the team we are hiring soon again as well. So growing fast, fortunately, and the biggest benefit
Lucas Josefiak (34:24.418) that teams have is that you are able to shift left. And shifting left is something that is currently quite important for a lot of enterprises. So basically what it means is that you’re trying to test as early as possible in the software development lifecycle to catch bugs, basically as soon as they are introduced. And with WidgetBook, we really allow you to catch all of your visual bugs, as you called it, David DeRemer, already on a PR level.
why the code is not merged or polished yet. So you catch them very early and therefore, yeah, you are making sure to waste basically as little time and resources as possible. And we published a few case studies already. One is with an enterprise from the Netherlands called Salto. It’s one of the leading companies for identity management software. And what they noticed is they were able to prevent
all visual bugs in their code, and they saved over 50 % of the development time. So basically every developer that basically works 40 hours a week now has 20 hours a week available to do something else. And because the developer does not need to be concerned anymore about, did I introduce any unintended changes to my code base? Hmm, how do I fix those?
those changes now that the code is already polished. How do I make sure to get my team to review my code as well? So basically all of these questions are now automatically answered with WidgetBook. And for Salto, they learned they are saving 50 % of the development time.
Significant. That’s amazing. Wonderful. So I love that idea of shifting left. You want to catch those bugs. And traditionally, I think over these visual bugs have always been very difficult. Even golden tests are really hard because especially, you know, people who feel like, we’re in a really fast cycle, we’re constantly changing or startup or whatever. People kind of get away from those. And then the problem is that it’s very easy for visual bugs to creep in. And it’s really hard to find those because you actually have to kind of use the app.
David DeRemer (36:40.778)
and work through it. So I think that’s an incredibly valuable tool to make sure that the designers, the developers, the QA teams are working in sync and anything you can do to save time is massively important. So sounds like you guys have really great integration.
Exactly. And that’s in the end, the second big benefit that you have. you can really make sure that your developers and your designers are aligned and that they have a great structure to then build a maintainable app long-term. So not only that you build a structure once, but that you maintain it. And there we have another customer that’s testified already that also the designers have a lot of time savings. basically their developers and designers combined save over 20%.
of their working time in their company. And that company gave a talk at FlutterCon Europe, where they basically presented their entire Widget book workflow. And what they mentioned is that in the past, they always had a code review where basically, so the developer made a change and then in the pull request, they then had a code review. So something that we all know, right?
The issue was always, okay, who is now responsible for also making sure that it really aligns with the design. And the developer basically always kind of pushed the responsibility towards the QA testers. The QA testers were also not too happy with their responsibility and the designers, usually they’re not included in the process at all. Or if they are included, they are included very late in the process. So they might get a test flight build every now and then, but usually they are not included at all. And for the designers…
it’s also not really motivating to not be included and not really knowing what happens to the design. So what they included is basically on the same level as a code review and now have design review as well in their pull requests. And there they have a required designer that always has to review the pull requests as well. And that’s why with widget book, we included now the term of visual pull requests, kinda. So to really make sure that you have this full
Lucas Josefiak (38:50.188) stakeholder alignment because with Widget Book, we also allow you to not only basically see, that’s how the Flutter implementation looked in the past. That’s how it looks now, but you can also compare it to the Figma design in Widget Book Cloud.
So when you think about the fact that actually what we’re trying to do here is create user experience, like actually create a design and a tool that you actually engage with and use the fact that this isn’t already like a very established pattern of a visual pull request is like kind of shocking when you really get down to it and think about it. So kudos to you guys for coming up with some really amazing technology to help solve that. Given that you have this Widget book Cloud offering, you know, one of the advantages of having customers like when you have open source software,
anyone can pull it and you kind of don’t always know who’s actually using it or what people are doing with it. Once you have customers, you have a little bit more insight into, you know, where people are, what are their needs, what types of companies are out there using it. What is that experience kind of taught you or have you observed about the current state of the Flutter community? Maybe like when our companies kind of coming to Widget book, is there a certain trend you’re seeing around the size or type of companies engaging with with this? And fundamentally, what do you think that means for the Flutter ecosystem?
Yeah, mean, first of all, it’s super important that you get this data finally. mean, with VGV, are amazingly also doing a lot of great open source work. And that’s why you also know, hey, that unfortunately, you don’t always know who is using your open source package. And then you have all these developers and companies at conferences talking to you and are like, hey, Lucas Josefiak, we’re using Widget book. It’s so amazing. And you’re like, okay, and who are you? I’ve never heard about you that you’re using it because we just don’t have the…
usage data. But with Widgetbook Cloud, fortunately, we have the data. what we are seeing is that Flutter seems to be stronger in Europe than it seems to be in the US. We also have the same, or we see the same at conferences. I mean, David DeRemer, you also joined FlutterCon in the US and also in Europe. And you also see that the European community just seems to be bigger. But
Lucas Josefiak (41:01.75) On the enterprise side, really feel like in Europe, more smaller companies are using Flutter versus the larger enterprises are in the US. So if I would basically have to differentiate my customer segments into basically, so we have self-service tiers on Widgetbook and Cloud, and then we have enterprise plans. And on the self-service side, most of our customers are from Europe versus on the enterprise side,
most customers are from the US. And there we also have customers from Asia as well. So we basically don’t have paying customers from Africa yet. I hope to change it eventually. But we basically have paying customers across all the different continents. And to your question, at what stage are companies usually integrating Widgetbook, I would say
Mostly it’s mid-project. that basically means, and here I’d also be curious about the experience that you have, but to our experience, mostly the teams that are using WidgetBook are starting with a POC of WidgetBook. So usually you just build, either you build an MVP or you build an internal app only where basically in case it fails, no one really cares that much. So it’s just easier to…
to get it started. And then you notice, it’s amazing. Let’s actually make it into a real product. And then the team already started and then they are not starting. So, I mean, we have some teams that are then also throwing away everything they had. So they threw away their spike and then they’re starting kind of from scratch, but most teams are then already integrating Widget book into an existing app. Mostly, I have to say that that app is not, mean, product is not a final, right? But usually,
It is not in a stage yet where the app is already super mature. So usually, WidgetBook is integrated in a state where you now basically have the validation that you can actually have a multi-year commitment to your app. And that’s why now it really makes sense to have a design system for the app, as it makes sense to have a design system for your app. It makes sense to use WidgetBook for your app. And then you…
Lucas Josefiak (43:28.876) Yeah, start using it for your design system. then, yeah, large enterprises then always also use it for their various apps. most, I would say the Widget book is the strongest in bigger companies where ideally you have one design system for multiple products. So you have like a multi-branded design system. And then you start with your design system, a repo and widget book. And then you also bring your app specific.
repo to Widget Book, where you then also catalog your app specific widgets and entire screens to Widget Book as well.
Very cool. Well, it’s wonderful to see the growth and the success you guys are having and getting into more enterprise customers and things along those lines. You’ve been a very involved member of the Flutter community and sponsoring and showing up at all the events and being a great driver of the community. So I think for that, everyone in the community should thank you for your presence and your participation in that. think that really helps, you know, showing up at these events, adding that weight. And I think it starts to pay dividends in the long run as you start to see the growth and the opportunities.
Actually one question I wanted to ask you around that is like you have been very involved in the community and, maybe for companies sitting on the sidelines thinking about like, should I get a booth at FlutterCon or, you know, should I, you know, actively participate in these communities, go to a meetup? What has been the impact of that involvement on your business?
So I think for us, it’s a bit special because we’re building a developer tool. So basically every developer that is walking around at the conference could be a potential customer for us. So I think if you’re listening and you’re building a developer tool for Flutter, yeah, I mean, basically you have to join the conferences. So it’s kind of the lead generation, especially on the enterprise side because…
Lucas Josefiak (45:20.238) I if it’s a self-service tier and you’re charging a few hundred bucks a month, okay. mean, trust is not really an issue there. You can just risk it. And if it doesn’t really work, yeah, okay. What did you waste like a few hundred bucks? But if you’re talking about enterprise sales and you’re talking about six figure contracts there, it’s also really about building a relationship with a customer, making sure that you can trust each other.
And in the end, it’s a people business, right? So you really miss out if you’re not meeting people in person and conferences are the best way of meeting people in person. So I would say if you’re building a developer tool, you have to go to conferences. No excuse, basically. But also if you’re not building a developer tool and you are either a developer or an executive of a Flutter team,
I would also really encourage you to join conferences for multiple reasons. One really big reason is Flutter is so special because of its community. mean, all of us, know that Flutter is maintained by Google. And it’s true, but you also have now even more contributions from non-Googlers than from Googlers.
And Flutter is, I think, now the top three ranked repository on GitHub. Am I correct, David DeRemer? I think it’s up there.
ahead but it’s up there it’s definitely one of the biggest ones.
Lucas Josefiak (47:05.25) Yeah, exactly. So there are so many contributions that you have from the community. at the conferences, you always meet other developers and many of them are quite influential. And you have the chance of talking to other open source package maintainers. You have the chance to basically share best practices with other teams and make a connection with them because very, very likely whatever issue you’re facing right now, someone else faced it as well.
And if you then have these connections to the other teams, you can just ask them and learn from each other. And that’s something that’s also like so easy to do at conference. And then obviously you can also go and join talks and basically learn from a presentation from people. But I really feel like that human connection at conferences is what makes a conference very special. And then I mean, very, very, very easy.
RIS, if you’re hiring right now, you have a booth and you can just talk to other developers that you can then just quickly hire is also a no-brainer.
Yeah, I totally agree. And I think I love that sentiment. If you’re building developer tooling and you can afford it, obviously you really should be here. And I think the more we have, think it also creates, it’s like a flywheel, you know, it’s like a snowball that rolls down. The more people that come, the more people who have a booth or give a talk, the more people come to the community and it just becomes this like self-driving engine at some point. And I think it is immensely valuable. And I think it’s, the value is demonstrated by the fact that
There are people who have been sponsoring and going to these FlutterCon events for many, many years now and are always there, always showing up. And if it wasn’t good, people wouldn’t keep doing it. So I think that’s really important. The other thing I think is for anybody sitting on the sidelines, I think there’s a feeling like sometimes you have to get some sort of lead or business out of this. And I think the way I like to think about it first and foremost is those relationships. There’s a famous Harvard study.
David DeRemer (49:08.212)
about like factors that lead into like human happiness has been going on for a long time. And the number one thing is relationships, like good relationships. And I think that’s really telling and more broadly, and not just to each of us as individuals, but even the the happiness or healthiness of a community, right, the more relationships people have, the more connections people have, the more willing to help people become and the more opportunities there are to increase that surface area for luck and make good things happen.
I think coming in and just being like, you know what my objective is to meet people that I’ve only seen in a GitHub handle or or not as a package owner or on a recording or something along those lines. I think it’s really, really important. So you’ve shared so much with us today and I want to kind of wrap this up a little bit. And I think one thing I’d like to know is you’ve been on this interesting journey. You started building things, you identified Storybook, you found Flutter, you thought it was really cool. You’re like, oh, Flutter needs Storybook.
We created Widget book, you went off, started your own company and have grown, now have enterprise customers. As you kind of like reflect back on that journey, what do you think is like a key lesson you’ve learned that you think you’ll take with us, not just forward in your own business, but maybe over the next 10 years, you think it’ll still hold true.
So, I mean, there were lots of learnings. I would say the key thing really is whatever you are building has to be something that you’re really passionate about. I mean, you were talking about happiness and how important relationships are. And that’s especially true then also for the team that you’re surrounded with all the time. I I have a beautiful girlfriend.
at home and I love spending time with her. But as much as I love spending time with her in the end, I’m spending most of my time with the team in the office. Most of my time I’m spending with my co-founder Jens. And I mean, we’re not married or something, but it’s often feels like it. And it’s really, really, really important that you are really only working together with people who love the problem that you’re solving.
Lucas Josefiak (51:15.372) I really can’t stress it enough. So biggest kind of biggest learning for me. I would, I will definitely take it in all possible future ventures that I might end up building. Basically only work with people who really love what you’re doing and who are not just looking for another job, because then you’re really onto creating something super beautiful. I mean, all of us, we’re spending most of our time.
in the job and we should really make sure that we spend all our time well.
Yeah, I think that’s really vital. You know, I think, obviously, we need money to survive and to grow and make our give our families better opportunities. We need ways to manage stress, you know, we need a bunch of things that matter. But I think you are hitting it right on the head. And I think it’s something that we you can see time and time again that when people really care when there’s passion, when there’s commitment to each other and good, healthy relationships, those other things tend to come.
If you prioritize, I’m going to jump to this job just for the money and but it’s like a toxic environment. It’s not enjoyable working no one’s passionate about it. In fact, I think that’s there’s an inverse correlation. I’ve noticed in my career that companies willing to pay the most. The reason they often do that is because it’s the it’s not a great environment and they need to offer some counterbalance to that to make it work. You know, whether it’s this whole nonsense going on in Silicon Valley of what is it like the
you whatever the numbers they have now for just like busy working all the time, you know, and having no personal life or anything like that. So, you know, each person needs to make that balance. But what I’ve found is that passion, you’re right, like the commitment to it. At the end of the day, that tends to yield the better results and even get to those same outcomes, but maybe be a different path.
Lucas Josefiak (53:02.196) what makes it fun, right? in the end, we only have one life. Statistically, we’re just spending most of it at work. So let’s work on something fun.
So if somebody based on your journey, maybe there’s been something along the way that you really drew from or learned from a book, a mentor or movie or something like that. What’s something someone you would recommend someone go out and pick up and read and learn from in order to help them down their journey?
So I would say most influential book on my career and probably therefore also my personal life was Aria Greece, The Lean Startup. I think it’s very, very classic read. So basically everyone that aspires to build a startup someday should really read it. And especially for software engineers that like to basically make things perfect and basically building.
all the time. And then I like, okay, I just have to ship it. I just have to press the button. And yeah, the revenue is going to come. I’m telling you, nope, that’s not happening. So it’s build, measure, learn. And yeah, that’s what Eric Ries teaches you really well.
Yeah, I totally you know, one of the things I’ve it’s like building it is actually the easy part. So many people think about like, oh, building is the hard part. If I can just find a way to get this done. And know, especially if you’re non-technical, you’re like, oh, I got a technical co-founder, somebody will build this for me. All my dreams will come true. And in reality, like, no building it is like actually the easy part. The hard part is making something people want and getting people to be aware of it and use it and continue to want to use it. That’s the hard part. So that’s a good one for sure.
David DeRemer (54:40.268)
Well, thank you, Lucas Josefiak, so much for joining us, sharing your journey, telling us all about Widget book and helping to educate us on design systems. If people want to find out more about you and look into Widget book, where can they learn more?
Basically every social media channel I’m on there. So I would say Flutter community is most active on X and LinkedIn. So feel free to hit me up there. Otherwise, widgetbook.io is our website. They’ll also find every way to contact me.
and they’ll also see you at tons of Flutter events.
Exactly. Join us. And I mean, probably same for you, David DeRemer. In case you are not so sure if the ticket is worth it, we are sponsoring basically every major Flutter event. I think David DeRemer is doing the same. And if you need a discount code, hit us up.
100 % well said. Thank you so much Lucas Josefiak. We’ll see you soon.
Lucas Josefiak (55:40.91) See you.