DEV Community: Yadnesh Teli

Building a Flutter Shopping App from Scratch — Part 1: Scaffolding Models, Providers, and Screens

Yadnesh Teli — Tue, 06 Oct 2026 13:00:00 +0000

Series 1 of 2 — Part 1 of 5

Building a Flutter Shopping App from Scratch — Part 1: Scaffolding Models, Providers, and Screens

Series: Building a Flutter Shopping App — From Zero to Architecture

Every Flutter developer I know has at some point just started writing code without thinking too much about architecture. I was no different. When my internship mentor gave me a shopping app to build as a learning project, I opened VS Code and started typing.

This post covers what I built on day one — the models, providers, and screens — and why I made the choices I made, even if some of them turned out to be wrong.

The project brief

A standard e-commerce shopping app. Products, categories, a cart, a favourites list, and user authentication. Nothing groundbreaking, but enough to force you to think about state, data flow, and UI structure.

At this point in my Flutter journey I had a basic understanding of widgets and StatefulWidgets. I had read about Provider but not really used it properly. I did not know what MVVM was.

Starting with models

The first thing I did was define my data structures. A product has a name, price, image URL, and category. A category is just an id and a label.

class ProductModel {
  final String id;
  final String name;
  final double price;
  final String imageUrl;
  final String categoryId;

  ProductModel({
    required this.id,
    required this.name,
    required this.price,
    required this.imageUrl,
    required this.categoryId,
  });
}

Clean enough to start with. At this stage I was not thinking about fromJson or toJson — that would come back to bite me later when I integrated Firestore.

Building the providers

I used Riverpod for state management. I created providers for products, categories, cart, favourites, and search. Each was a StateNotifier that held a list and exposed methods to add, remove, and filter items.

The cart provider looked reasonable at first. But there was a problem I did not see yet — it had no concept of the current user. The cart data was global. If two users logged in on the same device, they would share the same cart. This is the kind of issue you only discover when you try to add authentication.

Setting up screens

I built three screens: HomeScreen, CartScreen, and FavouritesScreen. The HomeScreen had a product grid, category filters, and a search bar with debounce. The CartScreen showed cart items with quantities. The FavouritesScreen was a responsive grid of saved products.

I also added Device Preview at this stage, which turned out to be a good decision. It caught several responsive layout bugs early without needing to switch simulators.

What I got right

Using Riverpod from the start: Even my naive providers were easier to manage than raw setState.
Separating models early: Gave me a consistent data layer before I understood the full architecture.
Adding Device Preview early: Surfaced layout bugs while they were still cheap to fix.

What I got wrong

Global user state: Cart and favourites providers had no concept of the current user — state was global.
Leaking business logic: Business logic was leaking into the UI layer — screens called provider methods with too much knowledge of storage internals.
Tangled data sources: No repositories. API calls, local storage reads, and state updates were all tangled inside the same providers.

What is coming next

In Part 2 I add authentication — Firebase login, signup, Google Sign-In, and the surprisingly tricky problem of merging accounts when a user signs up with email and then tries to log in with Google using the same address.

Next: Part 2 — Adding Firebase Auth, Google Sign-In, and Account Merging

My Flutter Internship Learning Journey: Two Projects, One Progression

Yadnesh Teli — Mon, 05 Oct 2026 13:03:33 +0000

Intro Post

My Flutter Internship Learning Journey: Two Projects, One Progression

A Dev.to blog series about learning Flutter the hard way — and then the right way.

I am an MCA student based in Mumbai, currently doing a Flutter developer internship. Over the past few weeks I built two Flutter apps as part of my learning journey. On the surface they look similar — both are Flutter apps, both deal with real features, both use Riverpod. But the way I approached them could not have been more different.

The first project, a shopping app, started with zero knowledge of proper Flutter architecture. I just started building — models, providers, screens — figuring things out as I went. Halfway through, I realised the codebase was becoming hard to manage. So I stopped and refactored the entire thing to MVVM with repositories and viewmodels. It was painful but I learned more from that refactor than from anything else.

The second project, DevFeed — a Hacker News reader — is where I applied everything I had just learned. I set up MVVM from the first commit. I never had to do a big painful refactor because the architecture was right from day one. It shipped to v1.0.1 with a changelog and a GitHub Actions release workflow.

These two projects together tell a story I think a lot of Flutter beginners will relate to. So I am writing about both, as two parallel series.

What the two series cover

Series 1 — Building a Flutter Shopping App: From Zero to Architecture

This follows the shopping app from scratch. You will see me build it the naive way, hit the walls, and then migrate to proper MVVM. If you have ever written Flutter code that became a mess and wondered how to fix it, this series is for you.

Series 2 — Building DevFeed: A Proper Flutter MVVM App from Day One

This follows DevFeed from the first commit. No big refactor needed — because the architecture was planned upfront. This series shows what it looks like when you apply the lessons from Series 1 before you start writing features.

Beyond the Basics: Deep Dives & State Management Alternatives

Following both projects, I also explore alternative paradigms that broadened my engineering toolkit: GetX, Flutter BLoC, Supabase as a Firebase alternative, implicit & explicit animations, and GraphQL.

Who this is for

Flutter beginners who are learning by building real projects
Students doing internships who want to write production-quality code
Anyone who has built a messy Flutter app and wants to understand MVVM
Anyone curious about what a real learning-in-public journey looks like

The tech stack

Flutter & Dart
Riverpod for state management
Firebase Auth, Firestore, FCM
MVVM architecture with repositories and viewmodels
GitHub Actions for CI/CD automation

How to follow along

I will post both series in parallel, alternating weekly. Start with Series 1 Part 1 and Series 2 Part 1 simultaneously — they set up the contrast that makes the whole journey make sense.

Let us get into it.

DartBox Buddy: Running Flutter On-Device with a Local Gemma 4 AI Tutor for My Friend

Yadnesh Teli — Mon, 05 Oct 2026 04:32:27 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

A close friend of mine has wanted to learn Flutter for months. They had great app ideas—little personal tools, habit logs, and clean interfaces—but every time they sat down to start, reality hit them like a wall:

The Setup Monster: First came downloading gigabytes of Android Studio, fighting Gradle daemon memory errors, configuring Java home variables, and waiting 10 minutes for an initial build. By the time the emulator booted, their creative momentum was completely gone.
The Layout Maze: When they finally got code running, Flutter layouts proved deceptively tricky. Misunderstanding Row vs Column constraints, getting mysterious black-and-yellow striped overflow errors, and not knowing why an element vanished caused endless frustration.
The Closed AI Trap: They tried pasting questions into cloud AI assistants, but web playgrounds only produced browser mockups, closed APIs demanded $20/month subscriptions, and personal daily habit ideas were being shipped to third-party corporate servers.

I realized what my friend needed wasn't another thick tutorial or a heavy laptop IDE. They needed a playful sandbox right in their pocket: an app where they could experiment with layouts on the subway, see changes instantly on a real touch screen, and have a patient, private mentor guiding them through every mistake.

DartBox Buddy is an on-device Flutter development studio and AI tutor that runs entirely on a mobile phone.

With DartBox Buddy, you can open any .dart file on your phone, tap Run, and watch it compile and mount as an interactive, live native Flutter widget in under 100 milliseconds—with zero project setup, no laptop, no command-line tools, and no internet connection required.

Sitting beside you in the editor is an on-device AI mentor powered by Google Gemma 4 E2B running via LiteRT-LM. When a layout breaks or a compiler error occurs, Gemma analyzes the AST on your phone, explains the visual hierarchy in plain English, and auto-repairs code before mounting it on screen.

To solve my friend's layout struggles from day one, DartBox bundles 6 Progressive Layout Lessons:

Centering & Text: Center, Container, padding, and decoration basics.
Padding & Margins: Visualizing inner space vs outer margin boundaries.
Row & Column Alignment: Mastering mainAxisAlignment and crossAxisAlignment.
Stack & Positioned: Layering badges, floating tags, and overlapping cards.
Scrollable Card Feed: Constructing lists with ListView, Card, and ListTile.
Interactive State: Connecting taps to layout updates using StatefulWidget and setState.

Bundled lessons are read-only templates: editing any lesson automatically forks a custom copy into "My Scripts" so original reference lessons are never overwritten.

Demo

User Workflow

┌────────────────────────────────────────────────────────┐
│  DartBox Buddy Studio (On-Device Mobile Engine)        │
│                                                        │
│  [Code Editor] ──(Compiles in <100ms)──> [Live Widget] │
│        ▲                                       │       │
│        │                                       ▼       │
│   Auto-Repair <── [On-Device Gemma 4] <── [Errors/AST] │
└────────────────────────────────────────────────────────┘

My Friend's Reaction

When I handed the phone to my friend and opened Lesson 3 (Row & Column Alignment), their first question was:

"Wait, where's the laptop? How is this running without Android Studio open?"

Within five minutes, they had changed the button padding, flipped the alignment from spaceEvenly to spaceBetween, and used the Gemma AI Tutor to ask why their text wasn't centered. For the first time, learning Flutter felt as fast and playful as playing a mobile game.

Code

📂 GitHub Repository: https://github.com/yadneshteli/dartbox
📜 License: MIT
🤖 AI Model Used: Google Gemma 4 E2B LiteRT-LM (Open-weight, Apache-2.0)
📦 Built With: Flutter, flutter_eval, flutter_gemma, LiteRT

# Clone and run locally
git clone https://github.com/yadneshteli/dartbox.git
cd dartbox
flutter pub get
flutter run

How I Built It

DartBox Buddy connects two cutting-edge open technologies:

1. The On-Device Flutter Runtime (`flutter_eval` + `dart_eval`)

The host app runs standard Flutter compiled for Android. When the user edits code, DartBox passes the source string to the on-device Compiler with flutterEvalPlugin, producing platform-agnostic EVC bytecode in memory. The RuntimeWidget mounts the bytecode as a live widget tree with interactive touch gestures and state management (setState).

To ensure my friend wasn't restricted to basic containers, we bridged essential Flutter layout and styling primitives into the dynamic runtime:

Layout: Flexible, Wrap, SingleChildScrollView for scrollable, wrapping feeds.
Styling: BoxDecoration, BorderRadius, BoxShadow, and LinearGradient for sleek card designs.
Controls & Inputs: NavigationBar, Checkbox, Switch, and OutlineInputBorder for interactive components.

2. The On-Device AI Engine (`flutter_gemma` + LiteRT-LM)

Inference runs locally using the flutter_gemma package backed by LiteRT-LM. We deploy gemma-4-E2B-it.litertlm (an Apache-2.0 open-weight model from the LiteRT community).

flowchart TD
    A["Friend edits layout in Editor"] --> B["CompatChecker (Allowlist & Linter)"]
    B --> C["dart_eval Compiler"]
    C -->|Success in <100ms| D["Live Interactive Widget"]
    C -->|Compile Error| E["On-Device Error Console"]

    E --> F["Gemma 4 E2B Tutor (On-Device via LiteRT)"]
    F -->|System Prompts + Widget Hierarchy| G["Explain Error / Layout Hint"]
    G --> H["Self-Healing Repair Loop"]
    H -->|Repaired Code| C

3. Mobile Ergonomics & Developer Experience

Writing code on a touch keyboard requires deliberate tooling:

One-Tap Symbol Bar: Instant access to {, }, (, ), ;, :, =>, quotes, and brackets without toggling keyboard layers.
Undo & Redo: Directly integrated UndoHistoryController on the mobile toolbar.
Debounced Auto-Save & Safe Navigation: Code automatically saves after 1.5s of inactivity and via PopScope on back navigation.
Error-to-Line Navigation: Tapping any compiler error in the on-device console automatically jumps the cursor to the exact error line.
Script Management: Local duplicate, rename, delete with confirmation, and clipboard code paste/import.

4. Benchmarks & Verification

Tested on a OnePlus 13R (Qualcomm Snapdragon 8 Gen 3, 16 GB RAM):

Bytecode Compilation Time: 85 ms (average for 150-line layout scripts)
Warm Recompile Time: < 15 ms (using in-memory AST cache)
Automated Test Suite: 16 passed tests (100% pass rate across compiler units, all 6 bundled layout lessons, bridge widgets, and the multi-turn Gemma auto-repair loop)
Analyzer Health: 0 errors, 0 warnings with flutter analyze
Packaging: Standalone debug APK verified and built cleanly in 68s.

Why Does Open Innovation Matter?

This project was built to prove why open-source AI is transformative for learning and mobile development:

100% Offline Independence: Learning shouldn't stop when you lose Wi-Fi. By packaging Google's open-weight Gemma 4 E2B model (.litertlm) directly onto the device, the tutor runs in airplane mode, on trains, or in remote spots with zero network latency.
Complete Data Sovereignty & Privacy: The friend's personal thoughts, draft widgets, and habit data never leave the phone. There is no tracking, no logging, and no telemetry sent to a remote API.
Zero Ongoing Costs: Cloud LLMs impose steep per-token pricing or monthly subscriptions. Open-weight models democratize access—once installed, millions of tokens of guidance cost exactly $0.00.
Deterministic Closed-Loop Compilation: Unlike generic cloud chatbots that hallucinate outdated syntax, DartBox pairs Gemma with an on-device compiler (dart_eval / flutter_eval). When Gemma suggests or generates a layout, DartBox compiles it in memory. If a syntax mismatch is detected, it feeds the error back to Gemma for an instant self-healing repair turn before the user even sees it.

My Agent Session

We saved the AI agent session transcript from our architectural build and test verification using DevRelay:

Building DartBox Buddy with On-Device Gemma 4

You

Build DartBox Buddy: an on-device Flutter runner and local Google Gemma 4 AI tutor for my friend learning Flutter layouts without laptop setup.

Agent

Designing 100% offline architecture: local bytecode compilation via flutter_eval, on-device Gemma 4 E2B inference via LiteRT-LM, debounced auto-save, and self-healing auto-repair loop.

▸ run_command flutter test

Input

$ flutter test

Output

All 16 tests passed cleanly! Bytecode compilation, bundled lessons, and Gemma repair loop verified.

Direct Transcript Link: DevRelay Agent Session #543

The agent session covers designing the 100% offline runtime architecture, extending flutter_eval with layout bridges, implementing the 3-turn Gemma auto-repair loop, and passing all 16 automated tests.

Prize Categories

Featured Category: Best Use of Gemma ($200)

DartBox Buddy enters the Best Use of Gemma category. The project features Google's open-weight Gemma 4 E2B model (gemma-4-E2B-it.litertlm, Apache-2.0) running natively on-device via LiteRT-LM.

Gemma serves as an on-device tutor and autonomous code repair engine:

Visual Hierarchy Explanation: Deconstructs Flutter widget trees and explains layout rules in plain English without cloud latency.
Self-Healing Auto-Repair: Automatically catches compiler errors, feeds AST error diagnostics into an on-device 3-turn repair loop, and outputs corrected code that compiles and mounts live.
Local Privacy: Ensures all user code, draft widgets, and learning conversations remain 100% local on the device.

Thank you to DEV, Google, and the Hacktoberfest organizers for this challenge!

DEV Community: Yadnesh Teli

Building a Flutter Shopping App from Scratch — Part 1: Scaffolding Models, Providers, and Screens

Building a Flutter Shopping App from Scratch — Part 1: Scaffolding Models, Providers, and Screens

The project brief

Starting with models

Building the providers

Setting up screens

What I got right

What I got wrong

What is coming next

My Flutter Internship Learning Journey: Two Projects, One Progression

My Flutter Internship Learning Journey: Two Projects, One Progression

What the two series cover

Who this is for

The tech stack

How to follow along

DartBox Buddy: Running Flutter On-Device with a Local Gemma 4 AI Tutor for My Friend

What I Built

Demo

User Workflow

My Friend's Reaction

Code

How I Built It

1. The On-Device Flutter Runtime (flutter_eval + dart_eval)

2. The On-Device AI Engine (flutter_gemma + LiteRT-LM)

3. Mobile Ergonomics & Developer Experience

4. Benchmarks & Verification

Why Does Open Innovation Matter?

My Agent Session

Prize Categories

Featured Category: Best Use of Gemma ($200)

1. The On-Device Flutter Runtime (`flutter_eval` + `dart_eval`)

2. The On-Device AI Engine (`flutter_gemma` + LiteRT-LM)