Kody Peterson, Foresight Sports - Rebuilding Mobile Architecture With Flutter and 3D Innovation

Speaker A: Uh, hi, I'm David, and this is Build to Succeed from Very Good Ventures. Today we meet with Cody Peterson, Director of Software engineering at Foresight Sports. In this episode, we explore Cody's engineering leadership experience, building high performance apps with exceptional user experiences. At Foresight, Cody's team is pushing the boundaries of flutter, including new approaches for creating 3D experiences. And he offers some really compelling advice about choosing the right technology for your team. I hope you enjoy it. Now, here's Cody. Welcome, Cody. Thanks for coming on the podcast today. Got a chance to meet you recently and really appreciate what you guys are doing at Foresight. Um, so wanted to get an opportunity to talk with you and share your story. But one way I like to start is, um, tell, uh, us something about you that connects your personal world to your technical one. I know we have our jobs and our things that we do, but what's something you do for fun that really connects to your work and technology?

Speaker B: Yeah, that's a good one. For me, I've kind of like found a love for trains. They're super interesting to me. They use technology from forever ago. A lot of people don't know, like, when a train's coming up to a, uh, to a crossing, it's just like an electrical line that causes those, those rails to come down and, and so lately I've been experimenting with my 3D printer and trying to print train tracks and then, uh, you know, use a little bit of Arduino and some servos and stuff to like, really get that to work like it does in real life, which poses its own challenges because we don't have things like electrical on plastic. So you have to think of other creative ways. And I always think that's kind of fun, is like trying to take technology that exists in the real world, maybe bring it down to a much smaller scale, and then go ahead and implement that in some way. So, yeah, that's. That lately has kind of been the thing I've been hacking on in my free time. Nice.

Speaker A: There's an interesting scale there. Is that physical world interaction. Is that, um, has that influenced how you see, like, software architecture?

Speaker B: Yeah, I think so. Uh, because, uh, especially here at Foresight, right, like we interact with physical products to a mobile app or to our golf simulation software. And so it's continued extension of that. Even like an Apple Watch or something like that, right. It's taking something that happens in the physical world and then implementing it in a way that you can do something in the virtual space to do that. So like the trains for Example, they're all controlled by a web interface. The trains know where each other are. So you've got this connection between what's happening physically and then translating in that some way so that your code and in all the ones and zeros know what's actually happening. Which is really the hard part, right, because it can't see it. Uh, so you have to find creative ways to translate that.

Speaker A: That's interesting. I might have to check out some of this train tech. I remember the old like Lionel trains that would roll around a Christmas tree or something, right?

Speaker B: It's a little bit more advanced than that.

Speaker A: Yeah. Pretty neat. Um, well, so take us back to the beginning, give us your story. Um, how did you get into engineering and what led to your current role at Foresight Sports?

Speaker B: Yeah, so for me I got started in the education sector. Actually I dropped out of college because it wasn't for me and I was bored and uh, applied for a web job at the college. And for some reason someone took a gamble on me and so I ended up working at the college for a little while, working in with really large systems. So right straight into like big Oracle data warehouses and that sort of stuff. I'm a newbie to tech, have a little bit of like HTML experience essentially. And now they're like, go find a way to query these really large databases. And I'm like, sure, I can totally do that. And some way I was able to do it right. It's just like figuring out creative solutions. So I did that for a little while and actually funny enough, I started almost immediately in my career journey trying to figure out ways to do mobile without native iOS and Android, mainly because I didn't know it, I didn't know how to do it. And I knew PHP and HTML, JavaScript. And so I came across, uh, this thing called Phonegap now called Apache Cordova, or maybe it's called something else now even. And it was what I knew, HTML, JavaScript, CSS. And I was like, sweet, I can make mobile applications now. Look how awesome I am. And uh, so actually ended up pitching that to the college and we started working on a little bit. But then I got this really great opportunity I turned down to go work for the Walt Disney Company. And uh, so we never really got phonegap off the ground there at the college, but went to go work for the Walt Disney company for a while. Once again a good, good gamble on their side, I guess, which I really appreciate now, coming in with a little bit of experience and being able to work on Some really large complex websites. It uh, was the time when magic bands were coming around and we were trying to get that whole system integrated into the web. My introduction to like physical to virtual space again, it kind of always keeps coming around. Uh, so I did that for a pretty long time and then uh, I got an opportunity to go work for a startup uh, which sounded really exciting to me. Didn't really know what I was getting into but it turned out really great. We were in the fintech space essentially creating chatbots for the financial uh, sector well before ChatGPT, so definitely a bit ahead of our time. Uh, and so I did that for a little while, then moved into management within that ecosystem, started to become a leader and learning all the leadership things and how to motivate people and make big business decisions like moving to Flutter or something like that. And then after that moved on to another startup in the golf industry. So kind of really just a lot of different industries. And uh, recently we were acquired by Foresight and we've come into Foresight now and been able to provide some leadership there and really change the software ecosystem here at Foresight into, Into now. What we've got with this, this brand new app that we released uh, earlier this year.

Speaker A: That's awesome. What a good uh, good mix there of startups and then Disney and um, all those sorts of things. It sounds like in your career you've had a lot of opportunities to kind of take some risks and try new things, uh, things that maybe someone trusted you to do or like you're talking about the, the database queries and I, do you think that that sort of early sort of belief like hey, I'm going to give you this hard thing and go figure it out. Did that skew you towards startup decisions later? I'm curious.

Speaker B: I think so. I think it was one. I'm just, I'm really self driven and I think to join a startup or to be a part of a startup you've got to have that mentality and so uh, that worked in my favor. But yeah, I think me having those opportunities to someone just taking a risk on me and then me having to fulfill that uh, because I've done felt indebted. Right. It's like you know yourself how good you are at what you're trying to do and, and uh, sometimes in interviews we definitely try to look a lot better uh, because we're striving to grow and, and move our career in different directions and, and so for me at least it's like wow, I, I recognize you're taking a risk on me. Thank you for that. I'm now going to do everything in my power to exceed those expectations. And, and yeah, so then a startup comes around and you're like, that's all it's going to be. It's going to be a just running all the time, continuously trying to surpass expectations of the customers and you know, everyone else you're working with. Because at the end of the day you've got to get funding, right? You've got to continuously deliver to customers. And that's the beauty of startups is just being able to just keep iterating and iterating and iterating. And so yeah, I'd say a lot of it came from just that, that risk for sure is a lot of

Speaker A: self awareness too, right? When you're in those situations where people are taking risk on you, I think, um, to turn that into creative energy to like actually be motivated to push harder. I think a lot of people have personal motivations. I want to do this for me, but I think that's pretty cool to think about. Like, hey, you know, like people are taking risks on me to help me out, to invest in me, to give me hard problems and, and help uh, you move forward. I think that's pretty awesome. When you think about that progression in your career all the way through now you've been through an acquisition into, into foresight, uh, here, um, were there any like kind of key moments or, or lessons learned that you think have kind of best prepared you to navigate that transition and now be in your current role?

Speaker B: Yeah, yeah, that, that transition is, is an experience all on its own, I'd say. And, and I glad to be able to have that opportunity to go from startup world to being acquired. And then now you're, you're going to have to prove yourself again. Almost. Right? It's like that the acquisition for what was for a reason that doesn't mean you pump the brakes, you almost start accelerating even more. You're given more resources to do that, you're given more stability to do that. And now you have this opportunity to take, take the product or take what you're building to the next level. But with that comes a lot of weight on your shoulders to be able to deliver that and to do that. So it's almost like taking the startup and then starting up again, but with a lot more stability and a lot more resources, which is really the best part, if you will, to me, because you get to grow your team, you get to meet new people, hear Ideas from different ways. Instead of kind of really small team just doing what they think is best and, and building, you know, the best product they can.

Speaker A: Yeah, that's really important because when you think about acquisition, I think when you read about acquisitions, like, oh, this company got acquired by so and so, you see the number maybe, and you're like, oh, probably the. Everyone was just like, cool, like, with this acquisition, like, our job is done. It's like, no. Well, the reason that company acquired you is because your job is just starting.

Speaker B: That's exactly it. Yeah. It's just start that loop again. Yep.

Speaker A: Yeah, that's.

Speaker B: Well.

Speaker A: And so tell us about Foresight Sports. What do you guys do and what's your role there?

Speaker B: Yeah, so here at Foresight, we develop launch monitor. We have two kinds. Overhead units and then ground units, essentially for those non golfers out there, including myself, just worth calling out. Definitely not a golfer, but I'm learning a lot about golf throughout. Throughout this whole journey. But we've got these devices and you. You put the golf ball in front of it, you hit the golf ball, and it provides a whole bunch of data about the ball, the characteristic characteristics of that ball, what it did in rotation at speed, how far it went with. With extreme accuracy. And then additionally, we can provide details on the club head and actually where the impact was and what angle your club was at. All this data golfers tend to utilize to get better, and we can utilize that data to help the golfer get better. And that's where the software aspect of the hardware comes into play. So we get that same data that the device has, but we can present that data in so many different ways and provide visuals to the golfer that they've never been able to have before either. And throughout those experiences, and throughout some AI features and some coaching features and all those sort of things that we could add to our software. We provide a way for the golfer to get better and to better understand the data that they're getting from the device as well.

Speaker A: So if I'm a golfer and I want to get better, I have this device in the ground or above me, right? And so I'm. I do my swinging, it's tracking my swing, the ball, everything. What's it looking at?

Speaker B: It tracks the ball and the club head specifically. And so between that, we have all the data required to know exactly what happened all the way through the shot to impact and then out, you know, through the flight as well. So. And then, yeah, it's just about visualizing that and providing data in so many different ways too, because every golfer learns kind of differently. We all learn differently whether it's golf or whether it's a new skill or anything like that. And so our challenge on the software side, and really the challenge for our product folks and our design folks is how do we present this data in a way that multiple personalities and multiple ways of learning can understand it and can grok it and learn from it. And so on the software side, that's where we're just building out a bunch of visuals so that if you're a data person, you can look at our table view and you can just read the data and you'll understand that. But if you're a more visual learner on like myself, I need those visual aids. I need representation of what was happening to the club and to the golf ball to help me learn.

Speaker A: Yeah, that's so cool. Sports in particular, I think, has that unique balance of like the data, like you're saying the tabular data and want to get into that and then the visualizations. You. We work with a NASCAR team called Track House, and it's a. There's like so much data. Some people just only want to look at the numbers and other people are like, I can't make sense of this.

Speaker B: Can make.

Speaker A: Can you make. Show me a graph or something that. What should I do with this? So I think sports in particular has that balance and, um, having good, effective tools to help you iterate through that, I would imagine would be pretty, pretty important. So let's maybe get into that. What are some of the technologies you guys are working with?

Speaker B: Yeah, so, um, we're really trying to expand the ways in which we can provide this data. And so in the flutter space specifically, we, we've got a lot going on there. Our design team is very blue sky. And as developers and engineers, we don't ever want to say no to a challenge. And that's had us build all custom components. We don't use material styles, we don't use Cupertino styles or anything like that. It's all very custom. Uh, we use them as bases because they're good foundations to build on. But if you were to look at our app and you were look at the design, you wouldn't see anything there that, you know, you've kind of seen within, within UIs themselves. And that's, that's a design language choice. That was actually one of the things when we came in through acquisition, we, we identified as one of the goals that we wanted to do here at Foresight was start to build A design language, and start to build this consistent user experience and give foresight, this look and feel that you look at and you go, that's foresight. But that's an immense challenge on the software team to have to build that out. You go essentially straight from Figma, and you're like, okay, well, let's build out the borders and let's build out the exact curvatures and spacing and all these things. We have a whole button library because we couldn't just use the material buttons. Right. Because they're all vastly different in our own sizes and that sort of stuff. And, uh, even outside of just the ui, we've got complexities and the logic, the data. And the data is so important. We have to ensure the precision of the data coming in from the device is exactly what you see in the. The application. If the software doesn't show the same numbers that the device shows, uh, the golfers are going to be asking, well, which one's right? Right. Our customers will wonder the accuracy of the data. And so we need to ensure that the algorithms and the formulas and the way that we're calculating the data is identical. And so we've got a lot of logical things. We use block for our state management system. We've actually built wrappers around block because we just needed more, uh, we needed more ways to understand when events were actually done and complete so that we could do other things. Because there's a lot of order of events that kind of have to happen. And then we can even dive into our 3D modeling, which I know we want to talk about. I've kind of previewed, uh, you a little bit on that one. But, yeah, we brought 3D to Flutter in a roundabout way, but we're really excited about that. And that was a huge challenge. And I think that just talks to our software team, is that we get something from design and we don't think, well, can Flutter do this? We think, how can we get Flutter to do this? Or how can we get Unity to do this? Right. In terms of our game simulation software, it's, uh, a really different mindset. It's kind of that startup mentality that we've brought to a larger organization. And we found that that mentality allows our engineers to get really creative and grow even in their own. Right. So, yeah, lots of, lots of neat technologies that we're kind of pulling in, but a ton of custom flutter work. So we know a lot about flutter at this point.

Speaker A: Awesome. Yeah. Well, I, um, mean so much to unpack in what you said there, uh, and so many things about Flutter specifically that I think are interesting, that idea of building your own design system. You know, right now, uh, the Flutter team is working on sort of actually taking the material in Cupertino out of the core framework and things you bring back in for kind of precisely this reason. So that the original intent of it was like, you build your own design system and your own thing and yeah, we're going to give you material in Cupertino as something to start with so you can build something easily. But just uh, that acknowledgment that I think a lot of big brands, um, and companies that really care about how they're showing up brand wise, they don't actually want to look like a native app. They don't want to look like the default Apple stuff or Google Material Things. They want to, uh, have their own aesthetic and user interface paradigms and stuff. So I think that's been really cool. So yeah, design systems a big one. And I, I think it's so cool how you guys have took that approach too of like not expecting it to be there, but be like, how can we push the framework? How can we do more? And I think that's really the philosophy that is the whole point of open source software really is like, hey, build on this, like, take it and run with it. Add more things. Don't just wait for Google to figure it out for you. If you're do that, even though they have such so many resources, you never know if they're going to get to it.

Speaker B: Right.

Speaker A: How did you get to Flutter in the first place? I mean, um, were some of these things part of the evaluation criteria and what led you to it, or were these sort of happy side effects? I mean, tell us the story of like going from your trajectory into Flutter.

Speaker B: Yeah. So when I came into the foresight ecosystem, one of the things that I started to look at is, okay, well, what do we have here already? What are we building on top of and what are we going to, going to just make even better? And they already had a mobile app here. It was built in React Native. So the first step was like, okay, let's think about what we want to do, let's think about what we want to accomplish. We've got a whole slew of features that we're looking to bring into the mobile space. We've got this new design language that we were sort of talking about and is React native the right choice? And what we ended up identifying was for performance reasons for the animations and the High fidelity, uh, level of UI design and control that we wanted to do. Flutter just outperformed in that way. We ran multiple pocs, uh, within the React native space and within the Flutter space and some various other frameworks as well. And we found for our requirements is that Flutter was going to work better for us. We knew that we wanted to try to identify some way to do 3D. We knew that we were going to want to have a really quick iteration on things and have full control over the platform itself. Another consideration was we have to talk to native SDKs, uh, that we build in house to talk to the devices. What sort of bridge exists there or what would be really well served. And while both React Native and Flutter have a bridge to talk from, talk to the native side, what we were missing m on the React native side was this type safety nest. This really well easily orchestrate a way to get data models from one side to the other in a way that still gave us our type safety. And so utilizing Pigeon, for example on the Flutter side we're able to have this really well defined structured messaging layer that allows us to talk to the native side. And so that was another kind of checkbox on the Flutter side for us. And then yeah, and so once we identified we wanted to go the Flutter route. And additionally in the Golf startup Pinseeker, uh, which got acquired by foresight, we had already been using Flutter there. We knew the advantages of Flutter, we knew the speed of development and not that that doesn't exist with React Native, it's just we knew that the nuances and the differences. And so we came in with that knowledge as well. We came in with some foundation that could help us out as well, interacting with some deeper GraphQL stuff and custom build runner, uh, code generation stuff, uh, that we, we could kind of quickly get up and running. So after we identified Flutter, the next step was, all right, well how do we convince the business to essentially say hey, we've got to start, start from scratch because there's no like magic. Convert this React native over to Flutter. Right? As much as we would love that, or convert this native to Flutter even. Right? Because that would, that would make uh, uh, a lot of our jobs a little bit easier. But it doesn't exist. And so now you understand, now you have to figure out okay, well what are the business benefits and how do you tell the business that this is a great reason to do this long term.

Speaker A: So did you build a brand new Flutter app or did you integrate into the React native app? Or how was the approach there.

Speaker B: So for this one we built from scratch, we just started a new repo, spun up Flutter, uh, brought in some foundational components from Pinseeker, uh, and went on in the Pinseeker world though that one we actually started as native iOS and native Android. And that application had a lot of screens. It already had usage. But we ended up needing to be a bit more leaner with the team as the startup went through its different phases. And so as we start to lose some of those, uh, individuals, that new native iOS, new native Android, and we get down to like one or two people, you end up thinking, well, how do you develop with one person or two people, iOS and native, native iOS and Android, you're duplicating the efforts. And so that's where we really started to think like, well, what if we could just do this one time for everything? And so that's where Flutter came into play. But being a startup, you can't just say, well, let's, let's throw it away essentially and, and, and just build it from Flutter. And so we had to start doing add to app strategies, uh, which is probably one of, I'd say one of the most uncommon things about Flutter is its ability to be injected into an already existing native iOS or Android app. You don't have to use Flutter, just straight Flutter, right? You can have sub views that are native and then switch over to Flutter views and then switch back, go back and forth. You can share data. I would say though, it's not easy and not for the faint of heart. We had to learn a lot about the Flutter cache engine and understand how to kind of start Flutter up in the background for some of these views so that when you switch to it, it just showed up. We had a lot of effort to like keep designs, you know, uh, across, across Flutter and Native the same. So it was definitely one of, one of the biggest challenges we had at Binseeker. But we knew that long term we would get to a place where we could begin to migrate everything over to Flutter and then at the, at the end would be all Flutter. And uh, eventually we got there, uh, or most of the way there. I think we still have a few lingering views or something like that, but for the most part it's all Flutter now. And we found the time to take those views, redesign them, allow product to take a second look at those views and then implement those in Flutter. But for a long period of time it was a lot of coordination between native and switching to Flutter and back and forth.

Speaker A: Well, it sounds like you're a go to person for anybody who's curious about React Native versus Flutter or do you go from scratch or do you add to app? Um, and then there's the other side of Flutter that I think school, like you restart with Flutter and add Native to it or other things, you can do that side too. Right? But uh, like when you think about coming into foresight and you had this existing React, because this is like, this is at really the critical point of the debate around Flutter React Native. You know, there's a whole debate around either one of those relative to Native, but the React Native to Flutter thing, in your experience with your team and what you've seen from teams who had seen both, um, what's your like your honest take around how those two, they're both great technologies school, we have them both. But what's your honest take around the pros and cons?

Speaker B: Yeah, I think it's really interesting. I think that React Native has some really great qualities around it. I think from a talent perspective it's probably a little bit easier to find people that can just get into React Native. Think about all of your engineers that know React or know Typescript. They can almost next day begin in React Native. Sure there's platform nuances and that sort of stuff that they have to work out, but that's no different than dealing with CSS nuances or browser, you know, Microsoft Edge versus Google Chrome right on the React side. So I think that's kind of one of the big things that you could look at React Native and go, wow, like finding talent is really easy there. The Flutter talent pool is a bit smaller. Right. It's still, I'd say, a new community. Uh, it's still maturing and evolving, but it's evolving into the direction of high performance and high fidelity. And I think that's the big differentiator, especially for us, uh, as we looked at the two is sure, React is mature because it builds or React Native, sorry, is mature because it builds on top of React and it gets all of that maturity and thought process through React And Flutter is building something new, right? Like it doesn't have that to fall back on. It's got Dart, but they kind of came together a little bit if you will. And so I think that's where it is. But because of that, because it is new, because it's being built specifically for this use case, it has the advantage of working through high performance, working through high fidelity and really focusing just on these platforms, uh, mobile desktop, uh, web even, right. And So I think that's really where it comes down to me, uh, with me on it is what are you going to be doing with it? Uh, what is your use case and trying to understand what you're trying to do with it in the future even. Which is a hard thing to think about. Right. When you're developing a product, a mobile app for the first time, you're just thinking about what I need to do now that, that mvp. Right. It's really hard to kind of think about in the future, but if you put some thought into that now, you'll likely make the best decision for, for your future self as well.

Speaker A: Yeah, no, that's, that's insightful and so many people want to know like what's the answer? Right. Just tell um, me which one to pick and there's never just one answer because you're right. Like if you have a whole bunch of really great TypeScript JavaScript developers that know React and they want to get into that, that's an advantage you got to pay attention to. You know, it's also maybe not as hard as people think to like, okay, if you've got a really good engineer who really understands fundamentals of solid software engineering practices and has been building mobile and you know, they're expert at Typescript, like they're probably going to pick up Dart and Flutter pretty quickly. Yeah.

Speaker B: I mean there's so many, so many similarities right between Dart and TypeScript or JavaScript. And that's what we found too is we've got some really talented senior engineers, uh, some that like maybe on the unity side etc. And didn't have Flutter experience before. I mean I'd say even myself, you know, four or five years ago or so didn't have Flutter experience and now I'd say, um, I'm pretty, pretty good at it. But it's that just understanding of programming concepts and understanding of just like other, other coding languages that you kind of put the pieces together and work it out. So if you got, if you've got a pretty strong team that understand different languages, they're probably are going to be already be able to pick up Flutter and run. Run with it.

Speaker A: Yeah. And like you said, what are your objectives? Are your objectives to build like high performance data driven experiences where you want to have full control of your design system and you don't want to worry about. I mean one of the things I think is interesting about the native side of React native is that while that's a benefit in some situations where you want it to look Native. If you're really trying to have like, very tight control over how your app looks on every device that runs it, uh, well, that can be a huge pain if, like, what if somebody using an old version of iOS or Android on an old phone? And how is that actually going to show up in terms of what the native component is going to be rendered as? Whereas with Flutter, you ship the design engine or the rendering engine with your app and it's going to look the same everywhere. You also mentioned about having to convince, sort of leadership and kind of work through. How do you sell this internally?

Speaker B: Take us a little bit about through

Speaker A: that happened, maybe even going back to the pin seeker days and then coming into Foresight, I guess, and kind of pitching Flutter into this, this, uh, existing team. What, what are those conversations like?

Speaker B: Yeah, in the pit Seeker days, it was, it was a little bit easier, smaller team, uh, it's startup. So you kind of already get that advantage of like, this will help us move faster. It's proven already. You can read hundreds of articles about it. That one's pretty easy. Where it became challenging was when we identified the nuances of add to app and the challenges that come to that. You end up finding it's taking a little bit longer than it normally would if it was just Flutter to start to implement those things. So now, as you build that stuff out, the, uh, business conversation becomes, how do we, as quickly as possible begin the migration process? How do we, like we've now seen, yes, you can build these views very quickly, but now we're running into time challenges with getting the native integrations working, getting the transitions working and that sort of stuff. So you've kind of shifted the problem not so much in convincing to do Flutter, but trying to now convince, hey, let's pause on product features so that we can do this migration. Because now you've seen the benefit of it. Whereas on the foresight side, it's the ask of, hey, we'd like to move away from React Native, this app that already exists in the App Store, that's already in production and serving customers, and we'd like to not put any more features there and we'd like to build this new thing in this new technology that we have to build every view that's already there from scratch, essentially. We've got some logic that can probably be copied and pasted over with AI. They can kind of help us a little bit, which is great. Now that's the discussion and that's where it comes out to be. Well, we've got A proven model on the pinseeker side, which is great. We've got a proven model across all these other companies that are, that are doing that, just like vgv. And how do we now tell the business those case studies and those user stories and explain how that is exactly what we're trying to do and will in the future pay off? And that's really what it's about, uh, is even if you're coming from native iOS and native Android, you're making that decision of we've got two teams or you've got one team of hybrid engineers that know both, which it's pretty uncommon, but it definitely exists. And you're now thinking of wanting to move faster and you want to ship features faster and you want to do all these things quicker. How do you do that? And one of the answers might be, well, we moved Flutter because we just build once and it ships everywhere. But to do that we're going to have to move slower. And that's really the hardest bit of conversation that you have to have. And you have to have a lot of conviction in it. You have to have a lot of confidence in your plan. There were a lot of conversations where it's like, well, maybe we just one more feature in React Native, one more feature in React Native before we start the migration. So the migration kind of keeps getting pushed back a little bit more to start Flutter because it's so easy to just say that platform already exists, let's just keep adding it. But if you can come to it with a plan, if you can come to it with all these features, it starts to make sense. But it's something that you're going to invest in in order to get those long term benefits a little later. And I'd say one of the other things that really helped us in that business case and that decision at the leadership level to do it, is we weren't just taking what we had and converting it to Flutter, we were taking what we had, looked at all the views, looked at the user experience and took it as an opportunity to redesign and rethink through the user experience. And if you end up in an opportunity like that, you have a lot more power, I'd say, to be able to convince the business that, well, we're going to have to rebuild all these views anyway in this language or this ecosystem. So because of that, this now becomes way more of a possibility because it's either rewrite it over here or rewrite it over here. And so it flutters that thing that you think is going to give you that long term advantage. Are you already going to be doing a redesign or already re looking at the user experience? If so, it's more of a reason to be able to do the Flutter thing now. Then keep building it with what you have.

Speaker A: Right? Yeah, that's very insightful. I think. Um, I've definitely heard a lot of people talk about old code bases that are just too cumbersome to maintain. Right. Where it's like, oh, we've been building this native code base to native for eight years and they've just diverged so much that to uh, ship a new feature and with parity it's so hard because the architectures are so different. We're now maintaining different APIs in the back end to talk to them and all this stuff. And that's like out of a need of, like we just can't ship fast enough. But I think that insight of, well, maybe you're at a moment where you're doing a big brand refresh, you're, you're want to completely rethink this and um, uh, you know, you're going to have to do a lot of energy to redo your user interface anyway. Take that as an opportunity to put yourself in a better position. Given that. You know, I'm, I'm curious how many people out there have kind of taken a React native app and then kind of pitched like, let's go to Flutter. I mean, certainly we hear a lot about native to one of those two. I think that's really interesting having like, we have a React native thing and it sounds like the design and the user experience was a part of the discussion, but I would imagine and um, you know, leadership, uh, who have a, you know, they're looking at P and L and everything. Are they like, wait, wait, whoa, whoa, hold on. We already have this thing, we already paid for it, we built it, we got to redo it. You know, uh, why would we do that? Um, what are like the one or two. Besides the design, which it sounds like might maybe is one of the two or two things in the ux.

Speaker B: Yeah.

Speaker A: Uh, what else kind of really resonated in that discussion with leadership, you think? In retrospect?

Speaker B: Yeah, I think it came down to once again performance of what we were going to be building. We came in with a really good idea of future features. And I think if you're in a position like we are and you're trying to pitch to business, move from React Native to Flutter for whatever reasons that you have me as someone being in Leadership. I'm going to ask those same kind of questions, like, okay, so you want me to not only kind of approve you finding more newer talent or different talent to support this or training your existing engineers for this, but also I'm going to have to put a pause on new feature work for how long in order to you to do this? Or are you saying, hey, we'll just keep building it in React Native while on the side we build this Flutter thing too, which is a very slippery slope because if you don't cut it off at some point you'll end up with two apps that are never ready to kind of go. And so yeah, I think it really comes down to that sort of future understanding when you're thinking about going from an already existing multi platform framework to another one because you don't have the advantage to go pitch to leadership. Oh, this is right once deploy everywhere that one goes out the window because you've already done that. You can't go to leadership and say it'll be faster to develop because you're already there. Like we talked about, there are a lot of similarities between React Native and Flutter, right? They're both doing the same thing, just differently. And so if anything it's a much harder pitch. You've got to find the right time to do it and you've got to find the good reasons to do it right. Just because maybe Flutter is a new hotness probably isn't a good reason, especially at the leadership level to do that. And so I think that's where it comes down to is just trying to find those right reasons and find the right time to be able to pitch something like that.

Speaker A: Find the right reasons, find the right time. That's very uh, very uh, wise advice. And I think that's, that's what's so cool about that story is you're right. Like when you're talking about native to either uh, React Native or Flutter, you have that whole thing of like, oh, I will just can do more with less. Generally that one's a pretty easy sell to management, uh, a lot of times, um, even though there's a cost upfront to do that. But yeah, it's a tough. Your ace card was taken off the table right out of the gate with that one. So that's kudos to you for getting there. And I think it really demonstrates also sort of the experience you guys had had already and the ability to demonstrate that performance and that uh, improved user experience you're going to get out of it. Speaking of improved user experience, I know you guys are also sort of pushing the boundaries a bit with Flutter. You mentioned some of the 3D work you're doing.

Speaker B: Yeah.

Speaker A: Can you tell us a little bit about that?

Speaker B: Yeah, I'd love to. Yeah, that, that project has been really exciting from an Azure perspective. So we once again went into this mentality with design of, hey, Blue sky, show us what you want to do, we'll figure out how to implement it. Uh, uh, and so we saw the first designs for what's called Club View in the mobile app. And Club View is this ability to see the club from different perspectives at the point of impact. And so this allows the golfer to see exactly where the ball hit on, on the club head and then allow you to see the angle at which your club was in multiple views. And so we thought, you know, they're going to come to us with a static image that we can just kind of rotate and we can plop a little point on and all is good. And we could totally do that Flutter. And they came to us with a, uh, prototyped out 3D view. These 3D club models that were built from scratch by the design team. They were moving, like animating in. You would tap buttons, the camera would rotate around them to the views. They had these really great animations. And I looked at it and I go, that's amazing. I love that user experience. I have no idea how I'm going to get Flutter to do this, because this was very, very much so right when Flutter announced that they were starting to look into 3D. And they have this experimental library that lets you put a 3D model on the screen and kind of look around it. But I knew we needed way more than that. I knew there wasn't camera controls, There wasn't a, uh, 3D scene. There's none of. And so we started to kind of sit at the table and go, okay, well what can we do? What are some technologies that exist out there already? What can we take advantage of or work out to make this happen? And I just happened to watch a, uh, Talk by the SpaceX Starlink team, who, from what I understand, actually builds their app at React Native. And they were coming to the same sort of conclusion of like, hey, we want to do 3D in react native. How do we do that? And they had the same problem. There's like, no 3D standard support in React Native. And they came up with a Solution to utilize JavaScript and HTML technologies to put 3D, like, embedded into, uh, React Native. And I started thinking, I said, well, first Off. That's a great idea. So I got to give them kudos because we've built our architecture pretty much foundation on top of that. And I said, I wonder if we could do that in Flutter. And so we started looking at the different JavaScript libraries that existed out there for 3D, and we came across Babylon JS, a very mature, well known 3D JavaScript framework. And so we started to build a little PoC out and then we took, uh, an in app web frame and we loaded the HTML JavaScript in there and we had 3D and Flutter. And we were like, okay, this is great. This feels good. We've got some performance issues we've got to work out. We've got to bring down the size of the JavaScript and whatnot to make it just load a little bit faster. But we've got kind of an idea here. We brought a 3D model into flutter and we can move the camera around. And then so the design started to evolve a little bit more, as they tend to do. And the next iteration of their design had data points drawn on top of the 3D models and below were some like, really gradients and angle gradients and stuff like that. And we said, well, we can't do that in the 3D space because we need a UI system. And that just didn't work. So we're like, okay, well what if we built these layers in Flutter? So we've got Flutter doing the overlay, we've got Flutter doing the underlay, and then we've got the 3D model doing its thing with the cameras. And we found that we could make the webview transparent and we could now have Flutter sit on top and below this webview. But now we need to coordinate these systems. We've got two vastly different systems that are running in their own, you know, space time continuums, if you will. And we've got to sync those up and bring those in. So like Pigeon, we built a custom bridge between the Flutter space and the JavaScript space. And while you can send messages already between JavaScript and Flutter, you can't send, uh, structured messages. Right. It's the similar problem that Pigeon is working to solve. Right. When you send messages to the other platform, it's just like a string, essentially. And so we had to create this custom layer that allows us to communicate between flutter and that JavaScript web browser. And then the Babylon systems have to be built out to recognize those and send events the other way so that when a user tapped a button on the Flutter side to switch to side View, for example, it would tell Babylon. We would like animate out the overlays and then turn the camera, then animate the back end for those overlays. So we have this coordination and orchestration layer now that seamlessly connects these two worlds together. And when you're using the app, you wouldn't know. And that's the key. That's what I think we're all trying to, trying to strive for as engineers is we want our customers and our consumers of our apps to believe what we're showing them. I say this all the time. UI is just a facade. We're just having you believe what we want you to believe and what you're seeing. And so we built this out and it feels 3D, it feels native. The whole thing is just completely connected. You wouldn't know there are two systems. And that to me is a huge success. And so yeah, we brought 3D to Flutter. *.

Speaker A: Yeah, that's awesome. I mean what a really cool and interesting thing. Uh, have you guys done any open sourcing of that or any sort of blog posts or developer?

Speaker B: Yeah, so we're working on that. Actually I have an article going out on my LinkedIn a little later and that kind of gets a bit more detailed. We had to develop a web server and this sort of stuff too that runs on device to uh, serve these files. We had to get ODR on device resources in play too because we went to go submit to the Google Play store and they said your app's too big. And we said what? There's a, there's a limit. Uh, we didn't know this. Right? It's, it's just like we, we've been dealing with code and just assets and so yeah, I've got an article coming out with that that'll provide a lot more details. And uh, we are looking to get that communication layer to an open source repository kind of like, like Pigeon is because I think that providing examples on how to do this sort of multi layered system and keep them in sync through messages, I think it's really, really powerful. And there's a lot of use cases outside of even 3D where you could bring these two pieces together. And so I think that that messaging layer is kind of the missing link between those things and it's really a pretty great way to solve for complex things like this. While we wait for Flutter and the open source gods out there that are, that are doing great work that I just stand on the backs of to bring this sort of stuff more natively in and, uh, I'm really excited about the future of native Flutter 3D. And thanks to impeller and stuff like that, that kind of had to happen first. And I think we've got some big challenges with GPU and such like that, just like Web did. And that's why Web worked. That's why Babylon worked, is because all of this effort to get 3D to work in browser has already been done. But now all that effort has to be done now within the Flutter ecosystem to get the communication to GPUs across multiple phone types and that sort of stuff. That's the big challenge next, which a lot of headway on that recently, which is great to see. So we're looking to open source that, and I think that could be pretty useful to a lot of people.

Speaker A: That's awesome. Well, I'm glad you were here to tell the story too, because I think the more people hear about the use cases and the opportunities, the more I think people get motivated to like, all right, let's invest in solving this problem too, right? Because if you guys are using that in a really cool, compelling way, what would be the alternative? You'd have to maybe figure out how to get Unity or some other 3D tool, or could you not even do it?

Speaker B: Um, and we prototyped that out, actually, so we thought about Unity as well. We've got a whole team that does Unity here because of our goal simulation software. And so that was actually one of the first things that we thought of was like, let's just embed Unity. And then you realize to do that, you have to be on a very specific version of Unity. The layer is just not there. Unity actually recommends against it, uh, because of the communication layer. It's not something you can't do, but it's a lot more of a challenge, for sure. And then when Unity is not running, you're still using 200 megs of RAM on your app just to have Unity loaded. So now you've increased the. Increased your utilization of precious resources, I'd say, on mobile devices, especially as we think about all of the markets of mobile devices, not everyone has the iPhone Pro Max, where we could take advantage of that. So we're trying to satisfy the entire market, uh, of devices to be able to support this sort of stuff. And so slowly, Unity became less and less of an ideal choice. And so we had to kind of get really creative. And that's where we got to Babylon.

Speaker A: That's very cool. Well, thank you so much for, for sharing that. It's really, um, exciting Innovative uses of it. And I'm happy to hear you guys are pushing the boundaries there, um, to take us through a little bit of like technology leadership. Right. I think you've told so many interesting stories. You have a, a very sort of like risk tolerant background, very sort of self actualized kind of pursuing things. You're leading teams, you've gone through these acquisitions, um, and you're in a leadership position in engineering. So when you kind of think about everything you've learned and all these things you've worked through, what are some of the things you've learned about being an effective engineering leader in a company like Foresight or some of the other roles you've had?

Speaker B: Yeah, I think for me it's all about trying to help the engineers that work with me as efficient, ah, as possible. Uh, and that means providing them tools, providing them training, providing them procedures and policies and all that sort of stuff that we hate to kind of have. But it helps with structure, it helps with the engineers to be able to do what they're really good at and not have to focus on those other things. And so one of the cultural things that we do here at Foresight is everybody's got a budget for AI tooling and so we've got cursor accounts for everyone, we've got copilot accounts, we've got sort of whatever, whatever AI thing you kind of want to try. We have to help you be more efficient. We're not saying go have AI write all the code because personally I don't think we're there. And I'm hoping we never get there because it takes away, you know, what we love to be as engineers, in my opinion. But AI as an extension, to be able to help make you more efficient and be more efficient, I think is really where the power comes in, into being with, with those sort of things. So you know, we provide that and I provide that to all of all of our engineers. And that helps them be more efficient, which helps them get through tickets faster, which is great for me, but also it's great for them because they get to see stuff, get to production faster and they get to see customers utilize their stuff faster. And that's really what it's about for, you know, individual contributors is them being able to see people utilize their work and them being able to look at a marketing post and go, I built that right. Like that's, that's what the feel good is about. And so it's just, for me, it's really focusing on, on helping individual contributors be More efficient and be more effective and growth opportunities, um, I think are something as a leader you need to always be trying to look at. I have one on ones with, you know, all of my direct reports every, every week or every two weeks and we focus on how can I help you grow. Are you, are you doing this or are you doing that or hey, is there a training program that you want to take or something like that. And ah, then lastly, I'd say for me as a leader, I'm still in the code, I'm still looking at the code. I may not be coding as much as I used to or at all most times, but I'm still keeping myself familiar with the architectural decisions and what code is being pushed. And that allows me to talk to the engineers in a way that they understand as well and it makes them, you know, know that I'm, I'm right there with them in the trenches too. I've, I've gotten in written code to help help us get through features as well. And I think, I think that's an important thing for, for leaders to keep doing and to be able to do is gain that, that sort of trust with, with your individual contributors and, and those engineers that are, I would imagine, looking up to you, right? Like uh, you are their leader and you are trying to help them be as efficient as possible and, and succeed and you're helping the business succeed. And I think the only way to do that is everybody kind of being in the trenches together. So yeah, I still look at code, I still get pull requests, I, I still understand architectural and I, I help guide too. And I think that's for me at least as a leader that's, that's really what's important.

Speaker A: I love that. That's a really wise advice. Um, maybe it's one of those, maybe it's one of these questions, but, or one, one of those points. Um, when you think ahead, ah, 10 years from now, I mean the rate of change right now is so insane. Right? And it's so hard to think about like what we're going to be doing a year or two from now, let alone 10. But when you think back and you reflect on some of the common themes and the lessons you've learned, is there a lesson that you think will absolutely still hold true, like 10 years from now, despite all the change, despite all the AI?

Speaker B: Yeah, I don't know if it's a lesson more so a phrase. So one of my really great, uh, friends and someone that I get to work with, he drove this mentality into me. It's the startup mentality as he calls it. It's the uh, if not now, then when? If not you, then who? And I think about that phrase all the time and it's, it's a really easy phrase but it can be utilized in almost any facet. Not just engineering, but kind of whatever. And I think that's something that continues to stick with me. Ten years from now will still stick with me. It's, it's uh, almost a motto or that you carry along. As I, as I make decisions as a leader, as I make decisions with my teams and so on and so forth. It's, it's driving that mentality to, to the teams as well. And I think that's something I continue to carry and, and I do so in like, even in my non engineering stuff, you know, it's like stuff around the house. It's like, well, is it going to be me or is it going to be me? Right, like so, you know, yeah, somebody's got to, you know, clean up the dishes and whatnot. So yeah, uh, I think that that's definitely what will continue to stick with me.

Speaker A: That's awesome. That's really good advice. Like you said, in general, not just in engineering. I mean it's so important. You just, you got to be able to be motivated and say, hey, I, I got to do this, I got to take responsibility. I have that internal locus of control. I can change the world. I don't need someone else to change it for me. I think that's great. Well, that's a great place to end. Thank you so much for, for um, spending some time with us today, telling the stories. So many interesting things going on with foresight and with what you guys are doing. If people are interested in foresight, sports, your product or maybe uh, a career, uh, um, where can they find out more?

Speaker B: Yeah, definitely. Catch me on LinkedIn. Uh, I post there pretty regularly. We've got articles that share insights into what we're doing, uh, and love to connect through that. And then if you're looking for uh, a golf launch motor, foresightsports.com is a great place to go ahead and pick up one of those.

Speaker A: Wonderful. Thank you so much for the time.

Speaker B: Yep. Thank you.

Speaker A: Thank you for joining us on Build to Succeed, a very good ventures podcast. We hope you enjoy exploring the experiences and insights of leaders that have been built successful digital products. Please take a moment to leave us a review and if you want to get our latest episodes, don't forget to subscribe. Thanks again and see you next time.