3 roles inside one project vs 1 projects for each role

In my opinion there is not much use for splitting a project for just that reason.

Everything you do after splitting the project into 2, you could also do with a single project and splitting the views and controllers into 2 folders (view/buyers/*, Controllers/Sellers/ItemController.php)

And about the pro's you named:

Since they still use the same DB, by doing a migration in 1 project, you could very well kill parts of the other project (untill its code is updated to reflect the new DB structure).

And code being more safe because noone has all projects code...... except for all the developers right? Or the person that gets into your repo, or the server..... So actually, it's just as safe as the single project.

Unless you really need your frontend to run from another server, I see no reason to split up a project into multiple.

Ok, but what if I have the project structure as below: Seller Frontend and BackEnd together. Buyer 2 different Frontend (one for desktop & one for mobile like a SIngle Page Application) and one BackEnd. Should I split it now? This is the structure of our project we want to build: https://imgur.com/a/L5MYEMe

The short answer is No. Don't split it since it will be very cumbersome to manage as it grows.

In Laravel it's very easy to make middlewares to determine what kind of user you are logged in as and the apply it to the admin routes.

As for the different devices one site is enough. Just use css to manage the layouts for mobile and desktop. There are frameworks that can help you with this i.e. Tailwind and Bootstrap.

But we use some UI frameworks wich similar to native App Design for mobile website, like some popupers or notification windows. This is the reason we start thinking about spliting it to different projects.

Also we want to split domains like: site.com - for buyers desktop m.site.com - for buyers mobile seller.site.com - for sellers

Many projects like tmall.com, beru.ru or alibaba.com have a separeted domain name for a desktop & mobile version of the project. Also they did different names for buyers and sellers. In this case I can create different landing pages with beautyful domains, check this: http://site.com http://seller.site.com or http://site.com/buyer http://site.com/seller

http://site.com/buyer http://site.com/seller is good and keep it in the same project.

Route::get('/sellers', 'SellersController@index');
Route::get('/buyers', 'BuyersController@index');

:)

( disclaimer; just an opion based on projects I work on, might be completely irrelevant to people working on different projects with different requirements, and I tend to change opinions over time :D Kind of hoping other people firmly object to this with some good constructive criticism.)

In your given example you will still have a lot of overlap in functionality, personally i'd keep everything the same codebase. Because on both sides you are still working a lot with generic stuff like; categories, brands, products.

And even somewhat more advanced stuff has a lot of overlap altho it being with a different label. What a customer considers to be an order a seller will consider it to be a sale.

Yes an order might have different functionality to a sale it also has a lot in common for example displaying the products sold or showing ordervalues.

It is possible to workaround those issues by extracting it to packages and some might even prefer that.

But to use models as an example i'd much rather have a default Order model with generic stuff and have a CustomerOrder and a SalesOrder both extending that Order with functionality specific to the context in there.

Or namespacing them, like I would with controllers and in my routes.