Not every useful healthcare software idea needs to become a separate SaaS product. Some problems are small, focused and operational: prepare a roster, calculate something, generate a document, guide a user through a structured workflow or provide a specialised reference interface.
For those cases I am using a plugin-based /apps/ model inside WordPress. Each app is rendered by its own plugin and can have its own interface, while the main website continues to provide the domain, deployment environment and portfolio context.
Why a micro-app instead of another page
A normal page is appropriate when the user mainly reads content. A micro-app is appropriate when the user enters data, makes choices, receives a calculated or generated result, or follows a stateful workflow.
Trying to build that behaviour inside a page-builder layout usually mixes application logic with presentation. A dedicated plugin gives the workflow its own code, validation, permissions and data model while still allowing it to appear at a clean URL such as /apps/health-camp-planner/.
The distinction also helps users. An app can feel like a focused tool rather than a long website page with controls inserted into it.
Keep each app isolated at the plugin layer
The main rule in this model is that the micro-app should not depend on the active theme for its business logic. The plugin owns routing, data processing, permissions and the application UI. The theme can provide a surrounding brand shell where appropriate, but changing the theme should not break the app.
Isolation also makes maintenance easier. A health-camp planner, a medicine explorer and a utility calculator can evolve independently even though they live under the same /apps/ namespace.
Where an app needs its own database tables or scheduled tasks, those resources belong to that plugin rather than to a generic site-wide code file.
Use one domain without making every app look like the main site
A shared domain has practical advantages: one deployment environment, simpler discovery, consistent trust and easier portfolio linking. It does not mean every app must inherit the exact visual layout of the main portfolio site.
A focused tool may need a denser toolbar, application-style navigation or even a largely independent shell. The plugin can render that experience while still using the same domain and, where useful, the same WordPress authentication.
This is especially useful for small professional tools that deserve a stable URL but would be over-engineered as separate domains and hosting stacks.
Share only the infrastructure that should be shared
The value of one WordPress installation is not that every component must share everything. It is that selected infrastructure can be reused deliberately.
Users and capabilities may be shared when the app needs login. The Media Library may be shared for assets. Common security conventions, backups and deployment can be shared. But app-specific settings, tables and workflows should remain namespaced and isolated so one plugin does not create hidden dependencies on another.
Public visibility should also be a conscious choice. Some micro-apps can be indexed and serve as useful public tools; internal operational apps should be protected and excluded from search. The /apps/ path is an organisational pattern, not a requirement that every app be public.
When a micro-app should graduate into a larger product
The micro-app model works best while the problem remains focused. If an app develops complex multi-tenant accounts, independent billing, heavy background processing, large-scale APIs or infrastructure requirements that no longer fit comfortably inside WordPress, it may deserve a separate product architecture.
That transition is easier when the original plugin has clear data boundaries and application logic. The first version can validate the workflow without pretending to solve the scaling problem before it exists.
For me, this is the main attraction of the /apps/ approach: it lowers the cost of turning a useful domain-specific idea into a working tool while keeping a clear path to something larger if real usage justifies it.