Reuse is valuable only when avoided product work exceeds the new shared burden. This model names both sides, calculates a conservative break-even point and supplies exit criteria. Every quantity in the worked example is hypothetical; the method supports accountable studio judgement rather than automatic platform expansion.
Define the decision in avoided work
A shared studio system earns its place only when the product-specific work it avoids exceeds the coordination, integration and maintenance work it creates. Reuse is therefore an economic decision about a named capability, not a general preference for platforms. Compare one bounded proposal—such as account settings, build tooling or a content pipeline—against separate implementations over the same review period.
Write the baseline first. Estimate the effort for each product to build, test and maintain its own solution. Then describe the shared alternative: common core work, adapters, migrations, governance and recurring support. Keep uncertain estimates as ranges. A shared system with a vague boundary cannot produce a trustworthy break-even calculation.
Use a transparent break-even equation
Let avoided duplicate cost equal the sum of separate product costs minus the product-specific adapters that remain. Let shared cost equal core construction, migration, coordination and maintenance. Break-even occurs when cumulative avoided cost exceeds cumulative shared cost, after including the cost of delay and expected coupling failures. Use the same unit throughout, whether days, money or capacity points.
In a hypothetical example, two separate implementations cost 18 days each and 6 days per period to maintain. A shared core costs 24 days, two adapters cost 5 days each, migration costs 8 days and shared maintenance costs 8 days per period. The initial shared route costs 42 days versus 36 separately, but saves 4 maintenance days per period. Break-even arrives after 1.5 periods. Every quantity is hypothetical.
Price coordination and coupling explicitly
Coordination cost includes agreeing on interfaces, scheduling compatible changes, reviewing cross-product effects and supporting contributors who do not own the core. Coupling cost covers forced upgrades, broader failure impact and compromises that make either product less coherent. These costs are easy to omit because they appear in meetings, queues and delayed decisions rather than in the shared repository itself.
Add a coupling multiplier when products change at different speeds or have different reliability needs. Do not hide the multiplier inside a generous contingency. Naming it makes the decision reversible: if adapter churn or blocked product work exceeds the threshold, pause adoption, narrow the common surface or return a capability to product ownership.
Adopt in stages and measure evidence
Begin with the smallest stable seam. One product can consume the shared interface while the other remains on its existing path, provided the comparison is safe and bounded. Measure integration effort, defects crossing the boundary, maintenance time and lead-time effects. Recalculate with observed ranges instead of defending the original estimate.
Define exit criteria before adoption: ownership becomes unclear, an adapter exceeds its budget, a shared failure affects unrelated work, or the review-period saving remains below the hurdle. Preserve migration notes only as long as needed, restrict access to sensitive business data and delete or redact records under a defined rule. Measurement does not justify indefinite retention.
Use portfolio breadth as context, not proof
Viotus publicly describes an independent studio spanning worlds, financial software and AI systems without reducing itself to one category. That breadth makes the reuse question concrete: different products can share a studio while still needing different technical boundaries. The public article does not prove that any particular internal system is shared, nor does this method claim one.
Use the linked studio article to understand the public portfolio context, then run the calculation for a specific capability with accountable human owners. Approve reuse only when the conservative range clears the hurdle and the products retain coherent control. A result below break-even is useful: it protects product-specific work from an abstraction whose coordination cost exceeds its value.