Independent project franchising: reasons why large software companies should support innovation rather than stifle it.

      TL;DR: Major software companies often develop internal tools that become valuable, but then neglect them when priorities change. Robert Brownstein suggests "independent project franchising," which allows engineers who are familiar with successful internal tools to create an independent venture, with the parent company as the initial customer and licensing partner. PwC data indicates that 42% of CEOs fear they are not adapting quickly enough, while Deloitte warns that agile AI-native competitors are reducing the cost baseline for software.

      Innovation typically doesn't die from failed experiments; it fades when there's no ownership. Large software firms can create useful ancillary tools and validate their effectiveness, but they may neglect these projects when leadership shifts focus to core products or urgent tasks. My main point is that when a beneficial internal project no longer aligns with corporate goals, companies should contemplate granting it independence before they let it go.

      Timing is crucial. In PwC’s 2026 Global CEO Survey, 42% of CEOs expressed concern about their ability to transform swiftly enough to keep up with technological advancements, and 29% doubted their capacity for innovation. Nonetheless, a related PwC study found that while half of CEOs view innovation as central to strategy, only 8% had fully implemented at least five of the six practices that support it. The industry is ambitious but lacks sustainable structures to carry promising initiatives through periods of changing priorities.

      Software engineers recognize this trend. Companies identify a need, allocate resources to develop a solution, and generate momentum around the project. Months later, it is deemed “sufficiently finished.” The engineers move on, leaving bug reports, security issues, and integration requirements behind. I refer to this repeated cycle as “initiative thrash”: teams develop context and commitment, then lose both when new directives emerge.

      The consequences extend beyond the initial development budget. Engineers often continue to be accountable for code they no longer have time to enhance. Upon their departure, their institutional knowledge is lost. The new team must either piece together prior decisions, work around overlooked architecture, or rewrite unmanageable code. Thus, a seemingly completed project can transform into an ongoing organizational burden.

      This issue is becoming increasingly urgent as software economics evolve. Deloitte’s 2026 Global Software Industry Outlook notes that software development is becoming faster and cheaper, while lean AI-native competitors are challenging established firms. However, quicker production does not ensure long-term ownership; it merely allows organizations to create more projects that later compete for resources.

      I propose a compromise between keeping projects in-house and abandoning them: independent project franchising. I am not referring to traditional retail franchising; I mean enabling those closest to a promising, non-core capability to establish a small independent venture around it. The parent company could act as an anchor customer, maintain a license or minority economic stake, and provide limited transitional funding. The new venture would gain the freedom to serve external customers and develop a sustainable product rather than merely an internal feature.

      This arrangement can mitigate risks for both parties. The parent company avoids making an indefinite commitment to an untested product, while the venture benefits from a defined first customer, skilled engineers, and a recognized market need. If demand falters, the experiment is contained. Conversely, if the product thrives, the parent can continue licensing it, enhance the partnership, acquire it, or reintegrate the capability. Independence serves as a testing phase rather than a severance procedure.

      My shift from corporate software development to independent product creation has altered my perspective on this issue. Now, I develop and test products independently, including browser-based graphical tools. Without corporate priorities redirecting my work every few quarters, I can address the same technical challenges across various products and clients. This continuity doesn't guarantee success, but it fosters cumulative learning because those receiving feedback are responsible for how the code evolves.

      This model should be selective. Companies should not spin out flagship products, strategically important infrastructure, or software that cannot be safely detached from sensitive data and systems. Moreover, entrepreneurship should not become a euphemism for offloading corporate risk onto employees without adequate funding, rights, or a viable customer base. EY’s 2026 survey of technology leaders in Ireland revealed that 36% cited talent shortages and approximately 30% cited budget constraints as major challenges. A spinout won’t resolve either issue if it starts with inadequate staffing and funding.

      Before approving a spinout, leaders should seek evidence of demand beyond a single internal sponsor, a dedicated technical owner, well-defined intellectual property and data boundaries, a support agreement, funding milestones, and an agreed-upon shutdown procedure. Both the team and the parent company must understand what they own, what can be used, and what the course of action will be if the market response is unfavorable.

      Large software companies consistently seek ways to foster innovation internally. However, that question might be too narrow; they should consider how a solid idea can gain sufficient autonomy, time, and accountable ownership to determine its viability in the market. The greatest risk to corporate innovation isn’t that every experiment