DEV Community: Bhanu Nagpure

Your agent looks healthy. It isn’t. Building recursive observability with SigNoz MCP

Bhanu Nagpure — Sun, 26 Jul 2026 16:06:07 +0000

Hackathon: Agents of SigNoz · Track 1 (AI & Agent Observability)

Code: github.com/bhanu-dev82/agentscope

Demo video (~2:43): Demo_AgentScope.mp4

I spent a solid chunk of this week staring at a dashboard that said everything was fine while the agent underneath was spinning in a tool loop. Latency looked normal. Error rate was zero. HTTP kept returning 200. Tokens kept leaving the account.

That gap — “green APM, broken agent” — is what pushed me to build AgentScope for the Agents of SigNoz hackathon.

Our operator console. The tagline is not marketing fluff; it is the bug report we kept hitting.

Why standard APM lies to you about agents

I am not saying traces are useless. They are necessary. But most of the agent failures I care about are semantic:

Same tool fires over and over in one conversation (loop)
A researcher step burns thousands of tokens on padding or retries
The model returns confident garbage and the HTTP layer still celebrates

None of that shows up as a 5xx. Your SLO board stays calm. You only notice when the bill arrives or a user says the answer is nonsense.

For Track 1 I wanted something sharper than “we exported OpenTelemetry to SigNoz.” The question I wrote on a sticky note was:

If an agent can use SigNoz through MCP, can that same agent show up as spans inside SigNoz?

That loop — monitor using the product, then appear inside the product — is what I ended up calling recursive observability. Slightly dramatic name. Accurate description.

AgentScope in one picture

Three moving parts:

A small multi-agent pipeline (Planner → Researcher → Summarizer) on LangGraph + Gemini
Self-hosted SigNoz from Foundry, with MCP turned on
A Watchdog process that polls SigNoz MCP, runs detectors, logs interventions, and writes its own spans back

UI → pipeline → SigNoz → Watchdog. Recent sessions show loop / cost / silent inject modes we actually ran.

Rough data path:

Browser UI (:3000)
    → FastAPI (:8888) runs LangGraph
        → OTLP gRPC (:4317) into SigNoz
            ← Watchdog polls MCP (:8000)
            → Watchdog also exports spans on OTLP

Chaos buttons in the UI do not flip a boolean for the detector. They make the pipeline emit real span shapes. The Watchdog only sees what ClickHouse has after ingestion. That constraint kept me honest.

How I actually used SigNoz

This is the section judges care about, so I will be concrete.

Foundry, not a mystery compose file

Rules want casting.yaml and casting.yaml.lock in the repo. Fair. I cast SigNoz with MCP enabled:

apiVersion: v1alpha1
kind: Installation
metadata:
  name: signoz
spec:
  deployment:
    mode: docker
    flavor: compose
  mcp:
    spec:
      enabled: true

foundryctl cast -f casting.yaml

After that: UI on 8080, OTLP on 4317, MCP on 8000.

I lost half an evening when OTLP stopped accepting data while the UI still looked healthy. Turns out OpAMP had rewritten collector pipelines toward nop receivers. Fix was boring and real: force file-based collector config, recreate the ingester, watch logs until gRPC 4317 came back. If your demo has “no traces,” check the collector before you rewrite application code. I rewrote application code first. Do not be me.

Traces with agent-shaped names

I bootstrapped OpenTelemetry before LangChain imports. Order matters; I learned that the hard way when half the spans vanished.

What landed in SigNoz for service agentscope:

invoke_workflow AgentPipeline
invoke_agent Planner / Researcher / Summarizer
execute_tool web_search
generate / LLM spans from the model path
attributes like gen_ai.agent.name, token usage, conversation id

I did not invent a new observability religion here. I just refused to ship a single fat “HTTP POST /run” span and call it agent ops.

MCP as a polling data plane (not a chat stunt)

A lot of demos open MCP, ask one question, screenshot the answer, done. Fine for a keynote. Useless as an ops loop.

My Watchdog:

Opens MCP session to http://localhost:8000/mcp
Sends SIGNOZ-API-KEY (created in SigNoz → Settings → API Keys)
Every ~10 seconds calls tools like signoz_aggregate_traces
Parses the response
Runs detectors
Dedupes on (failure_type, trace_id) so it does not spam forever
Writes a critical log (optional webhook if you set one)
Emits invoke_agent Watchdog plus child tool spans such as execute_tool signoz_loop_check

Loop, cost spike, silent failure — each with action logged_critical and a real trace id.

One parser bug cost me more time than the detectors: MCP aggregate payloads are columnar (columns + data), not a list of objects. My first code assumed rows-of-dicts, scanned “three rows,” found nothing, and I almost blamed ClickHouse. Always print the raw shape once.

What the detectors look for

Inject	Pipeline does	Watchdog looks for
Loop	Ten `web_search` tool spans in one trace	count of `execute_tool *` per (trace, name) > 5
Cost spike	Heavy token padding on the researcher	High input token sum on the trace
Silent failure	Garbage tool output + span `semantic_failure silent_output`	Aggregate on name containing `semantic_failure`

For loops I group by span name (execute_tool web_search) more than nested attributes. Attributes were flaky under time pressure; names were stable in the explorer.

I also had to exclude the Watchdog’s own signoz_*_check tools from the loop rule. Otherwise the monitor alerts on itself and you invent a very philosophical outage.

Metrics, logs, dashboards

Traces carried the story, but I still exported metrics (token usage, durations), bridged Python logs into OTel, and scripted a few dashboards/views through MCP. Not every panel is glamorous. Having API keys + MCP + Foundry in one product is what made the Watchdog feel like a real consumer of SigNoz instead of a side script scraping HTML.

The live path I show in the video

Inject loop / cost / silent. Status can still be Complete with a 200 path.

Hero path:

Open Live Demo, hit Inject loop
Pipeline finishes. No HTTP error theater. Error rate still zero.
Wait. I mean it — 15 to 40 seconds for OTLP batch + ClickHouse. The UI even says so. Instant detection would be a lie.
Watchdog tab lights up: tool web_search called 10 times, threshold 5, logged_critical, real trace_id
Jump to SigNoz Traces

This is the recursive proof. Same service name. Monitor spans next to pipeline traffic.

When invoke_agent Watchdog and execute_tool signoz_loop_check showed up next to the pipeline, the sticky note question was answered. The monitor is not invisible. It is another agent-shaped workload on the same backend.

Full walkthrough is in the demo video (~2:43). Deck is in the repo if you want slides.

Things that bit me (so you skip them)

Ingestion lag. I almost built a fake “instant alert” path for the demo. Glad I did not. Real ClickHouse lag is part of the product story.

Self-alerting. Exclude your own MCP tool spans from loop detection. Sounds obvious after midnight. Less obvious before.

Collector config vs UI health. SigNoz UI up ≠ OTLP path healthy. Verify 4317 when traces disappear.

Attribute worship. Nice when they index cleanly. For hackathon detectors, span names got me further.

English + live demo. I am not a native English speaker. I wrote a short script, practiced once off camera, and recorded with OBS. Slow is fine. Clear inject → detect → SigNoz is better than fast mumbling.

Stack, short

SigNoz via Foundry (casting.yaml, MCP, API keys, traces/metrics/logs)
Python FastAPI + LangGraph + Gemini
OTel traces, metrics, logs to OTLP
React operator UI for inject + interventions
Repo: bhanu-dev82/agentscope

Run sketch (details in README):

git clone https://github.com/bhanu-dev82/agentscope.git
cd agentscope
foundryctl cast -f casting.yaml
cp .env.example .env   # SIGNOZ_API_KEY, GEMINI_API_KEY
python3 -m venv venv && source venv/bin/activate
pip install -r requirements.txt && python -m src.run
cd ui && npm i && npm run dev -- --port 3000

Closing

I did not invent agent monitoring. I wired a small multi-agent app to SigNoz the way the hackathon asks you to — Foundry, deep signals, MCP as something an agent actually calls on a timer — and I made the monitor leave fingerprints in the same traces UI.

If your agents only look healthy, dig one layer under HTTP. And if you build a watchdog, put it on the board too.

Recursive observability: observe agents with an agent, through SigNoz MCP. The monitor is itself monitored, in the same product.

Links: GitHub · Video · Deck · SigNoz

I Built a Python Learning App From a Hospital Bed. Here’s What I Actually Built.

Bhanu Nagpure — Tue, 16 Jun 2026 08:03:38 +0000

I graduated. Then I got sick. Then I built an app.

I was stuck in a hospital bed, freshly out of college, with nothing but my laptop and a question I couldn't stop thinking about: Why is learning to code still so painful in 2026?

I remembered exactly how it felt to be a beginner staring at a Python tutorial that assumed I cared about abstract theory before writing a single working line. So I built PyMaster. It shipped on January 26, 2026. Here's what's inside - and what it actually took to build it alone.

Learning That Feels Like Playing

The structure is zone-based. You work through Zone 1: The Foundation - First Contact, Memory Bank (variables), Data Types, The Converter - unlocking the next zone only when you've genuinely understood the current one. No skipping. No guessing your way through.

The home screen shows your name, level, streak, coins, and one clear nudge toward what to tackle next. No dashboard overwhelm.

Practice Arena: Where the AI Lives

The app watches your performance and identifies weak spots. If your PREDICT_OUTPUT mastery is at 5%, the AI builds a focused session targeting exactly that gap - and tells you so explicitly.

You pick your format: Quick (5 Qs), Blitz (10 Qs), or Marathon (25 Qs). Then your intensity: Standard play or Sudden Death - 1 life only.

There's also a Python Sandbox - write and run real Python entirely offline. For a learner with spotty connectivity, this isn't a feature. It's the point.

The AI Tutor Runs on Gemini

The AI tutor is built on Gemini 3.1 Flash Lite via the Gemini API. I chose Flash Lite deliberately - fast, efficient, and perfect for short contextual explanations mid-session.

Each track has a custom system prompt. The Python Core tutor explains errors like a patient teacher. The GenAI track tutor is configured differently because someone learning to build with generative AI needs different mental models. The mastery detection in Practice Arena feeds directly into what the AI surfaces next. It's woven in, not bolted on.

How Antigravity Kept Me From Drowning

I built this solo. Antigravity became my agentic development partner in ways I didn't fully anticipate.

The obvious value was bug detection - catching logic errors in my streak system, flagging edge cases in offline sync I'd have found three weeks later in a Play Store review. But the bigger win was automating the repetitive parts. Every new screen needed the same scaffolding work - new lesson types, new zones, new career tabs. Antigravity automated the template setup. I described what I needed, it generated the structure, I filled in the logic.

When you're building alone, that's not a productivity gain. That's the difference between shipping and not shipping.

Three Tracks. One Engine.

Python Core - fundamentals, for everyone
Data Science - Pandas, real datasets
GenAI - building with Generative AI using Gemini

Same engine underneath. Completely different curricula, question banks, and AI tutor behaviour per track.

Who's Actually Using It

I built this with Indian students in mind. The reality turned out bigger.

Users are coming in from South Asia, South Africa, and Brazil - spending 15 to 30 minutes per session, which for mobile learning is a genuinely strong engagement number. That's not a passive scroll. That's someone working through a lesson.

The geographic spread confirmed something I suspected: this isn't an Indian problem. It's a global one, concentrated wherever laptop-first education has left learners behind.

Content updates are coming. The question banks will grow, new zones will ship, and the AI tutor will get sharper. The foundation is in place.

What I'd Tell Someone Starting Out

Build something real. Use Gemini not just as a coding assistant but as a thought partner - ask it why, not just what. And use agentic tools to kill the mechanical work so your energy goes into making the product actually good.

PyMaster is live on the Google Play Store. Built by one developer, from a hospital bed, shipped on Republic Day.

I'd love to hear what you think.

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 👇