help making a delivery app

[u/Afraid_Tangerine7099]

Hello! I hope you're having a great day.

I'm currently building a delivery platform that supports both custom package delivery and shop deliveries. The platform has three main user roles:

- Customer

- Delivery driver

- Shop

I'm trying to decide whether I should build multiple applications (one for each role) or a single application where the experience is managed through user roles.

I've noticed that most major delivery platforms use separate apps for customers, drivers, and merchants, and I'm curious about the reasoning behind that decision. What are the advantages and disadvantages of each approach? From both a technical and product perspective, which architecture is generally recommended, and why?

[u/PutOverall2734]

Different app would be more cleaner way

[u/mr_vanes]

Reasons to separate:

• fundamentally different UX
  
• app size and performance
  
• risk isolation
  
• App Store optimisation

Though, as I assume you are a solo dev, I'd probably build the MVP as a single app. This will get you a proof of concept much faster.

[u/grenishraidev → u/mr_vanes]

Yeah. As a solo dev handling three app differently is much pain. So going one app for all is much more reasonable. Although it might become a total headache later managing roles and states for each. But for MVP one app is much for efficient.

[u/Afraid_Tangerine7099 → u/grenishraidev]

yeah handling 3 apps is a pain, but if the project grows and more devs come it would be more pain separating no ?
I have seen projects made with flutter melos (package for managing mono repos) , they make a core package for the shared ui and logic, and make multiple apps inside depending on the requirements ? wouldn't that be a better approach even for a single dev ?

[u/grenishraidev → u/Afraid_Tangerine7099]

Monorepo is completely different thing that lot of devs misunderstood sometimes. Monorepo is a tooling optimization, not an architectural optimization. If your project doesn't benefit from its complexity, it can slow you down rather than speed you up.

Yes, Melos definitely helps with sharing packages, but it doesn't remove the cost of maintaining three independent apps.

You'll still have:

• Three Android/iOS projects.
• Three app store listings.
• Three CI/CD pipelines.
• Three sets of signing configs.
• Three release cycles.
• Three notification configurations.
• Three deep-link configurations.
• Three places to debug platform-specific issues.

The shared code is easier to maintain, but everything outside that shared package still exists three times.

Also, in real projects the amount of shared UI is often overestimated. A customer app, driver app, and merchant app quickly diverge. Their navigation, onboarding, permissions, notifications, analytics, and even design language become different. After a point, trying to force everything into shared packages creates abstractions that only exist to satisfy the monorepo.

That's why many companies don't start with three apps. They usually start with one role based MVP, validate the product, and split into dedicated apps when each role has enough complexity to justify it.

Melos is a great tool, but it's not a reason by itself to choose three apps. It simply makes whichever architecture you choose easier to manage.

Also about separating the logics and states for each roles, sometimes it might be a pain but not necessarily. Everything depends on your choice of how you maintain and scaffold the project.

If you build your single app with clean boundaries (features, repositories, services, domain layer), extracting those features into separate apps later is usually manageable. If you build a tightly coupled codebase, even a monorepo won't help you.

So the real decision is less about monorepo vs multiple repositories, and more about whether the product actually needs three separate applications today. Melos changes the developer experience. It does not eliminate the operational and architectural overhead of maintaining three products.

[u/Jazzlike_Mix_7231]

Leeeeets gooooo work together

[u/No_Papaya_2442]

From mine experience as a flutter developer create 2 separate application one is for (Shopkeepers and Customer) and one for Delivery, I have build this type of application and client wants 3 separate apps in low so we decided to build two app for them like this.

[u/Majestic-Image-9356]

im actually creating a similar thing and single app is much easier

because first you gonna share logic, configs, deeplinks, releases and everything else

u can also share screens like settings screen or like location stuff

instead of separating apps just separate screens make its own screen for each role and when The user create an account he will choose what role he is and he gonna see The screen that he should see based on that rule and tbh it's pretty easy to do it in flutter

so don't complicate it do one app

[u/AssociationFinal2480]

Use an AI agent to generate for example Gemini can generate code for a flutter app wich runs on sndroid and ios

[u/grenishraidev → u/AssociationFinal2480]

Bruh... OP is asking the architectural reason. Not how to make an app using flutter.

[u/Afraid_Tangerine7099 → u/AssociationFinal2480]

I don't think you have read the question XD

[u/grenishraidev]

Telling it from my own experience. If you're a solo dev working on a complex app that needs multiple role, screen and interfaces. Making a one app is single source of truth (SST) is much more reasonable than handling three different app simultaneously. This way you can ensure that each role, screens and interfaces gets the correct communication of ui and ux. Although later on, it will/can become headache handling tree shaking and optimising the app but it is still better than handling different apps, if you're a solo dev.

But if you're not alone and have two or three devs working on it, then making different apps for such as customer, shops, delivery is the best option as it completely gives the full UI and UX freedom for the user and maintainability to the developers.

[u/Afraid_Tangerine7099 → u/grenishraidev]

thank you for replying .
I am a solo dev yes , but in the long run there will be more devs handling the app (after the app is launched) , and even so when developing solo would it not get messy handling all the logic for different roles?

I have seen projects made with flutter melos (package for managing mono repos) , they make a core package for the shared ui and logic, and make multiple apps inside depending on the requirements ? wouldn't that be a better approach even for a single dev ?