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

David DeRemer:

Hi, I'm David, and this is Build to Succeed from Very Good Ventures. Today we meet with Kody Peterson, Director of Software Engineering at Foresight Sports. In this episode, we explore Kody's engineering leadership experience building high performance apps with exceptional user experiences. At Foresight, Kody'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 Kody. 

Welcome, Kody. Thanks for coming on the podcast today. 

‍

Kody Peterson:

Super excited for this one.

‍

David DeRemer:

Got a chance to meet you recently, and really appreciate what you guys are doing at Foresight. So wanted to get an opportunity to talk with you and share your story. But one way I like to start is, tell 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?
‍

Kody Peterson:

Yeah, that's a good one. For me, I've found a love for trains. They're super interesting to me. They use technology from forever ago. A lot of people don't know, when a train's coming up to a crossing, it's just like an electrical line that causes those rails to come down. And so lately I've been experimenting with my 3D printer and trying to print train tracks, and then use a little bit of our Duino, and some servos and stuff, to 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 fun, is 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 lately has been the thing I've been hacking on in my free time.
‍

David DeRemer:

Nice. There's an interesting scale there. Is that physical world interaction—has that influenced how you see software architecture?
‍

Kody Peterson:

Yeah, I think so, because especially here at Foresight, we interact with physical products to a mobile app or to our golf simulation software. And so it's a continued extension of that. Even an Apple Watch, or something like that, 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 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 all the ones and zeros know what's actually happening, which is really the hard part, because they can't see it. So you have to find creative ways to translate that.
‍

David DeRemer:

That's interesting. I might have to check out some of this train tech then. I remember the old Lionel trains that would roll around a Christmas tree or something.
‍

Kody Peterson:

That's right. It's a little bit more advanced than that.
‍

David DeRemer:

Yeah. Pretty neat. Well, so take us back to the beginning. Give us your story. How did you get into engineering, and what led to your current role at Foresight Sports?
‍

Kody Peterson:

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 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 with really large systems. So right straight into big Oracle data warehouses, and that sort of stuff. I'm a newbie to tech, have a little bit of 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 in some way I was able to do it. It's just like figuring out creative solutions. So 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 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 so actually ended up pitching that to the college, and we started working on it a little bit, but then I got this really great opportunity I couldn't turn down to go work for the Walt Disney Company.

‍

And 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 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 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 physical to virtual space again, it always keeps coming around. So I did that for a pretty long time. 
‍

And then I got an opportunity to go work for a startup, 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 sector, well before ChatGPT. So definitely a bit ahead of our time. And so did that for a little while, then moved into management within that ecosystem. Starting 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 really just a lot of different industries. And 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, now what we've got, with this brand new app that we released earlier this year.
‍

David DeRemer:

That's awesome. What a good mix there of startups and then Disney and all those sorts of things. And sounds like in your career, you've had a lot of opportunities to take some risks and try new things, things that maybe someone trusted you to do, or like you're talking about, the database queries. And do you think that that early 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?
‍

Kody Peterson:

I think so. I think it was, one, 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 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 because I felt indebted. It's like you know yourself, how good you are at what you're trying to do. And sometimes in interviews, we definitely try to look a lot better because we're striving to grow and move our career in different directions. And so for me at least, it's like, "Wow, 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 yeah, so then a startup comes around, and you're like, "That's all it's going to be. It's going to be just running all the time, continuously trying to surpass expectations of the customers and 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 risk, for sure.
‍

David DeRemer:

It shows a lot of self-awareness too, when you're in those situations where people are taking a risk on you. I think to turn that into creative energy, to 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, people are taking risks on me to help me out, to invest in me, to give me hard problems and help you move forward." I think that's pretty awesome. 
‍

And when you think about that progression in your career, all the way through now, you've been through an acquisition into Foresight here, were there any key moments or lessons learned that you think have best prepared you to navigate that transition and now be in your current role?
‍

Kody Peterson:

Yeah, that transition is an experience all on its own, I'd say. And I'm glad to be able to have that opportunity to go from startup world to being acquired. And then now you're going to have to prove yourself again, almost. It's like that the acquisition 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 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 really, really small team just doing what they think is best and building the best product they can.
‍

David DeRemer:

Yeah. That's really important, because when you think about acquisition... I think when you read about acquisition, it's like, "Oh, this company got acquired by so and-so." You see the number maybe, and everyone was just like, "Cool, we have this acquisition. Our job is done." It's like, "Nope. Well, the reason that company acquired you is because your job is just starting."
‍

Kody Peterson:

That's exactly it. Yeah. It's just, start that loop again. Yep.
‍

David DeRemer:

Yeah. Well, and so tell us about Foresight Sports. What do you guys do and what's your role there?
‍

Kody Peterson:

Yeah. So here at Foresight, we develop launch monitors. 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 this whole journey. 
‍

But we've got these devices and 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 characteristics of that ball, what it did in rotation, at speed, how far it went, with extreme accuracy. And then additionally, we can provide details on the clubhead 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 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.
‍

David DeRemer:

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 do my swing, and it's tracking my swing, the ball, everything. What's it looking at?
‍

Kody Peterson:

Yeah, it tracks the ball and the clubhead 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 through the flight as well. And then yeah, it's just about visualizing that and providing data. In so many different ways too, because every golfer learns differently. We all learn differently, whether it's golf, 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, 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.
‍

David DeRemer:

Yeah. That's so cool. Sports in particular, I think, has that unique balance of the data, like you're saying, the tabular data, and wanting to get into that, and then the visualizations. We work with a NASCAR team called Trackhouse, and there's like so much data, and some people just only want to look at the numbers, and other people are like, "I can't make sense of this. Can you show me a graph or something? What should I do with this?"

‍

So I think sports in particular has that balance, and having good effective tools to help you iterate through that, I would imagine would be pretty important. So let's maybe get into that. What are some of the technologies you guys are working with?
‍

Kody Peterson:

Yeah. So we're really trying to expand the ways in which we can provide this data. And so in the Flutter space specifically, 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. 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 to look at the design, you wouldn't see anything there that you've seen within UIs themselves. And that's a design language choice.
‍

That was actually one of the things, when we came in through acquisition, 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, because they're all vastly different in our own sizes, and that sort of stuff. And 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 application. If the software doesn't show the same numbers that the device shows, the golfers are going to be asking, "Well, which one's right?" Our customers will wonder [about] 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. 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 have to happen. And then we can even dive into our 3D modeling, which I know we want to talk about. I've previewed 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?" In terms of our game simulation software. It's a really different mindset. It's that startup mentality that we've brought to a large 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 neat technologies that we're pulling in, but a ton of custom Flutter work. So we know a lot about Flutter at this point.
‍

David DeRemer:

Awesome. Yeah. Well, and so much to unpack in what you said there, and so many things about Flutter specifically, that I think are interesting, that idea of building your own design system. Right now, the Flutter team is working on actually taking the material and Cupertino out of the core framework, and things that you could bring back in, for precisely this reason.

‍

The original intent of it was, you build your own design system and your own thing. Yeah, we're going to give you material in Cupertino as something to start with so you can build something easily. But just that acknowledgement that I think a lot of big brands 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 have their own aesthetic and user interface paradigms and stuff. So I think that's been really cool.
‍

So yeah, design system's a big one. And I think it's so cool how you guys 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. Take it and run with it, add more things. Don't just wait for Google to figure it out for you." If you do that, even though they have so many resources, you never know if they're going to get to it. 
‍

How did you get to Flutter in the first place? Were some of these things part of the evaluation criteria, and what led you to it, or were these happy side effects? Tell us the story of going from your trajectory into Flutter.
‍

Kody Peterson:

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 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 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 level of UI design and control that we wanted to do, Flutter just outperformed in that way.
‍

We ran multiple POCs 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, that we build in-house, to talk to the devices. What bridge exists there, or what would be really well served? And while both React Native and Flutter have a bridge to talk to the Native side, what we were missing on the React Native side was this type safetiness, this really well, easily orchestrated 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 checkbox on the Flutter side for us. And so once we identified we wanted to go the Flutter route... And additionally, in the golf startup, PinSeeker, 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 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 code generation stuff, that we could 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 from scratch."? Because there's no magic, convert this React Native over to Flutter, as much as we would love that. Or convert this Native to Flutter even, because that would make a lot of our jobs a little bit easier, but it doesn't exist. And so 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?"
‍

David DeRemer:

And so did you build a brand new Flutter app or did you integrate into the React Native app? Or how was the approach there?
‍

Kody Peterson:

So for this one, we built from scratch. We just started a new repo, spun up Flutter, brought in some foundational components from PinSeeker, 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 individuals, that new Native iOS and 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 IOs?" 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 throw it away, essentially, and just build it from Flutter." And so we had to start doing add-to-app strategies. Which is probably, 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 some 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 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 keep designs across Flutter and Native the same. So it was definitely one of the biggest challenges we had at PinSeeker, 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 end we would be all Flutter. And eventually we got there, 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 switching to Native and switching to Flutter, and back and forth.
‍

David DeRemer:

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? And then there's the other side of Flutter, that I think is cool, you start with Flutter and add Native to it or add other things. You can go that side too, right? 
‍

But when you think about coming into Foresight, and you had this existing React... Because this is at, really, the critical point of the debate around Flutter, React Native. 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 the teams who had seen both, what's your honest take around how those two... They're both great technologies. It's cool we have them both, but what's your honest take around the pros and cons?
‍

Kody Peterson:

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, Microsoft Edge versus Google Chrome, on the React side. So I think that's one of the big things that you could look at React Native and go, "Wow, finding talent is really easy there." The Flutter talent pool is a bit smaller, right? It's still, I'd say, a new community. 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, as we looked at the two, is, sure, React Native 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? It doesn't have that to fall back on. It's got Dart, but they 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, mobile, desktop, web even.
‍

And so I think that's really where it comes down to me on it, is, what are you going to be doing with it? What is your use case in trying to understand what you're trying to do with it in the future even? Which is a hard thing to think about. 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 MVP, right? It's really hard to think about in the future, but if you put some thought into that now, you'll likely make the best decision for your future self as well.
‍

David DeRemer:

No, that's insightful. And so many people want to know what's the answer, right? Just tell me which one to pick. And there's never just one answer. Because you're right, 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. 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 they're expert at TypeScript, they're probably going to pick up Dart and Flutter pretty quickly.
‍

Kody Peterson:

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

David DeRemer:

Yeah. And like you said, what are your objectives? Are your objectives to build high performance, data driven experiences, where you want to have full control of your design system and you don't want to worry about... 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 very tight control over how your app looks on every device that runs it, well, that can be a huge pain, of like, what if somebody's 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 rendering engine with your app, and it's going to look the same everywhere.
‍

You also mentioned about having to convince leadership, and work through, how do you sell this internally? Take us a little bit through that habit, maybe even going back to the PinSeeker days, and then coming into Foresight, I guess, and pitching Flutter into this existing team, what are those conversations like?
‍

Kody Peterson:

Yeah. In the PinSeeker days, it was a little bit easier. Smaller team, it's startup, so you 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 business conversation becomes, how do we, as quickly as possible, begin the migration process? 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 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 and 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, that can 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 to prove a model across all these other companies 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, 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 is 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 move to 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 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's 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 if Flutter's 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, than keep building it with what you have.
‍

David DeRemer:

Right. Yeah, that's very insightful. 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, 2 Native for eight years, and they've just diverged so much that to ship a new feature in with parity, it's so hard because the architectures are so different. We're now maintaining different APIs in the backend to talk to them, and all this stuff." And that's 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 want to completely rethink this, and 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, I'm curious how many people out there have taken a React Native app and then pitched like, "Let's go to Flutter." 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 leadership who, they're looking at P&L and everything, they're 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. Why would we do that?" What are the one or two, besides the design, which it sounds like might maybe is one of the two things in the UX, what else really resonated in that discussion with leadership, you think, in retrospect?
‍

Kody Peterson:

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 questions, like, "Okay, so you want me to not only approve you finding 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 go.
‍

And so yeah, I think it really comes down to that 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 one's to 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's 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.
‍

David DeRemer:

Find the right reasons, find the right time. That's very, very wise advice. And I think that's what's so cool about that story, is, you're right, when you're talking about Native to either React Native or Flutter, you have that whole thing of like, "Oh, well, just can do more with less." Generally, that one's a pretty easy sell to management a lot of times, even though there's a cost upfront to do that. But yeah, your ace card was taken off the table right out of the gate with that one. So kudos to you for getting there.

‍

And I think it really demonstrates also the experience you guys had had already, and the ability to demonstrate that performance and that improved user experience you're going to get out of it. Speaking of improved user experience, I know you guys are also pushing the boundaries a bit with Flutter. You mentioned some of the 3D work you're doing. Can you tell us a little bit about that?
‍

Kody Peterson:

Yeah, I'd love to. Yeah, that project has been really exciting, from an engineering perspective. So we, once again, went into this mentality with design of, "Hey, Blue Sky, show us what you want to do and we'll figure out how to implement it."

‍

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 the club head, and then allow you to see the angle at which your club was, in multiple views. And so we thought they're going to come to us with a static image that we can just rotate and we can plop a little point on, and all is good, and we could totally do that in Flutter.
‍

And they came to us with a 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 like 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 much 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 look around it.

‍

But I knew we needed way more than that. I knew there wasn't camera controls. There wasn't a 3D scene, there's none of that. And so we started to 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 talk by the SpaceX Starlink team, who, from what I understand, actually builds their app in React Native. And they were coming to the same 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 no 3D standard support in React Native. And they came up with a solution to utilise JavaScript and HTML technologies to put 3D embedded into 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 an in-app web frame and we loaded the HTML JavaScript in there, and we had 3D in 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 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 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. 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 web view transparent, and we could now have Flutter sit on top and below this web view.
‍

But now we needed to coordinate these systems. We've got two vastly different systems that are running in their own 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 structured messages, right? It's the similar problem that Pigeon is working to solve. 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 had to be built out to recognise 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 animate out the overlays and then turn the camera, and then animate the backend 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 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 in what you're seeing. And so we built this out, and it feels streaky, it feels native. The whole thing is just completely connected. You wouldn't know their two systems. And that, to me, is a huge success. And so yeah, we brought 3D to Flutter, asterisk.
‍

David DeRemer:

Yeah. That's awesome. What a really cool and interesting thing. Have you guys done any open sourcing of that? Or any blog posts or developer content or anything?
‍

Kody Peterson:

Yeah. So we're working on that. Actually, I have an article going out on my LinkedIn a little later and that gets a bit more detailed. We had to develop a web server, and this sort of stuff too, that runs on device to 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 limit." We didn't know this, right? It's just like, 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 we are looking to get that communication layer to an open source repository, like Pigeon is, because I think that providing examples on how to do this 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 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 doing great work, that I just stand on the backs of, to bring this sort of stuff more natively in. And I'm really excited about the future of Native Flutter 3D.

‍

And thanks to Impeller, and stuff like that, that 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, 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.
‍

David DeRemer:

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." Because 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?
‍

Kody Peterson:

And we prototyped that out actually. So we thought about Unity as well, where we've got a whole team that does Unity here because of our golf 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 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 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 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 get really creative, and that's where we got to Babylon.
‍

David DeRemer:

That's very cool. Well, thank you so much for sharing that. It's really exciting, innovative uses of it, and I'm happy to hear you guys are pushing the boundaries there.
‍

Take us through a little bit of technology leadership, right? I think that you've told so many interesting stories. You have a very risk-tolerant background, very self-actualized in pursuing things. You're leading teams, you've gone through these acquisitions, and you're in a leadership position in engineering. So when you 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?
‍

Kody Peterson:

Yeah, I think for me, it's all about trying to help the engineers that work with me as efficient as possible. And that means providing them tools, providing them training, providing them procedures and policies, and all that sort of stuff that we hate to 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, whatever AI thing you 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 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, and to be with those sort of things.
‍

So we provide that, and I provide that to 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 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." That's what the feel good is about.

‍

And so it's just, for me, it's really focusing on helping individual contributors be more efficient and be more effective, and growth opportunities, I think, are something as a leader you need to always be trying to look at. I have one-on-ones with all of my direct reports every week, or every two weeks, and we focus on, "How can I help you grow? 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 then lastly, I'd say for me, as a leader, I'm still into 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 know that I'm right there with them in the trenches too. I've written code to help us get through features as well. And I think that's an important thing for leaders to keep doing, and to be able to do, is gain that trust with your individual contributors and those engineers that are, I would imagine, looking up to you, right?
‍

You are their leader and you are trying to help them be as efficient as possible, and succeed, and you're helping the business succeed. And I think the only way to do that is everybody in the trenches together. So yeah, I still look at code. I still get pull requests. I still understand architectural, and I help guide too. And I think that's, for me at least, as a leader, that's really what's important.
‍

David DeRemer:

I love that. That's really wise advice. Maybe it's one of these questions or one of those points, when you think ahead 10 years from now... The rate of change right now is so insane, and it's so hard to think about 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?
‍

Kody Peterson:

Yeah. I don't know if it's a lesson, more so a phrase. So one of my really great friends, and someone that I get to work with, he drove this mentality into me. It's this startup mentality, as he calls it. It's the, if not now, then when, if not you, then who? And I think about that phrase all the time. And it's a really easy phrase, but it can be utilized in almost any facet, not just engineering, but whatever. And I think that's something that continues to stick with me, 10 years from now will still stick with me. It's almost a motto that you carry along as I make decisions as a leader, as I make decisions with my teams, and so on and so forth, it's driving that mentality to the teams as well. And I think that's something I continue to carry.
‍

And I do so even in my non-engineering stuff, it's like stuff around the house. It's like, "Well, is it going to be me or is it going to be me?" So yeah, somebody's got to clean up the dishes and whatnot. So yeah, I think that that's definitely what will continue to stick with me.
‍

David DeRemer:

That's awesome. That's really good advice. And like you said, in general, not just in engineering. It's so important. You got to be able to be motivated, and say, "Hey, I've 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 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 a career, where can they find out more?
‍

Kody Peterson:

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

David DeRemer:

Wonderful. Thank you so much for the time.
‍

Kody Peterson:

Yep, thank you.
‍

David DeRemer:

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 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.

‍