Shared engineering where it saves real work.
Avenue reuses technical foundations when the same problem appears across companies. Product-specific technology stays with the business that owns the product.
A practical set of reusable technical systems.
The objective is not maximum code sharing. It is to avoid rebuilding the same infrastructure while keeping company products independent.
Reusable patterns for accounts, permissions, authentication, and secure access when product requirements overlap.
Structured data, event flows, reporting foundations, and operational visibility that can be understood across systems.
Monitoring, logging, deployment patterns, error visibility, and practical operational controls.
Reusable integration patterns where commercial and technical requirements genuinely overlap, while company-specific payment flows remain distinct.
Automation and interfaces for repetitive operating work that should not be rebuilt independently without reason.
Commerce-specific and software-specific systems stay with NIO and Dominion when the customer requirement is unique to that company.
Build common primitives. Keep the products loosely coupled.
A shared foundation is useful only when it stays understandable, replaceable, and compatible with company-level ownership.
Shared primitives
Small, reusable foundations instead of a single monolithic platform.
Visible data
Reporting and operational signals designed to make system state understandable.
Reliable by default
Common practices for access, resilience, monitoring, and recoverability.
Loose coupling
Company products should be able to evolve without hidden dependency on unrelated systems.
Product code stays close to the product.
NIO's commerce systems exist because NIO is an ecommerce business. Dominion's software systems exist because Dominion is a software business. Avenue only owns the layer that makes sense to share across those different contexts.
Clear interfaces are more useful than forced consolidation.
The platform favors explicit ownership and small interfaces between systems rather than hidden dependencies across the portfolio.
Catalog, checkout, order, fulfillment, returns, and customer-commerce workflows remain NIO-specific.
Software product, account, entitlement, delivery, and service workflows remain Dominion-specific.
Identity patterns, data foundations, observability, reliability, and internal tooling can be reused where appropriate.
Technology should improve the operating system, not decorate it.
The useful shared layer is often invisible to customers: better monitoring, clearer internal tools, consistent data, and fewer repeated infrastructure decisions.
Do not reproduce the same infrastructure in multiple companies without a reason.
Prefer systems that teams can understand, operate, and replace over clever shared abstractions.