The obvious move is wrong

The default builder move is to create a new repo for every app.

That feels clean in the first week and becomes expensive by the third or fourth launch.

You duplicate:

• auth
• OAuth setup
• user tables
• billing glue
• blog and publishing logic
• deployment work

That is not leverage. That is overhead pretending to be architecture.

What actually matters for this portfolio

The lmachine portfolio needs a shared spine:

• one account
• one identity model
• one activation path
• one entitlement model
• one place to publish notes and docs

That is why the right starting point is a monolith.

Why Laravel fits

Laravel gives enough convention to keep the codebase fast without making the system stiff.

The stack is opinionated in the right places:

• Blade for public surfaces
• Livewire and Volt for interactive server-driven UI
• Fortify for auth
• Passport for first-party OAuth
• Horizon and Redis for queue visibility
• Boost for agent-aware development

The result is one deployable system with room for many surfaces.

What this does not mean

A monolith is only good if the internal boundaries are real.

So the repo is being shaped around capabilities, not vibes:

• Identity
• Access
• Billing
• Launch
• Feedback
• Publishing
• Apps
• Admin

That is how you keep a monolith from turning into a junk drawer.