Over roughly two years, Rapsodo Studios grew from zero into a team of 10 to 11 people developing a production-ready golf simulation platform from the ground up. We did it with a deliberately lean organization and a total investment in the low single-digit millions of dollars.
We built not only the simulation itself, but also the gameplay and physics systems behind it, a high-fidelity real-time rendering foundation, specialized golf-course production technology, a dedicated course-building editor and pipeline, reusable tools and workflows, and the foundations for online services and analytics. Along the way, our organizational operating system, execution model and culture, built around continuous learning, constant improvement and a strong work ethic, became some of our biggest sources of leverage.
With the product now approaching release, I want to take the opportunity to look back at what we set out to build, how we approached it, where that leverage came from, and which organizational choices helped a small technology team develop considerably more capability than its headcount alone might suggest.
Building a Technology Organization from the Ground Up
After years of building software, studying organizations and seeing both successful and failed products throughout my career, I had come to believe that a small, autonomous, high-ownership team, given the right people, systems and context, could create disproportionate software capability with less organizational overhead, shorter feedback loops and stronger product focus. That belief became an important part of how I approached building Rapsodo Studios and, more broadly, how I think about high-performance technology organizations building complex products across games, simulation and interactive technology.
When we started building Rapsodo Studios, very little of that capability was already in place. There was no established game studio to inherit, no mature simulation software organization, and no complete production platform waiting for a team to operate it.
A production-grade golf simulation requires several interconnected capabilities. It needs realistic golf physics and trustworthy shot behavior; gameplay systems, rules, cameras, practice experiences and competitive modes; a modern real-time rendering foundation capable of producing high-fidelity golf environments across different performance targets; online foundations for connected experiences such as multiplayer, tournaments, leaderboards, accounts, data collection and analytics; and, of course, golf courses.
That last challenge eventually became a significant technology problem of its own. Producing realistic digital representations of real golf courses repeatedly and efficiently requires more than environment art. It requires geospatial data, terrain processing, specialized workflows, reusable course systems, validation, documentation and a production pipeline. That led us to build a dedicated golf course-production system and editor where art, geospatial data and engineering come together.
We weren’t only building outputs. We were increasingly building the systems that produced those outputs.
Systems and Ownership Before Headcount
Software organizations have a tendency to grow around complexity. As product scope increases, organizations naturally add people and specialized roles. But without well-defined systems, cultural norms and clear ownership, increasing the size of the organization can begin creating complexity almost as quickly as it creates capacity.
More people create more coordination needs. More coordination creates additional management needs, processes and organizational dependencies. If these are not designed carefully, the result can be more meetings, more questions and slower decisions, creating frustration and organizational friction.
With Studios, we wanted to approach the problem differently. Rather than starting with organizational scale, we wanted to start with systems, ownership and capability. We decided that repeated work should be turned into systems wherever practical, and that the organization should invest in capabilities that make future work easier rather than simply completing the immediate task.
For most of this journey, Studios operated with approximately 10 to 11 people, primarily organized around art and engineering teams. We have never had product managers, producers, project coordinators or dedicated manual QA roles, nor equivalent roles under different titles.
We deliberately built the organization around the people with the relevant context, gave them end-to-end ownership, kept decisions close to that context, removed unnecessary coordination layers, and turned repeatable parts of the work into systems, tools and automation.
This was not a model built around compensating for fewer people with longer working hours. Across roughly two years of development, the team worked only a few hours of overtime in total. We relied instead on continuous planning, early visibility into risks and open communication, giving us time to adjust scope, priorities or execution before problems turned into deadline crises.
Hiring for a High-Ownership Organization
From the beginning, we designed our hiring process around making this model possible. Every candidate was evaluated not only on technical knowledge, but also on their reasoning, problem-solving ability, communication, judgment and approach to ownership. We removed practices we found ineffective and treated the hiring process itself as a system to continuously improve. After interviews, hires, performance reviews and departures, we revisited the process and introduced new approaches based on what we learned.
We applied the same discipline to how quickly we grew. Studios did not grow from two people to ten at once. We added people gradually over almost a year, giving the operating model and culture time to become understood, practiced and owned by the existing team. New hires therefore entered an environment where expectations, ownership and ways of working were already established in practice. We considered not only whether a candidate was ready to join Studios, but also whether the organization was ready to absorb another person without weakening what we were building.
Throughout that process, we did not lower the hiring bar. There were positions we waited months to fill, some we eventually closed without hiring anyone, and others we filled within days when we found the right person. A lean, high-ownership organization depends heavily on finding people with both the professional capability and the autonomy, judgment and responsibility the model requires. As a result, talent availability became one of the most significant constraints we encountered. When we couldn’t find the right person, rather than hiring simply to add capacity, we adjusted scope and roadmap around the bandwidth of the existing team while protecting the targeted quality and delivery timeline. Protecting that standard also meant making difficult decisions when someone was not a fit for the organization we were building.
Turning Recurring Problems into Infrastructure
The same principle applied to how we approached recurring complexity. Whenever we encountered a problem that was likely to repeat, whether across teams in something like course production or within a smaller area such as physics development, we asked whether the solution could become infrastructure.
Infrastructure in this sense did not always mean software. It could mean a clearer ownership model, proper documentation, automation, a reusable tool or a better-defined workflow. Most importantly, we tried to turn knowledge that existed only in someone’s head into a repeatable process that another capable person could understand and execute.
These investments can sometimes look slower than simply solving the immediate problem. They require time and effort before their value becomes visible. But if the objective extends beyond producing a single product once, and instead is to build an organization capable of producing complex interactive software repeatedly, investing in systems and reusable capability becomes an economic decision, not merely an engineering preference.
Building Organizational Capability Alongside the Product
When I look at what we built at Studios, I think there are actually two outputs. The first is the visible one: the product and its technology foundation. The second is organizational capability: the ability to take complex and sometimes ambiguous problems, structure them, establish ownership, build the necessary systems and convert them into working software.
That second output matters because software products rarely stand still. Technologies change, markets change, requirements change and new products emerge. Over the long term, what matters is not only what an organization has already built, but whether it has developed the capability to keep building.
There is also a compounding effect between these two outputs. The simulation and gameplay technology, high-fidelity course rendering, course-production technology, online foundations, production systems and golf-domain capability we have developed can continue supporting the existing product. Much of that capability can also provide reusable foundations for future game, simulation and interactive products. The organization does not have to begin every new problem from zero.
Leverage Before Scale
I don’t think the lesson from Studios is that every technology company should have ten people. Different products, stages and markets require different structures, and sometimes adding people is exactly the right answer. But before increasing the size of an organization, I think it is worth asking what is actually limiting the team you already have. Headcount is only one way to increase what an organization can accomplish.
The same team can accomplish significantly more when ownership is clear, decisions can be made without unnecessary coordination or approval layers, risks become visible early, knowledge is documented instead of remaining with individuals, repetitive work is automated and recurring problems are turned into reusable tools and systems.
Before adding organizational scale, it is therefore worth asking whether the existing organization can first become more effective and capable.
That principle has shaped much of how we built Rapsodo Studios. So the lesson I take from Studios is not “stay small.” It is: build leverage before you build scale.