I ve been building mobile applications for years, and one thing kept bothering me. A new project may be an educational platform, a business network, or a content ecosystem, but a large part of the underlying work is familiar: authentication, permissions, content structures, push notifications, backend APIs, databases, deployment, and native iOS/Android infrastructure.Eventually I started wondering whether we were optimizing the wrong thing. Instead of making each new project faster to develop, could the repetitive engineering itself become reusable infrastructure?The analogy I kept coming back to was Henry Ford. Ford didn t invent the assembly line from scratch; production-line methods existed before him. His achievement was to reorganize automobile manufacturing around them so effectively that Model T assembly eventually fell from about 12.5 hours to 93 minutes. The obvious trade-off was standardization - famously summarized by Ford as “any colour ... so long as it is black.”We tried something slightly different with software: standardize the production process without standardizing the final product.Over several years we built an architecture with a common native core in Swift and Kotlin, metadata-driven configuration, and an automated deployment pipeline. Different projects can have different functionality, structures, permissions, interfaces and branding, while each deployment gets an isolated backend and database on the owner s own server.We ve now published 250+ native applications using this approach. It’s proof that the concept works not just in theory, but in the real world - powering everything from educational platforms to business networks and content ecosystems. A new deployment has become closer to configuration and automated assembly than to starting another software project from an empty repository. Depending on the project, the native apps and isolated backend can be deployed within 24 hours rather than spending months rebuilding the same “zero-cycle” infrastructure.This is not intended as an app-builder or another multi-tenant SaaS model. The part we re trying to reuse is the engineering system underneath the product, while the result remains an independently deployed native mobile platform.And this has left us with a question I didn t expect to have.Tim O Reilly recently wrote about a conversation with Red Hat founder Bob Young, who described what Red Hat was really selling to customers as control. O Reilly s broader point was that open infrastructure lets people build on systems they depend on without having to ask the owner for permission.That resonates with why we chose self-hosting in the first place: the organization should control its server, data and applications rather than depend permanently on our cloud.But if control is the principle, who should control the technology that produces those independent platforms?We re a small engineering team. Open-sourcing the core could allow others to build on it without us, but the organizations best positioned to absorb years of engineering work may simply be the largest ones. Keeping it closed protects the system and its development, but then we remain the central dependency in an architecture intended to reduce central dependencies.For those who have faced a similar decision with infrastructure or developer tools: where did you draw the line between open and proprietary, and why?