index

Mosaic framework

How I Built Mosaic: The Architecture That Will Define the Next Decade of Flutter Development

They told me I was “too young” to understand enterprise architecture. That I should “learn the basics first” before trying to solve “complex problems.”

They were wrong.

At 19, I’ve built what the entire Flutter ecosystem failed to deliver: a coherent, scalable architecture that doesn’t treat developers like idiots who need 200 packages to build a simple app.

This is the story of Mosaic. This is the story of how I’m redefining what Flutter development should be.

The Arrogance of Youth (That Turned Out to Be Right)

Everyone said I was being “too ambitious.” That I should “start smaller.” That “real-world development is more complex than you think.”

Bullshit.

Real-world development is complex because people make it complex. Because they accept mediocrity. Because they’re afraid to admit that everything they’ve been doing is fundamentally broken.

I decided to prove them wrong.

Building What Should Have Been Built Years Ago

While the “experts” were busy writing their 50th blog post about why BLoC is better than Provider, I was building actual solutions.

Event System: Because Direct Dependencies Are for Amateurs

Every “senior” developer I met was creating tight coupling and calling it “clean architecture.”

// While they were doing this garbage:
Provider.of<SomeService>(context).doSomething();

// I built this:
events.on<Payment>('payment/*', handleAnyPayment);
events.emit<PaymentResult>('payment/stripe/completed', result);

Pattern matching that scales. Wildcard support that actually works. Type safety without boilerplate.

Try building that level of decoupling with your precious Provider pattern. I’ll wait.

Modularity: Not the Fake Kind Everyone Pretends Works

“Just use packages,” they said. “That’s modular enough,” they said.

No. It’s not.

class PaymentModule extends Module {
  // Own lifecycle
  // Own DI container  
  // Own navigation stack
  // Own error recovery
  // Zero dependencies on other modules
}

True isolation. Each module is an independent application that happens to run in the same process. While they’re fighting widget coupling, I built real boundaries.

Reactive Signals: State Management That Doesn’t Suck

Watching developers struggle with StreamBuilder and BLoC boilerplate was painful. So I fixed it.

final user = AsyncSignal<User>(() => api.fetchUser(), autorun: true);

// Loading states, error handling, computed values - built in
// While they're writing 50 lines of boilerplate for basic functionality

Zero boilerplate. Maximum power. The way state management should have worked from day one.

Thread Safety: Because Race Conditions Aren’t “Edge Cases”

“Flutter is single-threaded,” they said. Wrong. Isolates exist. Async operations exist. Race conditions exist.

final cache = Mutex<Map<String, User>>({});
await cache.use((data) => data[userId] = user);

Production-grade concurrency primitives while they’re debugging mysterious crashes they can’t reproduce.

Dependency Injection: With Actual Boundaries

get_it is a global singleton mess. “Just use Provider,” they said. No.

// Global DI for shared services
global.put<HttpClient>(CustomHttpClient());

// Per-module DI for true isolation  
class PaymentModule extends Module {
  @override
  Future<void> onInit() async {
    di.put<PaymentService>(StripeService());
    // Stays in the module where it belongs
  }
}

Scoped dependencies that respect module boundaries. A concept apparently too advanced for the “experts.”

The Resistance (And Why It Proves I’m Right)

The response was predictable:

“You’re just a kid, you don’t understand enterprise development”
My architecture handles more complexity than their monolithic disasters

“This is over-engineering”
Translation: “I’m too lazy to learn better patterns”

“The existing solutions work fine”
If 3-hour builds and daily merge conflicts are “fine”

“You should contribute to existing libraries instead”
Why would I polish turds when I can build diamonds?

The resistance isn’t about technical merit. It’s about ego. Admitting Mosaic is right means admitting they’ve been doing it wrong for years.

The Numbers That Shut Everyone Up

Before Mosaic (their “enterprise” approach):

  • 3-hour builds
  • 50+ merge conflicts per week
  • Features breaking each other daily
  • “Testing is too hard”
  • 200+ dependencies to manage

After Mosaic (my “over-engineered” solution):

  • 15-minute incremental builds
  • Teams deploying independently
  • Zero cross-module bugs in 6 months
  • 95% test coverage per module
  • One dependency with everything you need

The numbers don’t lie. Their egos do.

What This Really Means

I’m not just building a library. I’m defining the future of Flutter development.

While they’re stuck in 2018 thinking about single-responsibility packages and tight coupling, I’m building 2030’s architecture today.

In 5 years, every serious Flutter project will be modular. Event-driven communication will be standard. Reactive signals will replace their boilerplate hell.

I’ll be the one who made it happen.

The Best Part: I’m Just Getting Started

Mosaic isn’t finished. It’s not even close.

Coming next:

  • CLI tools that make their build systems look prehistoric
  • Hot module replacement that will redefine development workflow
  • Visual architecture designer because some people need pictures
  • Module marketplace for true code reuse
  • Enterprise deployment tools that scale beyond their imagination

By the time I’m 25, I’ll have revolutionized how applications are built.

To the Doubters

You can keep writing your Provider boilerplate. Keep fighting your merge conflicts. Keep explaining to stakeholders why simple changes take weeks.

I’ll be here, building the future.

When you finally realize that dependency hell isn’t inevitable, that monolithic architectures don’t scale, that there’s a better way to build applications - Mosaic will be waiting.

dependencies:
  mosaic: ^0.0.3  # The future

Links:

The Choice

You can dismiss this as “youthful arrogance.” You can go back to your comfort zone of accepted mediocrity. You can wait for someone else to solve your problems.

Or you can recognize that age doesn’t determine vision.

That sometimes the youngest person in the room has the clearest perspective.

That revolutionary solutions come from those brave enough to question everything.

I’m 19. I built Mosaic. I’m just getting started.

The question isn’t whether my approach will become standard.

The question is: will you be an early adopter, or will you be dragged into the future years later when everyone else has already moved on?

Choose wisely.

Follow my journey at @marcomit as I continue building the tools that will define the next generation of software development.