amrmohamed25/moneyfellows

1. This is a single Laravel monolith, not a split frontend/backend app. The user interface is server-rendered with Blade templates, while Laravel handles routing, controllers, models, auth, scheduled jobs, and persistence.

2. The presentation layer lives in resources/views and app/View/Components, with shared layouts for guest/authenticated areas. The UI is built from Bootstrap, jQuery, and compiled assets in resources/js, resources/css, and public/ via Laravel Mix.

3. Request handling starts at public/index.php and flows through Laravel middleware in app/Http/Middleware and app/Http/Kernel.php. Main web routes are in routes/web.php; routes/api.php, routes/channels.php, and the Jetstream API-token views exist as supporting auth/platform features rather than a separate public API.

4. Authentication and account management are provided by Jetstream/Fortify. The app/Actions/Fortify and app/Actions/Jetstream classes implement registration, password reset/update, profile updates, and account deletion. The repo also includes 2FA, email verification, browser-session management, and API token management views/tests.

5. The core business domain is the “MoneyFellows” money-circle workflow, modeled around three main entities: Category, Current, and User. Categories are the admin-created templates; currents are active/instance money circles derived from a category; users join currents through the current_user pivot table.

6. app/Http/Controllers/CategoryController.php and app/Http/Controllers/CurrentsController.php are the main application controllers. Category management is the admin boundary, while currents controller likely drives user actions such as requesting to join, editing participation timing, leaving before start, and paying.

7. The persistence layer is Eloquent models plus migrations in database/migrations. Besides the core tables for users, categories, currents, and the current-user pivot, the schema includes notifications, sessions, failed jobs, password resets, and personal access tokens.

8. Payments are integrated through Laravel Cashier with Stripe, as described in the README. The payment flow is rendered in the payment.blade.php view and is tied to the current lifecycle: once a circle starts, users can pay their fee and the system tracks payment state and due dates.

9. Notifications are first-class in the architecture. app/Notifications/NotifyUser.php and the notifications table indicate Laravel’s notification system is used to alert users about starts, due dates, and payment-related events; the app relies on persisted notifications rather than only transient UI messages.

10. Time-based business logic is handled by Laravel’s scheduler and console command layer. app/Console/Commands/everyDay.php plus app/Console/Kernel.php are used to run daily checks for payment status, apply extra fees, collect payments, and update due dates. This is a key backend subsystem, not just a helper.

11. The app’s boundary between admin and user behavior is mostly business-rule driven rather than a separate role subsystem. The README describes the admin as the creator of categories, while users consume those categories to create/join currents; both use the same authentication system and diverge in controller/view behavior.

12. Operationally, this repository looks like a standard Laravel deployment with artisan, config/*, storage/*, and tests in tests/. The test suite is heavily focused on Jetstream/Fortify authentication features, which suggests the business workflows are implemented in the app code but are less exhaustively covered than the auth layer.