I used to be one of them. Writing boilerplate APIs, managing dependencies, rebuilding the same UI components.

The tools were already there but I wasn’t aware how deadly they are when they are used individually and in combination. And now I use them in every app, like my most recent app - FUT Maidaan.

This article is going to share those packages. Feel free to acknowledge if you are using these or haven’t used them.

If you are figuring out what is FUT Maidaan then discover yourself by downloading the app.

iOS App

Android App

Get_it + Injectable: DI That Actually Works

Dependency injection in Flutter starts simple. You pass a repository to a widget. Then that widget needs another service. Soon you're passing five objects through 10 constructors just to reach the widget that needs them.

Get_it solves the access problem.

Injectable eliminates the boilerplate.

That lazySingleton annotation does heavy lifting. Injectable scans your code, finds these annotations and generates all the dependency registration code. No manual setup. No forgotten dependency registrations.

The real magic happens with the mono-repo structure. Each package declares its own dependencies and these dependencies are executed on app launch. Only non-lazy ones are gonna be instantiated.

Injectable knows to inject ApiClient and SupabaseClient automatically. When you need the repository anywhere in your app, just ask for it. No prop drilling. No global variables. Just clean dependency injection that scales with your app.

The combination reduces your mistakes and makes you focus on writing business logic and not the wiring code. Every hour saved on dependency management is an hour spent on features users actually care about.

Share

Melos: Mono-repo Without the Pain

Flutter's package management wasn't built for large apps. Create ten packages with interdependencies and watch your productivity die. Change one shared model? Update five pubspec files. Run pub get five times. Wait for five builds.

Melos changes the game entirely.

3 commands replace 30. But the real power is in the structure it enables.

I organized FUT Maidaan into clear boundaries:

• Quality layer - Shared lint rules and test utilities

• Utility layer - Cross-cutting concerns like navigation and DI

• Core layer - Business logic, API clients, design system

• Feature layer - Actual screens users interact with

I have written a complete article just on the Mono-Repo, which addresses package distribution and their co-working relationship in detail. I think this is a must read, if you want to really create a scalable Flutter app.

Tech Front

Inside Mono-Repo Flutter Architecture - FUT Maidaan

Most Flutter developers build their apps like a single giant house where everything lives under one roof. The kitchen connects directly to the bedroom, the bathroom shares pipes with the living room and when you need to fix the plumbing, you have to tear down half the structure. This approach worked fine when I was building small apps but when I started…

Read more

10 months ago · 1 like · Prateek Sharma

Running build_runner in all packages with just 1 command

That script runs code generation only in packages that need it. Change a model in the domain package? Only domain regenerates. The player feature package stays untouched. What used to take five minutes now takes thirty seconds.

Package management becomes invisible. You think about features and architecture, not about keeping dependencies in sync.

Subscribe now

Dio + Cache Interceptor: Smart API Calls

Mobile users have limited data. Servers have limited capacity. Yet most apps hammer both with redundant requests.

Player stats don't change every second. So why fetch them every time?

This configuration creates intelligent caching. Fresh data serves from cache instantly. Stale data triggers a background refresh. Network errors fall back to cached data. Users see instant responses while data updates silently.

Combined with Retrofit for type safety:

No more parsing JSON manually. No more runtime type errors. The compiler catches mistakes before users do. Each endpoint becomes a simple method call with full IDE support.

The cache even handles offline scenarios. Users can browse previously viewed players without internet. The app feels fast because it is fast. Cache-first architecture with automatic invalidation - the best of both worlds.

Leave a comment

Supabase: Skip the Backend Entirely

Traditional app development means building two systems. Your Flutter app and an entire backend with authentication, APIs, database management and many more.

For now I am just using Supabase database and Edge functions. This app will have authentication later which will then include RLS on tables and more user driven data.

If you want to know how easy it has been to filter players by any type of query in Flutter, check this article.

Tech Front

Building Supabase Filters That Actually Work

Supabase promises database queries that "just work…

Read more

9 months ago · 1 like · Prateek Sharma

The GUI makes development visual. See your data structure. Test queries interactively. Debug permission issues instantly. When building complex filters with nested OR conditions, visual query building beats writing SQL in the dark.

File storage? Built in. Row-level security? Configure in the dashboard. Indexes? Easy to setup. Cron Runs? Easy to maintain and monitor. Every backend feature you'd spend weeks building already exists and works.

Subscribe now

Mappable + Bloc: State That Scales

State management is where Flutter apps become unmaintainable. Manual JSON parsing. Forgotten copyWith parameters. Equality checks that miss fields.

Dart Mappable automates the mundane:

One annotation generates:

• fromJson and toJson for API communication

• copyWith for immutable updates

• == and hashCode for proper equality

• toString for debugging

No manual maintenance. Add a field, regenerate, everything updates. Remove a field, the compiler catches every usage.

This pairs perfectly with Bloc's event-driven architecture:

Every state change is traceable. Every update is immutable. The compiler ensures you handle all states. Testing becomes trivial events in, states out, no surprises.

The combination enforces good patterns. You can't accidentally mutate state. You can't forget to handle loading states. The architecture guides you toward maintainable code.

Build Runner: The Compound Effect

Code generation sounds boring until you realize its impact. Every model needs serialization. Every service needs registration. Every API needs implementation.

Build Runner automates it all:

But the magic is in what it generates. Take this API definition:

Build Runner creates the entire implementation. HTTP calls, error handling, JSON parsing - everything generated. You write the interface, the tool writes the implementation.

With mono-repo structure, generation becomes incremental:

• Touch a model in domain? Only domain regenerates

• Add an API in api_client? Only api_client rebuilds

• Create a new bloc in a feature? Only that feature updates

Five-minute builds become thirty-second updates.

Subscribe now

Firebase Test Labs: Testing on Real Devices

Emulators lie. Your high-end development phone lies. Only real devices tell the truth.

My first release proved this. Perfect on my iPhone and Samsung S20. Crashed on low-end Samsung devices. Firebase Test Labs caught what I missed.

This tests on flagship phones, mid-range devices and ancient hardware. Different Android versions. Different memory constraints. Different CPU speeds.

The results are enlightening. That smooth animation? Janky on old phones. That clever algorithm? Times out on slow processors. Test Labs is must before you submit app to google play, otherwise after multiple rejections your app will be suspended and you will have to change package id and name of the app, which I had to do. That’s why you see FUT Maidaan on iOS and FUTMaidaan on Google play.

Combined with BDD tests for clarity:

Feature: Player Data Loading

  Scenario: Player data loads successfully
    Given I am on the player list page
    When the page loads
    Then I see text {'Lionel Messi'}
    And I see text {'93'}
    And I see text {'RW'}
    And I don't see text {'Loading...'}

  Scenario: Player data fails to load
    Given I am on the player list page
    And the network is unavailable
    When the page loads
    Then I see text {'Failed to load players'}
    And I don't see text {'Lionel Messi'}
    And I see widget {RetryButton}

  Scenario: Loading state is displayed
    Given I am on the player list page
    And the API response is delayed
    When the page loads
    Then I see text {'Loading...'}
    And I see widget {CircularProgressIndicator}
    And I don't see text {'Lionel Messi'}

Anyone can read these tests. Product managers. Designers. New developers. Clear tests catch bugs before users do.

Most importantly when you upgrade to newer Flutter version and update dependencies, you might have fixed all compilation issues but runtime issues will only be caught in tests without running and checking whole app.

The Compound Architecture

These tools create something greater than their parts. Each combination solves specific pain points:

Get_it + Injectable removes dependency management friction. Write business logic, not wiring code.

Dio + Cache + Retrofit creates type-safe, offline-capable APIs. Users get instant responses and servers get fewer requests.

Mappable + Bloc enforces immutable, testable state management. Bugs become compiler errors.

Melos + Build Runner enables true incremental builds. Change one file, rebuild one package.

The architecture emerges naturally. Clean boundaries between packages. Clear data flow through layers. Testable components at every level.

This isn't over-engineering. It's acknowledging that apps grow, requirements change and good architecture pays dividends. Every shortcut in month one becomes technical debt in month six.

Start With Your Pain Points

You don't need every tool immediately. Start where it hurts most.

Drowning in prop drilling? Add Get_it + Injectable.

Fighting with API boilerplate? Try Dio + Retrofit.

Managing multiple features? Introduce Melos.

But commit to structure early. A mono-repo might seem excessive for five screens. By screen fifty, you'll thank yourself. Clean architecture might feel rigid initially. When adding features becomes trivial, you'll understand why.

These tools saved me weeks. But beyond time, they brought predictability. Predictable builds. Predictable state. Predictable deployment. In software development, predictability is the foundation of speed.

Ship faster by building better foundations. These tools show you how.

But every developer knows the truth: filters break, performance crawls and what looked simple in the docs becomes a debugging nightmare at 2 AM.

I've spent months untangling Supabase filter chains in FUT Maidaan, discovering patterns that transform fragile queries into bulletproof data pipelines.

Here's the exact system I use to build filters that handle millions of rows without breaking a sweat.

If you are figuring out what is FUT Maidaan then discover yourself by downloading the app.

iOS App

Android App

The Monster We're Dealing With

Before we dive in, let me show you the complexity we're tackling. This is a real filter function from FUT Maidaan - a football player database with thousands of cards:

That's twelve different filter types. Users can search for "left-footed Brazilian strikers from Premier League with 85+ rating who have the Finesse Shot playstyle." And they expect instant results.

If you're thinking "just chain some .where() calls," you're in for a world of pain. Let me show you why and more importantly, how to build this correctly.

The Domain: Understanding Football Card Filtering

In FUT Maidaan, players have multiple attributes that users want to filter by. A player card isn't just a name and rating - it's a complex entity with leagues, nations, positions, special abilities (roles and playstyles) and various ratings. Users might want to find specific combinations like "German midfielders from Bayern Munich with the Deep-Lying Playmaker role."

This creates unique challenges. A player can have multiple roles and playstyles. Positions aren't just simple strings - they're hierarchical (a striker can play as center forward, right wing, or left wing). And users expect to combine all these filters seamlessly.

The Naive Approach (And Why It Fails)

When I first started, I tried the obvious approach:

This approach has several problems. First, chaining .or() conditions creates increasingly complex SQL that Postgres struggles to optimize. Second, each method call might create a new query instance, leading to unexpected behavior. Third, there's no clear pattern for handling different filter types - some need OR logic, others need AND and some need special operators like contains for arrays.

The PostgrestFilterBuilder Pattern

The key insight is treating your query as a mutable builder object. Here's how the correct approach starts:

Notice how we're reassigning postgresFilterBuilder each time? This ensures we're always working with the latest query state. It's like building with LEGO blocks - each filter adds another piece to your structure.

Subscribe now

Handling Multiple Values: The inFilter Magic

Here's where things get interesting. When users select multiple leagues or clubs, you need to find players in ANY of those selections. The naive approach uses OR chains but there's a better way:

The inFilter method translates to SQL's IN operator, which Postgres optimizes much better than multiple OR conditions. It's cleaner, faster and less error-prone.

The Array Contains Pattern for Complex Filters

Now here's where it gets really interesting. In FUT Maidaan, players can have multiple roles and playstyles. These are stored as arrays of ids in the database. How do you filter for players who have ANY of the selected roles?

The contains method checks if the database array contains ANY of the provided values. This is perfect for our use case where a player might have multiple roles and we want to find players with at least one of the selected roles.

The Overlap Operator for Advanced Array Filtering

But what about playstyles? Here's where I discovered something powerful - the overlap operator:

The .ov. operator checks if arrays overlap. This query finds players who have ANY of the selected playstyles in EITHER their regular or "plus" playstyle arrays. It's like asking "Does this player have Finesse Shot OR Long Shot in their regular abilities OR their upgraded abilities?"

This is player_details table from supabase, for your reference to understand that how playstyles and roles are stored for a player. Each row is one player.

Range Filters: The Edge Cases Matter

Rating filters seem simple but edge cases will bite you:

Why these edge cases? Users might slide both handles to the same value (wanting exactly 87-rated players). Or they might not touch the slider at all (1-99 range), in which case adding filters just slows things down.

1. When users haven’t touched range slider or when the start is 1 and end is 99, there is no need to apply filter as all players’ rating is in this range.

2. When start and end is equal, this means they want exactly same overall rating player, so here eq is correct filter.

3. When start and end is not same, we can use gte start and lte end on overall rating.

I would like you to watch this custom rating slider. I will be writing about it in future, so here is the glimpse. It can work as a range or a single value.

Video Tutorials

I have created a complete playlist of most important Supabase Filters. If you wish, you can watch them. All videos are < 5 minutes.

Subscribe Techie Blossom

The Critical Order of Operations

After applying all filters, the ordering strategy is crucial:

Why three order clauses? This creates deterministic sorting. Without it, players with the same rating appear in random order across pages, causing duplicates in pagination. The secondary and tertiary sorts ensure consistent ordering even when primary values match.

Pagination: The Silent Performance Killer

Notice the pagination calculation at the start:

The range() method expects inclusive bounds. Getting this wrong means missing the last item on each page. But more importantly, this approach uses offset-based pagination, which has a hidden cost - Postgres still processes all skipped rows. For page 100 with 30 items per page, it processes 3,000 rows to return 30.

This is OK for few pages but as pages increase, cursor based pagination would make more sense. I will be updating this article where I will be comparing the performance of offset based and cursor based.

Leave a comment

The Complete Pattern in Action

Let's trace through a real user scenario. A user wants to find:

• Brazilian players (nation filter)

• From Premier League or La Liga (league filter)

• Who are strikers (position filter)

• With 85+ overall rating (range filter)

• Having the "Advanced Forward++" role (role filter)

Here's how our code handles it:

1. Transform complex objects to simple IDs

2. Build the query incrementally

3. Apply each filter with the appropriate method

4. Apply sorting and pagination

Each filter method is chosen specifically for its use case. Single values use eq, multiple values use inFilter, array fields use contains and ranges use gte/lte.

Performance Insights from Production

After implementing this pattern, here's what I observed in production:

Complex queries with 8+ active filters return in under 200ms. The key factors:

• Using inFilter instead of OR chains reduced query time by 60%. More importantly they work as expected

• Proper compound indexes on commonly filtered columns (league, nation, position)

• The three-level ordering strategy eliminated pagination duplicates

• Caching the column list (_columnsToFetchForList) instead of using wildcard

The Lessons Learned

Building complex Supabase filters taught me several principles:

Start with PostgrestFilterBuilder - It gives you a mutable query object you can build incrementally. This is cleaner than trying to chain everything in one go.

Choose the right operator for each filter type - Use inFilter for multiple IDs, contains for array membership, ilike for text search and standard comparison operators for ranges.

Handle edge cases explicitly - Empty arrays, null values and full ranges all need special handling. Don't assume your filters will always have sensible values.

Order matters for pagination - Multiple order clauses ensure deterministic results across pages. Without this, users see duplicate or missing results.

Wrap in proper error handling - Database queries fail. Network requests timeout. Plan for it from the start with Result types or similar patterns.

Next time you're building complex filters in Supabase, remember: it's not about chaining methods, it's about building a query systematically. Start with PostgrestFilterBuilder, choose the right operators, handle edge cases and always plan for failure. Your future self at 2 AM will thank you.

If you haven’t read about how all this started, I would recommend to understand the key insights that I shared in the previous two posts about my learnings and journey to make it to production on both mobile platforms - Android and iOS with Flutter.

Tech Front

Inside Mono-Repo Flutter Architecture - FUT Maidaan

Most Flutter developers build their apps like a single giant house where everything lives under one roof. The kitchen connects directly to the bedroom, the bathroom shares pipes with the living room and when you need to fix the plumbing, you have to tear down half the structure. This approach worked fine when I was building small apps but when I started…

Read more

10 months ago · 1 like · Prateek Sharma

Tech Front

Building My Side Project for 8 Years: The FUT Maidaan Story

Most developers work on side projects for a few months before moving on to the next idea…

Read more

10 months ago · Prateek Sharma

If you are figuring out what is FUT Maidaan then discover yourself downloading the app.

iOS App

Android App

The Problem with Monolithic Flutter Apps

When you create a standard Flutter app, everything exists in a single package. Your API calls, UI components, business logic and feature screens all mingle together in the same lib folder. This creates several problems that become more apparent as your app grows.

Code generation becomes painfully slow. When you run build_runner on a large monolithic app, it has to process thousands of files even when you’ve only changed a small widget. This means longer coffee breaks and broken development flow.

Testing becomes a nightmare because everything depends on everything else. Want to test your player details screen? You’ll need to mock the entire app context, navigation system and API layer just to verify that a rating displays correctly.

Sharing code between projects becomes impossible. That beautiful design system you built? Or complex design-agnostic widgets that you built It’s so tightly coupled to your current app that extracting it for your next project would require major surgery.

Note: In FUT Maidaan app, initial build_runner executions were taking 2-3 minutes for simple model changes. This development friction was slowing down feature implementation significantly.

The Mono-Repo Solution

A mono-repo architecture solves these problems by breaking your app into small, focused packages that live in the same repository but operate independently. Think of it like building with Lego blocks instead of carving everything from a single piece of marble.

In FUT Maidaan app, I organized packages into four distinct categories that each serve a specific purpose. This organization isn’t arbitrary. It follows the dependency flow and ensures that lower-level packages never depend on higher-level ones.

Quality Packages: The Foundation

Quality packages form the foundation of the entire system:

• quality_analysis - Holds only the linter rules and every package depends on it, ensuring all packages follow the same lint rules

• quality_bdd_test - Provides Gherkin-style test cases and testing framework that feature and domain packages depend on

Utility Packages: App-Agnostic Services

Utility packages provide functionality that could work in any Flutter app:

• utility_navigation - Abstracts go_router or auto_route packages for consistent navigation across features

• utility_di - Configures dependency injection using get_it and injectable for almost all packages, creating a clean dependency graph

Core Packages: Shared Business Concerns

Core packages handle the fundamental business logic that multiple features need:

• core_api_client - Foundation for API connection via dio with custom interceptors, consistent error handling and token management

• core_design_system - Atomic design principles for modular and consistent app UI following reusable component patterns

• core_domain - Common data layer, domain layer and presentation layer consumed by multiple features, containing shared models, APIs and repositories. This package follows clean architecture.

Feature Packages: Self-Contained User Flows

Feature packages implement specific user journeys using clean architecture:

• feature_player - Follows clean architecture (data, domain, presentation) for onboarding, player lists and player details screens

• feature_filter - Manages search and filtering functionality with complex query building UI

• Additional features - Easy to spin up new features following the same patterns

And, here’s how the main pubspec.yaml looks like:

Subscribe now

How Dependencies Flow Through the System

The beauty of this architecture lies in how packages depend on each other. Dependencies always flow downward, creating a directed acyclic graph that prevents circular dependencies and makes the system predictable.

Don’t worry by looking at these many arrows. They are for your clarity. Let me walk you through how this dependency flow works in practice:

Feature packages sit at the top and can depend on any lower-level package. When the player feature needs to make an API call, it uses repositories from the domain package. When it needs to display a component, it imports from the design_system package. When it needs navigation, it calls the navigation package.

Core packages depend only on utility and quality packages. The domain package uses dependency injection from the utility layer and follows lint rules from the quality layer but it never imports anything from feature packages.

Utility packages depend only on quality packages. They provide foundational services but don’t know anything about your business logic or UI.

Quality packages depend on nothing except external libraries. They establish the rules and testing framework that everything else follows. If you later wish to have common test files in bdd_test package, as it won’t violate the rule of features depending on quality.

This dependency structure creates several powerful benefits:

• When you modify a low-level package, you immediately know which packages might be affected

• When you want to add a new feature, you can be confident it won’t break existing functionality if you follow the dependency rules

• Circular dependencies become impossible by design and even if you face such a challenge, you know the architecture is disturbed and you are moving in opposite direction of modular app.

• Code reuse becomes natural rather than forced

The Magic of Granular Code Generation

One of the most immediate benefits I noticed was the dramatic improvement in code generation speed. When I modify a single component in the design_system or add api in domain package, I run build_runner for only that package and it processes files in that package only. This typically takes 10-15 seconds instead of the 2-3 minutes required for a monolithic app.

This speed improvement compounds throughout development:

• You make changes more frequently because the feedback loop is faster

• You experiment more freely because you’re not waiting for long build processes

• You catch errors sooner because you can regenerate code after each small change

The improved speed comes from isolating the blast radius of changes. When you modify a model in the player feature package, only that package needs to regenerate its code. The filter package, domain package and design_system package remain untouched.

Real-world impact: What used to be a 3-minute wait for code generation after changing a single data model became a 15-second operation. Over a full development day, this saved hours of waiting time. You can always run build_runner in watch mode to never wait.

Clean Architecture Within Each Package

Each package in my mono-repo follows clean architecture principles but the implementation varies based on the package’s purpose. Feature packages implement the full data-domain-presentation layering, while utility packages focus on a single responsibility.

Feature Package Architecture

In feature packages like player and filter, the architecture follows these layers:

Presentation Layer contains BLoC state management classes that handle user interactions. These BLoCs communicate exclusively with use cases from the domain layer, never directly with repositories or data sources.

Domain Layer contains use cases, entities and repository interfaces. Use cases encapsulate business logic and coordinate between different repositories. For example, the GetPlayerDetails use case might calls both the PlayerRepository and PriceRepository to build a complete player profile.

Data Layer implements repository interfaces and manages data sources. Repositories coordinate between local storage using Drift and remote APIs through Supabase. They handle caching, error handling and data transformation transparently.

Shared Domain Architecture

The domain package follows a similar structure but contains only shared concerns. Its entities represent core business concepts like Player, Team and League that multiple features need. Its repositories handle data that doesn’t belong to a specific feature. For any feature specific API calls or business logic, the feature packages will have their own data-domain layers.

State Management That Scales

I chose flutter_bloc as the sole state management solution because it enforces clear boundaries between different parts of the system. Each BLoC handles a specific user flow and communicates through well-defined events and states.

The state management follows a strict communication pattern:

1. UI triggers events → BLoCs receive user interactions

2. BLoCs call use cases → Business logic coordination happens here

3. Use cases call repositories → Data fetching and manipulation

4. Repositories return data → Results flow back up the chain

To reduce the verbosity that BLoC is known for, I use the mappable package instead of freezed. Mappable generates immutable classes with less boilerplate and supports inheritance for data classes, which proves useful for complex state hierarchies. As I remember, new freezed version also does it, but I am preferring 1 generated file over 2.

The state management architecture scales beautifully as the app grows. Adding a new feature means creating new BLoCs and respective pages that follow the same patterns. These BLoCs can safely depend on existing use cases and repositories without risking conflicts.

API Architecture That Adapts

The api_client package demonstrates how mono-repo architecture handles cross-cutting concerns elegantly. All network communication flows through this single package but features remain decoupled from specific API implementations.

I use Retrofit with Dio to generate type-safe API clients. The api_client package provides a configured Dio instance with two custom interceptors that handle common concerns automatically:

• ApiKeyInterceptor - Attaches authentication tokens to every request, eliminating repetitive boilerplate in feature code

• ApiErrorInterceptor - Transforms network errors into domain-specific exceptions that the presentation layer can handle appropriately

This centralized approach proved invaluable when I had to switch data sources. The original API I was using stopped updating player data for several months, which would have been catastrophic for a football app during the most important part of the season.

Because my API logic was isolated in the api_client and domain packages, switching from the external API to Supabase took only two days. I modified the repository implementations in the domain package and updated the API client configuration. No feature code needed to change because the use cases and BLoCs continued working with the same interfaces.

Crisis Management: When your primary data source fails, having isolated API logic means the difference between a two-day fix and a complete rewrite. This architectural decision saved my app during a critical period. Before making shift to Supabase, I was calling API for fetching players and almost everything but last season that API vanished. When I switched to supabase, all I had to do was make supabase calls from repository layer instead of calling API.

Leave a comment

Dependency Injection That Just Works

Managing dependencies across multiple packages could become a nightmare without proper tooling. I use get_it with injectable to create a dependency graph that configures itself automatically.

Each package defines its own dependencies using injectable annotations:

When the app starts, all package dependency modules are registered with get_it in the correct order. This ensures that when a BLoC needs a use case and that use case needs a repository, everything is available without manual wiring.

The dependency injection setup follows the same hierarchical structure as the packages themselves:

1. Quality packages register first

2. Utility packages register second

3. Core packages register third

4. Feature packages register last

This order ensures that dependencies are always available when they’re needed. Injectable generates all the registration code, so adding a new dependency is as simple as adding an annotation.

Testing That Makes Sense

The package structure makes testing significantly more straightforward because each package has clear boundaries and minimal dependencies. You can test a use case by mocking only its direct dependencies, not the entire application context.

I use BDD-style tests with the bdd_widget_test package to create readable test scenarios:

Feature: Player Data Loading

  Scenario: Player data loads successfully
    Given I am on the player list page
    When the page loads
    Then I see text {'Lionel Messi'}
    And I see text {'93'}
    And I see text {'RW'}
    And I don't see text {'Loading...'}

  Scenario: Player data fails to load
    Given I am on the player list page
    And the network is unavailable
    When the page loads
    Then I see text {'Failed to load players'}
    And I don't see text {'Lionel Messi'}
    And I see widget {RetryButton}

  Scenario: Loading state is displayed
    Given I am on the player list page
    And the API response is delayed
    When the page loads
    Then I see text {'Loading...'}
    And I see widget {CircularProgressIndicator}
    And I don't see text {'Lionel Messi'}

These tests read like natural language specifications and can be understood by non-technical stakeholders. Appropriate _test.dart files are created on generation. More on this in future posts. The isolated nature of packages means you can run tests for individual packages without setting up the entire application.

When you need to test integration between packages, the dependency injection system makes it easy to replace real services with test doubles. You can test the complete user flow while still maintaining control over external dependencies.

The Development Experience

Working with this architecture feels fundamentally different from traditional Flutter development. Adding a new feature becomes a process of composing existing building blocks rather than weaving new functionality into an existing codebase.

When I decided to add player price tracking to FUT Maidaan, the process was remarkably clean:

1. Created a new API client in the domain package for price data

2. Added price-related use cases that coordinated with existing player data

3. Updated the player feature to display the new price information

4. The filter feature, design system and navigation packages remained completely untouched

I developed this solo, so this doesn’t apply to me. But for larger teams the modular structure also makes code review more focused. When someone reviews a pull request that adds filter functionality, they only need to understand the filter package and its immediate dependencies. They don’t need to comprehend the entire application to verify that the changes are correct.

Development speed improvements compound throughout the day:

• Code generation runs faster - Only affected packages rebuild

• Tests run faster - You can test individual packages in isolation

• Builds complete faster - Each package processes only what it needs

This speed improvement accumulates throughout the day, making development more enjoyable and productive.

Sharing Code Between Projects

This is an ambitious thought - One of the long-term benefits of mono-repo architecture is code reusability. The design_system package I built for FUT Maidaan contains many components that would work perfectly in other sports apps or any app that needs clean data visualization.

The utility packages are completely app-agnostic:

• The navigation abstraction could work with any routing solution

• Dependency injection configuration applies to any Flutter project

• Analysis rules establish consistent code quality standards

Even some core packages like api_client could be adapted for other projects with minimal changes. The HTTP interceptors, error handling and caching logic solve common problems that most apps face.

This reusability means that future projects can start with a solid foundation instead of building everything from scratch. You’re not just building an app; you’re building a toolkit for all your future apps.

Building Your Own Mono-Repo

If you’re convinced that mono-repo architecture could benefit your Flutter project, start small and grow incrementally. Begin by extracting your most reusable components into separate packages within your existing project structure.

Step-by-Step Migration Strategy

Create a design_system package first because it has minimal dependencies and immediate benefits. Keep it free from domain knowledge; think how material widgets are created. Move your reusable widgets, themes and style constants into this package and update your feature code to import from it.

Next, extract utility concerns like navigation and dependency injection. These packages will be used by multiple features and help establish the dependency flow patterns that make mono-repo architecture effective.

Gradually extract feature functionality into dedicated packages, ensuring that each package follows clean architecture principles and maintains clear boundaries with other packages.

Set up proper tooling using melos for mono-repo management, which allows you to run commands across all packages with 1 command and manage dependencies effectively.

The investment in setting up this architecture pays dividends quickly. You’ll notice faster development cycles, easier testing and more maintainable code within the first few weeks of adoption.

The mono-repo approach transformed how I think about Flutter development. Instead of building apps as monolithic structures, I now build them as collections of focused, reusable components that happen to work together to create a cohesive user experience. This shift in perspective makes complex projects manageable and sets the foundation for building better apps faster.

I have used this structure in over 4-5 apps now and it has never felt that I over-engineered for no reason or I made a mistake.

When you’re ready to scale beyond simple Flutter apps, mono-repo architecture provides the structure and discipline needed to manage complexity without sacrificing development speed. The initial investment in proper architecture pays off exponentially as your project grows and evolves.

If you haven’t read about how all this started, I would recommend to understand the key insights that I shared in this post about my learnings and journey to make it to production on both mobile platforms - Android and iOS with Flutter.

Tech Front

Building My Side Project for 8 Years: The FUT Maidaan Story

Most developers work on side projects for a few months before moving on to the next idea…

Read more

10 months ago · Prateek Sharma

I spent 8 years building the same side project (FUT Maidaan) while working my regular job.

Here’s why I stuck with one idea for so long and what it taught me about persistence, user experience, and building something from scratch.

The Problem That Wouldn’t Leave Me Alone

The story starts in 2016 when I was deep into FIFA Ultimate Team. Like millions of other players, I relied on third-party apps to check player stats, prices, and build my dream squad.

But every app I used frustrated me in the same ways.

The player cards were cluttered messes. Apps would show three different card styles - minimal, regular, and large - depending on screen space. But none of them displayed the information I actually needed clearly.

I wanted to see league, club, nation, position, name and rating at a glance. Instead, I got cramped layouts where critical details were barely visible.

BTW, Look at the ads. Just bloated through out the app.

The filters were even worse. These apps threw every possible filter at you, most of which no one ever used. Want to select a club after choosing a league? You’d have to navigate through the entire league selection again. Well, they are much improved in newer app but still user has to type in to the club name. Not a fast or intuitive way.

For example, I selected Premier League and I see all clubs to select from. Either I type in or scroll a long list of clubs.

The interface felt like it was designed by someone who had never actually played the game.

But the biggest problem wasn’t what these apps showed - it was what they didn’t show. No one was tracking market trends the way financial apps track stock indices. Players would rise and fall in value, but there was no way to understand the broader market movements across different positions.

I knew I could build something better. But knowing and doing are separated by years of work, false starts, and steady persistence.

Share

The Seven-Year Struggle

The first roadblock hit immediately. Player data wasn’t freely available.

EA Sports had APIs until FIFA 22, but they were limited and didn’t include prices - that is the most crucial information for any FUT player. I built prototype after prototype using Android native and Flutter, each one getting scrapped when I couldn’t access the data I needed.

For years, this cycle continued. I’d get excited about a new approach, a new workaround, spend weeks building, then abandon the project when I couldn’t access the data I needed.

I accumulated many unfinished projects, each teaching me something new but none reaching completion.

The breakthrough came in 2023-24 when I finally found an API that provided both player data and pricing. It had rate limits and wasn’t perfect but it was enough to get started again.

Seven years after starting, I could finally build the app I’d been imagining.

Rethinking Everything From Scratch

But having the data was just the beginning. Now I had to solve the design problems that had bothered me for so long.

I threw out the traditional FUT card approach entirely. Instead of cramming information into card layouts, I created clean list tiles that displayed all essential information clearly.

The card colors became subtle rating box backgrounds and borders, giving visual distinction without sacrificing readability.

For the player detail pages, I eliminated the redundant information that plagued other apps. Why show the same stats twice?

I designed each page like a product page, using the card’s color scheme as an intelligent theme throughout the interface. Players could understand what type of card they were viewing without seeing the actual card cluttering the screen.

The filter system got a complete rethink. I removed every filter I’d never used in seven years of playing FIFA. The remaining filters became contextual - select a league, and you’d only see clubs from that league.

No more navigating through irrelevant options.

Leave a comment

The Innovation That Solved a Real Gap

The feature I am most satisfied with was the index system.

Taking inspiration from stock market indices, I created separate indexes for forwards, midfielders, defenders, and goalkeepers. These indexes tracked market trends in each position, giving players insights no other app provided.

For the first time, you could see how the entire midfielder market was performing, not just individual players.

Building Solo: Every Hat, Every Decision

The technical architecture had to support 18,000+ players with complex filtering and real-time price updates. I chose Flutter for cross-platform development and Supabase for its unlimited read/write capabilities.

The mono-repo structure kept everything organized and maintainable.

My wife Preeti, who has a background in development and product management, collaborated with me on the design work. I drew the initial sketches and wireframes, but she developed the main color palette and created the logo entirely.

The logo was completely her vision - she took my rough concept of incorporating football elements and crafted the elegant F and M design where the F forms a player with a football. Her color choices ensured the app worked beautifully in both light and dark themes.

Building solo meant wearing every hat. I was the business analyst defining requirements, the product manager prioritizing features, the developer architecting the system, the designer crafting the interface, and the release engineer publishing to app stores.

iOS App

Android App

The Real Education

The development process taught me more about persistence than any corporate project had before. When you’re building something completely on your own, every decision carries weight.

There’s no product manager to blame for poor requirements, no designer to blame for confusing interfaces. The responsibility is entirely yours.

Firebase Test Labs caught performance issues on low-end devices. Apple’s review process flagged copyright concerns on the second release, forcing me to navigate complex intellectual property questions as a solo developer.

Google Play Store required multiple submissions to meet their quality standards.

Each obstacle required careful problem-solving because I was responsible for finding the solutions. This wasn’t a client project with external deadlines and budgets. This was seven years of evenings, weekends, and consistent belief that I could build something better.

Get more from Prateek Sharma in the Substack app

Available for iOS and Android

Get the app

Launch and Beyond

The app launched with player listings, detailed player pages, search functionality and my innovative filter system. The index feature worked exactly as I’d envisioned, updating daily through scheduled Supabase edge functions.

The clean interface finally solved the cluttered mess that had frustrated me for years.

But launching was just the beginning. The roadmap includes player comparisons, AI-powered search, pack opening simulations, squad building, and even gameplay between users.

Each feature represents months of additional work, but the foundation is solid enough to support ambitious expansion.

What Seven Years Taught Me

Working evenings and weekends for seven years while maintaining a full-time job required consistent dedication. I’d hit points where I didn’t want to touch the code but motivation always returned.

The idea stayed with me throughout.

This experience taught me something valuable about building products. Most developers create smaller apps or quick projects. But there’s something deeply rewarding about building something substantial entirely yourself.

Every line of code, every design decision, every feature prioritization reflects your vision without compromise.

The app hasn’t made me rich or famous yet. User acquisition is its own challenge, requiring skills I’m still developing. But that misses the point.

The real value was in the building itself.

Seven years of thinking about user experience made me a better designer. Architecting a complex Flutter application from scratch made me a better developer. Managing every aspect of product development made me understand how software truly gets built.

Building FUT Maidaan taught me that persistence often matters more than talent, that understanding user needs beats adding features, and that building something entirely your own provides a unique kind of satisfaction.

The app exists because I wasn’t willing to accept that cluttered, poorly designed software was good enough. Seven years later, that decision led to both a better product and valuable learning experiences.

Building something this complex solo required architectural decisions that would either make or break the entire project. The mono-repo structure I chose became the foundation that allowed me to iterate quickly, maintain clean separation of concerns, and scale from a simple prototype to a production app handling 18,000+ players.

How do you architect a Flutter app so it can grow from MVP to a feature-rich platform without collapsing under its own complexity? The answer lies in understanding how to structure packages, manage dependencies, and create boundaries that prevent your codebase from becoming an unmaintainable mess.

In Next Post, I’ll walk you through the exact mono-repo architecture that powered FUT Maidaan. You’ll see how I organized features, core utilities, and design systems into separate packages. More importantly, you’ll understand the thinking behind each decision and how this structure enabled me to add major features without rewriting existing code.

Whether you’re building your first serious Flutter project or refactoring an existing app that’s become difficult to maintain, this architecture pattern will change how you think about organizing your code.