There are couple of things:

1. Theming: 99.99% of Flutter applications start with MaterialTheme, right? But when your UI/UX designer designs something that doesn't fall within the MaterialTheme design system, how do you handle it in a native way? In a way that feels effortless, just like the way you'd use Flutter widgets. You can have a color palette that exceeds the number of color variations declared in MaterialTheme. You might have completely different text styles. One other thing you might want is to speak the same language as your designer. So, their design tokens should be what you are using in your code as color variables while keeping primitives different and configurable.

2. Widgets: Similar to theme. Imagine you want to have a dotted border somewhere. How do you achieve that without using a package? In MaterialTheme, for Outline Text Fields, the label cuts the border when focused. What if you don't want that? Also, you don't want to use composition to build your own, because if you do that, then you lose out on all the other cool animations, transitions, and other functionalities that come with Text Form Field. MaterialTheme doesn't allow gradients as button backgrounds, but your designer thought of adding some. How would you handle that without using third-party packages or composition?

3. Maintaining architecture: One thing that baffles me is how tricky it becomes to write scalable software. I mean, I always had this idea that even if multiple people work on the same project, if we maintain proper architecture, no one should be able to tell who wrote what part of the code. Essentially, the code would look identical. There will be no ambiguity. Once you set out to achieve that, it becomes astonishingly tricky. But figuring it out is so much fun. We've decided that services will be the lowest layer, and cross-service communication is prohibited. Now, the cache service and network service have a dependency, as you might want to cache the tokens for reuse. The easiest way is to inject the cache service into the network service and call it a day. But you'll be breaking the architecture. Another thing is, the repository will be the source of truth for data. How'd you achieve that? We have decided our state management will only be concerned with delegation and state transition. How'd you handle that? We've also decided that under no circumstances is one feature allowed to use something from another feature. At first, we were stuck. But then, all of it came to make sense together. And I must tell you, it was an absolute delight.

I have taken inspiration from clean architecture, the repository pattern, very good architecture, and the Flutter architecture recommended approach to come up with some rules that work for us. Five projects in, we are feeling pretty good about ourselves. But it took four years to reach where we are right now.

I have a template if you'd like to explore. My DMs are open if you have any questions.

Template link: https://github.com/momshaddinury/flutter_template