One runtime for contracts, services and lifecycle behaviour reused across compatible Boost plugins.
WORDPRESS PLUGIN ARCHITECTURE
Boost Core
ONE SHARED RUNTIME. SMALLER, FOCUSED PLUGINS.
Boost Core is the shared WordPress plugin runtime beneath the Boost ecosystem. It centralises reusable contracts, services and lifecycle behaviour so common infrastructure is maintained once while each consumer plugin keeps ownership of its product logic.
RUNTIMEMODULARITYSHARED SERVICES
SYSTEM / PRODUCT MAPBOOST CORE
Boost CoreRUNTIME / MODULARITY / SHARED SERVICES
Fix common behaviour at the foundation instead of copying the same patch into multiple consumers.
Keep product logic in the consumer that owns it, so reuse does not collapse the suite into one monolith.
THE PROBLEM
SHARED INFRASTRUCTURE SHOULD BE FIXED ONCE.
Duplication is cheap only at the first copy. After that, contracts, lifecycle helpers and integration primitives start to drift. A shared WordPress plugin foundation gives genuinely common behaviour one owner, one hardening path and one place to improve.
Multiple Boost plugins repeat the same infrastructure, contracts and runtime helpers with slightly different implementations.
A bug fix in shared behaviour has to be copied across consumers, increasing release risk and maintenance cost.
Product-specific plugins become larger because reusable foundations have nowhere else to live.
WHAT IT DOES
WHAT BELONGS IN THE SHARED LAYER.
Move a concern into Core only when several consumers need the same contract and can depend on it without importing each other's domain behaviour.
01 / USE CASE
Shared contracts
Stable interfaces and reusable services become dependencies instead of copy-paste infrastructure.
02 / USE CASE
Runtime lifecycle
Common bootstrap, lifecycle and integration behaviour lives in one controlled layer where fixes can propagate coherently.
03 / USE CASE
Consumer autonomy
Each Boost plugin keeps its own domain logic and user-facing responsibility while consuming only the shared foundation it needs.
PRODUCT BOUNDARY
CORE OWNS THE COMMON LAYER. CONSUMERS OWN THE PRODUCT.
A shared runtime only works when the boundary is explicit. Boost Core centralises infrastructure that is truly reusable; domain behaviour, workflows and user-facing responsibility stay inside the plugin that owns them.
GOOD FIT WHEN
Boost Core has one clear job.
A good fit when several Boost consumers need the same runtime contracts and infrastructure while remaining separate products with separate responsibilities.
KEEP OUT WHEN
Boost Core starts owning the wrong problem.
Boost Core is infrastructure, not a feature catalogue. It should not absorb domain behaviour just because two plugins look similar; shared code belongs here only when the contract is genuinely reusable.
IMPLEMENT WHENThe responsibility is explicit.
Add the system only when its job, inputs, outputs and failure boundary are clear enough to review. Otherwise it adds another layer without removing the original friction.
QUESTIONS BEFORE CHOOSING IT
QUESTIONS THAT PREVENT THE WRONG IMPLEMENTATION.
The product should solve a real constraint, not create a new category of work. These questions make the boundary explicit before implementation.
Do I use Boost Core on its own?
Usually it exists to support compatible Boost consumers. The value is the shared runtime foundation rather than a standalone front-end feature.
Does Core turn all Boost plugins into one monolith?
No. The architectural goal is the opposite: centralise reusable foundations while keeping product-specific behaviour in the consumer that owns it.
Why centralise shared infrastructure?
Because contracts, hardening and fixes can be maintained once when they are truly common, reducing duplicated code and the chance that consumers drift apart.
SYSTEM / NEXT STEP
USE THE SYSTEM ONLY WHEN IT REMOVES REAL FRICTION.
START WITH THE RESPONSIBILITY.
If this problem matches the project, we can decide whether Boost Core belongs in the stack, what it should own and what it should leave alone.
DISCUSS THE PROJECT