DEV Community: Bhanu Nagpure

I Didn't Stress Test My Native Ads. My App Paid the Price.

Bhanu Nagpure — Wed, 01 Apr 2026 11:30:59 +0000

I launched PyMaster — a gamified Python learning app and everything looked fine — until my AdMob match rate dropped to 0.5%.
Here’s the mistake that caused it (and how to avoid it).

A few months in, I shipped an update I was proud of. Within days, my AdMob dashboard was showing something I didn't expect: ~2,000 requests. ~10 impressions.

That wasn't a bad ad day. That was a self-inflicted wound.

Here's what I got wrong, what it cost me, and the smarter path I found on the other side.

The Setup: Native Ads in a Scrollable List

My home screen is a vertical list — chapters, zones, locked content. Classic stuff.

I slotted a native ad tile into the list. It worked beautifully in testing. Loaded, rendered, sat quietly between content.

So I got ambitious. I added logic to retry loading if an ad failed — because why waste a slot? If AdMob couldn't fill it, at least try again, right?

The implementation looked like this:

// native_ad_tile.dart (simplified)
class NativeAdTile extends StatefulWidget {
  @override
  State<NativeAdTile> createState() => _NativeAdTileState();
}

class _NativeAdTileState extends State<NativeAdTile> {
  NativeAd? _nativeAd;
  bool _isLoaded = false;
  bool _adFailed = false;

  @override
  void didChangeDependencies() {
    super.didChangeDependencies();
    // Retry logic: reload if not yet failed
    if (_nativeAd == null && !_adFailed) {
      _loadAd();
    }
  }

  void _loadAd() {
    _nativeAd = NativeAd(
      adUnitId: 'your-ad-unit-id',
      listener: NativeAdListener(
        onAdLoaded: (ad) => setState(() => _isLoaded = true),
        onAdFailedToLoad: (ad, error) {
          ad.dispose();
          setState(() => _adFailed = true); // ← This was missing initially
        },
      ),
    )..load();
  }

  @override
  Widget build(BuildContext context) {
    if (_adFailed) return const SizedBox.shrink();
    if (!_isLoaded) return _buildSkeleton();
    return AdWidget(ad: _nativeAd!);
  }
}

Clean. Defensive. I was proud of it.

Then I shipped the update and forgot to ask one question:

What happens when AdMob has zero ads to serve?

Zero-fill regions broke my ad logic.

AdMob fill rates are not uniform across regions. In some markets — including places like Burkina Faso — native ad inventory can be extremely limited or even unavailable. In those cases, AdMob will accept the request but return a no-fill error.

My retry logic didn’t account for that. It assumed an ad would eventually load — so it kept trying.

Every scroll. Every didChangeDependencies call. Every widget rebuild.

The list had multiple ad slots. Each one repeatedly requesting ads.

The result?

~2,000 ad requests. ~10 impressions.

That’s a 0.5% fill rate.

This kind of request-to-impression imbalance can negatively impact performance signals like match rate and eCPM over time. When your app generates many requests but very few impressions, it may indicate inefficient ad loading or poor integration patterns.

The effect compounds quietly in the background — while everything looks fine on the surface.

The Lesson: Think in Request/Impression Ratio

When you're building ad integrations, the metric that matters most isn't revenue per impression.

It's request/impression ratio.

A ratio far above 1.0 is a red flag. It tells AdMob's systems that your integration is spammy, unreliable, or poorly targeted. This can reduce the chances of receiving high-value ads. Your eCPM drops. Your fill rate drops further. It compounds.

The golden rule for ad requests:

Make one request per ad slot per session
If it fails → mark it as failed, collapse the space, and move on
Do not retry indefinitely on failure
Do not reload on every widget lifecycle event

// ✅ The defensive pattern
onAdFailedToLoad: (ad, error) {
  ad.dispose();
  if (mounted) {
    setState(() {
      _adFailed = true;  // Mark permanently failed
      _isLoaded = false;
    });
  }
  // No retry. No loop. Just fail gracefully.
},

// ✅ Collapse space on failure — don't show an empty box
@override
Widget build(BuildContext context) {
  if (_adFailed) return const SizedBox.shrink(); // Zero height. Zero cost.
  // ...
}

Best Practices for Native Ads in Flutter (The Hard-Won List)

1. Always use test IDs in debug mode

if (kDebugMode) {
  adUnitId = Platform.isAndroid
    ? 'ca-app-pub-3940256099942544/2247696110'
    : 'ca-app-pub-3940256099942544/3986624511';
}

Never test with production IDs. Never.

2. Gate production loading strictly

// If the production ID is missing, do nothing.
if (adUnitId == null || adUnitId.isEmpty) {
  setState(() => _adFailed = true);
  return;
}

An empty ad is better than a test ad in production. An empty ad is better than a crash.

3. Use AutomaticKeepAliveClientMixin to prevent reload storms

In a scrollable list, widgets get disposed and recreated as you scroll. Without keep-alive, every scroll past an ad tile triggers a new ad request.

class _NativeAdTileState extends State<NativeAdTile>
    with AutomaticKeepAliveClientMixin {

  @override
  bool get wantKeepAlive => true;

  @override
  Widget build(BuildContext context) {
    super.build(context); // Required
    // ...
  }
}

4. Load the ad once — whether you use initState or didChangeDependencies, just make sure it’s properly guarded so you don’t trigger multiple requests.

@override
void didChangeDependencies() {
  super.didChangeDependencies();
  if (_nativeAd == null && !_adFailed) {
    _loadAd(); // The guard prevents double-loading
  }
}

5. Always dispose

@override
void dispose() {
  _nativeAd?.dispose();
  super.dispose();
}

Miss this once and you'll have memory leaks and phantom requests running in the background.

I Pulled the Plug. And It Felt Good.

After diagnosing the damage, I made the call: remove native ads entirely.

Within 24 hours of shipping that update:

Request count dropped to near zero
The relief was immediate and visible in the dashboard
My match rate started recovering

Native ads in a scrollable list with unknown regional fill rates were doing more harm than good.

What I Replaced Them With

Here's the clever bit.

Instead of an ad tile, I now have an in-house promotional tile.

Same slot. Same height. Same visual weight in the list.

But it promotes PyMaster Pro — my own upgrade.

// No AdMob. No fill rate. No requests. Just yours.
class ProUpgradeTile extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Container(
      height: 90,
      decoration: BoxDecoration(
        gradient: LinearGradient(colors: [Colors.amber, Colors.orange]),
        borderRadius: BorderRadius.circular(16),
      ),
      child: Row(
        children: [
          Icon(Icons.star, color: Colors.white),
          Text("Go Pro — Unlock All Chapters"),
          TextButton(onPressed: () => _openPaywall(), child: Text("Upgrade")),
        ],
      ),
    );
  }
}

The slot that was burning my request ratio and damaging rankings is now a direct conversion surface.

100% fill rate. 0 AdMob requests. You own the real estate.

The TL;DR

What I Did Wrong	What to Do Instead
Retried ad load on every rebuild	Mark failed, collapse, move on
No regional fill-rate awareness	Assume zero fill is possible anywhere
Native ads in a high-scroll list	Use `AutomaticKeepAliveClientMixin`
Measured success by impressions	Measure request/impression ratio
Kept native ads when they hurt	Know when to cut your losses

Final Thought

Stress testing ad integrations isn't just about "does the ad show."

It's about how your app behaves when it doesn’t.

Simulate real failure conditions — poor connectivity, no-fill responses — and watch what your UI actually does.

The bugs that hurt aren’t the visible ones. They’re the silent loops in the background, draining performance while everything looks fine on the surface.

Code defensively. Watch your ratios.
And design for failure — not just success.

I’m Bhanu, solo founder at Devanshu Studio, building PyMaster — a gamified Python learning app for mobile.

If you're learning Python on mobile, it's built for you → Check it out on the Play Store

Tags: flutter admob mobile indie-dev showdev android monetization

Why I Stopped Building Apps and Started Building an Engine in Flutter

Bhanu Nagpure — Thu, 12 Mar 2026 12:46:49 +0000

As an indie developer, your biggest bottleneck isn’t skill — it’s time. And maintaining multiple apps will absolutely destroy it.

A few months ago, I started building PyMaster, a gamified app to help people learn Python on their phones. But the moment I shipped the first version, I didn’t feel done. I wanted to teach SQL next. Then JavaScript. Maybe even Rust.

That’s when I realized I had a problem.

The Copy-Paste Trap

The obvious move was to duplicate the PyMaster codebase, swap the logos, change the content, and publish a new app.

Simple, right?

I actually tried it. I cloned the repo, renamed a few things, and within ten minutes I already hated what I was looking at.

Three separate codebases
Three separate sets of bugs
Three separate times I’d have to push a fix every time I touched the streak logic

As a solo founder, that’s not a roadmap — that’s a slow death.

So I scrapped it and spent a weekend thinking differently.

Instead of building another app, I’d build an engine — one codebase that could compile into an infinite number of apps.

A white-label educational platform, powered by Flutter + Riverpod.

Here’s exactly how I architected it.

The Core Concept: Inversion of Control

In a normal app, your UI knows too much.

It’s got hardcoded strings like:

Text("Welcome to Python")

It also has tightly coupled parsers that only understand Python syntax.

The UI is opinionated, and that opinion is baked in deep.

To white-label this, I needed the UI to become completely dumb.

It shouldn’t know what it’s teaching — only how to render what it’s given.

I achieved this by creating a master interface called CourseBlueprint.

// The master contract every app flavor must fulfill
abstract class CourseBlueprint {
  String get appTitle;
  String get virtualCurrencyName;

  // Theme Engine
  Color get brandPrimaryColor;
  Color get brandSecondaryColor;

  // Logic Injection
  CodeParserStrategy get codeParser;

  // Per-app 3rd Party Config
  String get analyticsId;
  String get aiSystemPrompt;
}

This interface is the backbone of the entire system.

Every flavor of the app — Python, SQL, JavaScript — must implement it.

The UI never imports a PythonCodeParser directly.

It just asks for a parser, and the configuration provides one.

Creating the “Flavors”

With the blueprint in place, spinning up a new app takes hours, not weeks.

Here’s what the Python flavor looks like:

// Python-specific implementation
class PythonCourseConfig implements CourseBlueprint {
  @override
  String get appTitle => "PyMaster";

  @override
  String get virtualCurrencyName => "Tokens";

  @override
  Color get brandPrimaryColor => const Color(0xFFFFD43B); // Python Yellow

  @override
  CodeParserStrategy get codeParser => PythonCodeParser(); // Handles indentation

  @override
  String get aiSystemPrompt =>
      "You are an expert Python tutor. Explain the error in simple terms.";
}

If I want to launch a SQL app tomorrow, I simply:

Create SqlCourseConfig
Change the theme color
Inject a SqlKeywordParser
Update the AI prompt

That’s genuinely it.

The real win here isn’t technical elegance.

It’s where my time goes.

Instead of wrestling infrastructure, I spend almost all my effort on the content inside the app.

Tying It Together with a Factory

How does the app know which configuration to load?

I use Flutter’s --dart-define flag during compilation.

A simple factory reads the flavor and returns the right config.

class BlueprintFactory {
  static CourseBlueprint getForFlavor(String flavor) {
    switch (flavor.toLowerCase()) {
      case 'python':
        return PythonCourseConfig();

      case 'sql':
        return SqlCourseConfig();

      default:
        return PythonCourseConfig(); // Safe fallback
    }
  }
}

I’ll be honest.

The first time I wired this up, I spent nearly two hours debugging why my SQL flavor kept rendering in Python Yellow.

Turns out I forgot to pass the build flag.

--dart-define=APP_FLAVOR=sql

So it silently fell back to the default.

Infuriating in the moment.

Obvious in hindsight. Classic.

Injecting Config into the UI with Riverpod

The last piece was making the configuration globally accessible.

Without prop-drilling it through every widget.

This is where Riverpod shines.

// Global provider — overridden at startup
final blueprintProvider = Provider<CourseBlueprint>((ref) {
  throw UnimplementedError("Must be overridden in main.dart");
});

void main() {
  const flavor =
      String.fromEnvironment('APP_FLAVOR', defaultValue: 'python');

  final selectedConfig = BlueprintFactory.getForFlavor(flavor);

  runApp(
    ProviderScope(
      overrides: [
        blueprintProvider.overrideWithValue(selectedConfig)
      ],
      child: const MyEduApp(),
    ),
  );
}

Now any widget can read the configuration.

Widget build(BuildContext context, WidgetRef ref) {
  final config = ref.watch(blueprintProvider);

  return Text(
    "Welcome to ${config.appTitle}!",
    style: TextStyle(color: config.brandPrimaryColor),
  );
}

The UI is completely blind to the domain.

It simply renders what it’s given.

That’s the whole point.

Why This Changes Everything for a Solo Founder

Every bug I fix in the core gamification engine — streaks, XP, offline progression — gets fixed for every app compiled from this codebase.

Write the fix once
Ship the improvement once
Every flavor inherits it

That leverage is everything for a solo developer.

I’m betting this architecture will outlive any single app I build with it.

Whether that’s a smart long-term bet or just what you tell yourself after spending a weekend over-engineering…

I guess we’ll find out.

If you want to see how this engine feels in production, I just shipped the first flavor:

PyMaster is now live on the Google Play Store, featuring:

gamified offline progression
a dynamic theme engine
a built-in AI tutor

Discussion

Have you architected something similar?

Did you go with:

app flavors
monorepos
plugin architectures

I’m curious what trade-offs you ran into.

Drop your thoughts in the comments 👇