Launch monitors have become part of modern golf.
Whether you’re booking time at an indoor simulator, getting fitted for new clubs, or trying to understand why one driver seems to outperform another, chances are a launch monitor is somewhere in the picture. The technology has transformed the way golfers practice, but it’s also created the impression that building one requires enormous engineering teams, years of research, and resources available only to a handful of companies.
Then along comes a project like OpenFlight.
During a recent Life At The Turn Live Q&A, we welcomed software engineer Coleman Rollins to talk about an idea that has attracted growing attention throughout the golf simulator and launch monitor community. OpenFlight is an open-source launch monitor project, but that description barely scratches the surface. Our conversation covered everything from radar technology and artificial intelligence to community-driven development and the realities of building something most people would never attempt.
By the end of the evening, it became clear that OpenFlight isn’t simply another piece of golf technology. It’s a different way of thinking about how golf technology can be created.
It Didn’t Start With a Business Plan
Ask most founders where their company began and you’ll usually hear a familiar story. There was a gap in the market. A business opportunity appeared. An idea slowly developed into a product.
Coleman’s answer couldn’t have been more different.
Golf season had slowed down, work had become quieter, and he suddenly found himself with time to tackle a technical challenge. Building a launch monitor wasn’t part of some long-term roadmap or carefully considered startup plan. It was simply a problem that seemed interesting enough to explore.
That distinction matters because it shaped the entire direction of the project.
Rather than trying to design a commercial product from day one, Coleman approached the challenge with a far simpler question.
Answering that question meant stepping well outside his own experience. His background is in software engineering, not radar systems or golf launch monitor design, so the first stage of OpenFlight involved far more learning than building. Research quickly became part of the daily routine, with technical documentation, hardware specifications and countless questions gradually replacing assumptions with understanding.
Listening to him describe those early weeks, it was obvious that curiosity drove every decision. Each answer uncovered another problem worth solving, and every solution opened the door to something else that hadn’t yet been considered.
That process still feels embedded in OpenFlight today.
Learning Faster Without Skipping the Hard Work
Artificial intelligence inevitably entered the conversation because it has become impossible to discuss software development without acknowledging how much the landscape has changed over the past few years.
Coleman spoke about AI in a way that felt refreshingly practical.
Instead of describing it as something that built OpenFlight for him, he explained how it accelerated the learning process. Moving into unfamiliar technical territory meant there were constant questions to answer, whether they involved radar concepts, hardware integration or software development. AI became another tool for exploring those questions, helping him understand subjects that would otherwise have required significantly more time to work through.
None of that removed the responsibility of proving the answers were correct.
Code still had to be tested.
Hardware still had to function.
Ideas still had to survive real-world validation.
That perspective stood out because conversations around artificial intelligence often become exaggerated in one direction or the other. Some people expect it to replace developers entirely, while others dismiss it outright. Coleman described something much more grounded. AI shortened the distance between a question and an informed starting point, but it couldn’t replace experimentation, troubleshooting or the experience gained by solving problems firsthand.
OpenFlight exists because someone remained curious enough to keep asking better questions.
Building in Public Changed Everything
Most golf companies spend years developing products before anyone outside the business knows they exist.
Prototype after prototype is tested behind closed doors, mistakes are corrected privately, and consumers only see the finished version once every detail has been polished.
OpenFlight followed the opposite path.
As development progressed, Coleman began sharing updates online. Early followers watched radar modules spread across a workbench, temporary enclosures held together by whatever materials happened to be available, and software evolve through constant experimentation. Nothing looked particularly polished because polish wasn’t the goal.
Progress was.
When I asked about those early posts, Coleman never suggested there was some carefully planned marketing strategy behind them. He simply enjoyed documenting the journey, and people found it interesting enough to keep following along.
Something unexpected happened as that audience grew.
People stopped acting like spectators.
Software developers began offering suggestions.
Engineers shared ideas from their own experience.
Golfers volunteered to test new builds and report what they were seeing.
Questions turned into discussions, discussions turned into improvements, and before long OpenFlight had become something much larger than a personal side project.
Looking back, that openness may have been one of the most important decisions Coleman ever made, even if it wasn’t really a decision at all.
Instead of asking the community to believe in a finished product, he invited them to understand how it was being built.
Trust developed naturally because people witnessed every success alongside every setback.
By the time our conversation moved toward the technology itself, the launch monitor had already become only part of the story.
The project had also become proof that innovation doesn’t always happen inside large companies with closed doors and dedicated research departments. Sometimes it begins with one person asking an interesting question, sharing the process openly, and discovering that hundreds of others want to help answer it.
Looking Beyond the Hardware
Eventually, our conversation reached the question every golfer was probably waiting for.
How do you actually build a launch monitor?
It’s easy to look at a finished device and assume the challenge lies in assembling the right collection of electronics. Buy the radar, write some software, package everything neatly, and you’ve got a launch monitor. Listening to Coleman describe the process quickly put that assumption to rest.
The hardware, as it turns out, is only the beginning.
Coleman explained that deciding to use radar wasn’t about proving it was better than camera technology or claiming one approach had an advantage over another. Every launch monitor on the market is trying to answer the same questions about the golf shot, but the path each manufacturer takes to reach those answers can look very different. Camera-based systems observe impact through high-speed imagery. Radar continuously tracks movement after the ball leaves the clubface. Both approaches are capable of producing excellent results, but they ask engineers to solve completely different problems.
That distinction became more interesting the longer we talked.
Most golfers evaluate a launch monitor by looking at the numbers on the screen. Ball speed, carry distance, launch angle and spin are either believable or they aren’t. Very little thought is given to everything that happens between impact and those final figures appearing in the software. Coleman pulled back the curtain on that process, explaining that radar doesn’t simply hand over finished measurements waiting to be displayed.
Instead, it produces an enormous amount of raw information.
Before any useful data reaches the golfer, the software has to determine which signals belong to the golf ball, filter out interference, interpret movement, and perform thousands of calculations that ultimately become the numbers we rely on during practice sessions and club fittings. Building confidence in those calculations has consumed just as much time as developing the physical hardware itself.
That was probably the biggest revelation for me.
Until this conversation, I’d always thought about launch monitors as pieces of equipment. Coleman described them more like software platforms built around sensors. The radar collects information, but the software gives that information meaning. Without sophisticated processing, even the best hardware in the world is little more than an expensive collection of components.
That perspective also explains why OpenFlight has evolved through so many iterations. Every improvement to the algorithms creates another opportunity to compare results, identify inconsistencies and refine the system again. Progress isn’t measured by adding another feature to a specification sheet. Progress comes from reaching a point where the next shot inspires just a little more confidence than the one before it.
Naturally, the conversation drifted toward spin.
Few measurements receive more attention from golfers because few measurements are more difficult to get right. Club fittings depend on it. Equipment comparisons often come down to it. Better players use it to shape shots, while everyday golfers rely on it to understand why one drive flies forever and another seems to fall out of the sky.
Rather than presenting spin as a box that had already been checked, Coleman spoke candidly about the work involved in getting there. He explained that measuring spin has been one of the most demanding parts of the entire project, requiring continual refinement as more testing takes place. There wasn’t a story about one breakthrough that suddenly solved everything. Improvement has arrived the way engineering projects usually do, one problem at a time.
That honesty has become one of OpenFlight’s defining characteristics.
Commercial products typically appear once the difficult work is already finished. Consumers see polished hardware, marketing videos and carefully prepared demonstrations without ever knowing how many dead ends came beforehand. OpenFlight has unfolded in public from the very beginning, allowing people to watch the setbacks, celebrate the breakthroughs and understand why certain problems take weeks or months to solve.
Perhaps that’s why the community has grown alongside the project instead of simply following it.
As Coleman shared updates, people with different backgrounds started finding ways to contribute. Software developers reviewed code. Engineers offered technical suggestions. Golfers tested new builds in their own simulator setups and reported what they were seeing. Questions raised inside Discord often led to improvements that benefited everyone using the platform.
Listening to Coleman describe those interactions, it became clear that OpenFlight isn’t being built by a traditional product team. It’s evolving through hundreds of conversations, countless experiments and a community willing to share knowledge instead of protecting it.
By the time we moved on to the next topic, the launch monitor itself almost felt like the outcome rather than the objective.
The real story wasn’t about one person proving that a radar launch monitor could be built at home.
It was about discovering what becomes possible when an entire community decides to solve the same problem together.
Looking Ahead Without Rushing There
Eventually, I asked the question that felt impossible to avoid.
Where does OpenFlight go from here?
By that point we’d spent the better part of an hour talking about radar, software development, artificial intelligence, testing, community feedback and everything that goes into building a launch monitor from the ground up. It would have been easy for Coleman to answer with a list of upcoming features or milestones still waiting to be checked off.
That wasn’t where he took the conversation.
Instead, he talked about continuing to improve the project the same way it has always improved. Test another build. Solve the next problem. Learn from the community. Repeat.
It sounds almost too simple.
Then again, so did the original idea.
Listening to Coleman, it became obvious that OpenFlight has never been driven by artificial deadlines. There wasn’t any sense that the project had to arrive at a particular destination by a particular date. Every improvement creates another opportunity to ask a better question, and every answer uncovers another challenge worth exploring.
That’s probably why the community continues to grow alongside it.
People rarely stay invested in a project simply because they’re waiting for the next software update. They stay because they enjoy being part of the process. Throughout our conversation, it was clear that OpenFlight has become far more collaborative than Coleman ever expected. Developers contribute code because they see interesting engineering problems. Golfers share testing results because they want to help improve the data. Others simply enjoy watching an ambitious idea evolve in public instead of behind closed doors.
Somewhere along the way, the project stopped feeling like one person building a launch monitor.
It started feeling like a group of people building knowledge together.
That might be the part of this story that surprised me the most.
Golf equipment has traditionally been something we consume. Manufacturers develop products, golfers buy them, and very little happens between those two moments. OpenFlight quietly challenges that model. It invites people into the messy middle, where ideas change, assumptions are tested and improvements happen one conversation at a time.
You don’t have to understand radar processing to appreciate that.
You don’t need to write software to enjoy seeing a difficult engineering problem gradually come into focus.
In many ways, that’s what made this Live Q&A so enjoyable. Yes, we spent plenty of time talking about launch monitor technology, but the conversation never became so technical that it lost sight of the people behind it. Coleman spoke with the same curiosity that started the project in the first place, and that curiosity turned out to be contagious. By the end of the evening, it was easy to find yourself wondering not just how OpenFlight would develop over the next year, but what other ideas are waiting for someone willing to tackle them in the open.
Maybe that’s OpenFlight’s most meaningful contribution.
Not because it promises to replace every commercial launch monitor.
Not because it’s open source.
Not because it’s powered by radar.
Those are all interesting parts of the story, but they aren’t the story itself.
What stayed with me after the conversation ended was something much simpler.
Innovation isn’t always born inside polished laboratories or billion-dollar companies. Sometimes it begins with one person looking at a problem, admitting they don’t yet know the answer, and deciding to learn anyway. Share that journey with enough people, stay honest about the setbacks as well as the breakthroughs, and you create something that becomes bigger than the product sitting on the workbench.
Whether OpenFlight eventually becomes a fixture in golf simulator setups around the world is a question only time can answer.
The more interesting thing is that it has already changed the conversation.
It has reminded golfers that technology doesn’t have to feel mysterious.
It has shown developers that their work can have an audience beyond other engineers.
Most importantly, it has demonstrated that curiosity has a habit of attracting company.
That feels like a fitting place to leave the story.
Not because OpenFlight is finished.
Far from it.
The next update will arrive.
Another challenge will appear.
The community will pull it apart, improve it and move forward again.
And if this conversation with Coleman Rollins taught me anything, it’s that watching that process unfold may prove just as interesting as whatever the finished launch monitor eventually becomes.