For more than a year, the NanoRich signal board existed only as a web interface embedded in a regional lifestyle platform I operate. During market hours, I could open it on any browser, on any device, and watch the signals update in real time. The system worked. The display was clear. I had no particular reason to build a dedicated app.
Then I started noticing how I actually used it.
How I Was Actually Using the Dashboard
The theoretical use case for the signal board was this: sit at a desk, open the browser, watch the signals develop through the morning session, act on confirmed signals with the full context of a desktop environment. That was the design assumption.
The actual use case was different. I was checking the dashboard on my phone — while commuting, while eating, while doing other work between sessions. The web interface worked on mobile in the sense that it displayed correctly and updated in real time. But the experience was noticeably degraded compared to desktop. The layout, designed for a wider screen, required constant scrolling. Tapping on a signal card to see details was imprecise. Loading times on mobile networks, while not severe, added a friction that the desktop experience didn't have.
More importantly, the web interface had no notification capability. If an A-grade signal fired at 09:47 while I was away from the screen, I had no way to know until I happened to check. Several times over the course of a month, I discovered after the fact that a strong signal had fired and resolved — either hitting its target or reversing — while the dashboard was open in a background browser tab I hadn't checked.
These two observations — degraded mobile experience and no notification system — were the functional reasons for building an app. But there was a third reason that took longer to articulate.
The Monetization Question
The signal board was, at this point, a tool I had built for myself. It had no other users and no revenue. The Python server running on my desktop generated signals from my brokerage account data. The Firebase database received those signals. The web interface displayed them. The entire system served one user: me.
At some point during the fourteenth month of running the system, I started thinking about whether the display layer — the part of the system that reads from Firebase and shows the signals — could be separated from the detection layer and turned into something other people could use.
The detection layer is inherently personal. It requires a connection to a brokerage account through the brokerage's API, which means it has to run on the account holder's own machine. I can't run it on behalf of other people without effectively managing their accounts, which creates legal and practical problems I don't want.
The display layer is different. The Firebase database is just a data source. A mobile app that reads from that data source and displays it doesn't need to connect to anyone's brokerage account. If I designed the app to show signals from my Firebase database — signals generated by my detection system, running on my machine — other users could install it and watch the same signal board I watch during market hours.
This is a fundamentally different product from an algorithmic trading system that trades on users' behalf. It's a read-only display of publicly visible signal data. The legal and practical complexity is minimal compared to any approach that involves executing trades.
The monetization model followed from this structure: a free app supported by advertising. Users get access to the real-time signal board. I get ad revenue. The signals are mine, generated by my system, displayed for an audience that finds value in watching a real-time breakout detection system during Korean market hours.
What the App Needs to Do
Once the concept was clear, defining the requirements took about an hour. The app needs to do five things, in roughly this order of importance.
First, display real-time signal data from Firebase in a clear, mobile-optimized layout. The web interface was designed for desktop; the app needs to be designed from the start for a phone-sized screen with thumb navigation.
Second, send push notifications when specific signal events occur — primarily when a stock reaches the confirmed signal state, and optionally when an A-grade secondary signal fires.
Third, show the signal history for the current session, including signals that have already resolved, so users who open the app mid-session can see what they missed.
Fourth, provide a clean explanation of what the signals mean — what the grades indicate, what the stages represent, what the legal context is (this is a data display, not investment advice). This is as much a legal requirement as a usability one.
Fifth, display advertising in a way that generates meaningful revenue without making the core experience unusable. Banner ads at the bottom of the screen during normal browsing, with a full-screen interstitial on app launch, is the standard approach for this category.
Push notifications are the most technically complex requirement — they require a notification service that can trigger on Firebase database writes, which involves a server-side component that the current architecture doesn't have. Everything else can be built as a client-only Flutter app.
Why Flutter
The choice of framework came down to three criteria: Firebase integration quality, AdMob integration quality, and platform reach with a single codebase.
Flutter, Google's cross-platform UI framework, wins on all three. Firebase is a Google product; its Flutter SDK is maintained by Google and is consistently the best-supported client for Firebase's various services. AdMob is also a Google product, and its Flutter plugin is similarly well-maintained. And Flutter produces a native-performance Android APK from a single Dart codebase — the same code that could later be extended to iOS without rewriting the core logic.
The alternative I considered briefly was React Native, which would have let me reuse more of the JavaScript and React code from the existing web interface. The reason I chose Flutter over React Native ultimately came down to performance: the signal board updates in real time from Firebase, with potentially many state changes per second during active market periods. Flutter's rendering approach handles high-frequency UI updates more cleanly than React Native's bridge architecture, and for a real-time display application, that difference matters.
What Comes Next
The development process from this decision point to a working app took approximately three weeks of focused weekend work. The path wasn't entirely smooth — Firebase notification integration in particular involved several dead ends before I found an approach that worked cleanly — but the core display functionality came together faster than I expected.
The following posts in this series cover each stage of that development: building the real-time display in Flutter, integrating Firebase push notifications, adding AdMob, designing the mobile UX, and navigating the app store submission process for both Google Play and the Korean-specific One Store platform. Each stage produced at least one problem I hadn't anticipated, and the solutions to those problems are worth documenting in detail.
Today's Investing Insight — The Difference Between a Signal and a Recommendation
One of the most important distinctions in financial services regulation is the difference between providing a signal or data display and providing investment advice or recommendations. A signal — in the context of a system like this one — is a summary of quantitative market data at a specific moment: price, volume, momentum indicators. Displaying that signal tells the viewer what the data showed. A recommendation tells the viewer what to do based on that data. The distinction matters because investment recommendations typically require regulatory licensing in most jurisdictions, while data display generally does not. The NanoRich app is designed to stay clearly on the data display side of this line: it shows what the algorithm detected, with explicit labeling that no investment decision is implied, and leaves all trading judgment entirely to the person viewing it. Maintaining this distinction clearly — in the app's description, in its in-app text, and in its design — is not just legally important but also honest: the system genuinely is a detection tool, not a decision-maker.
---
This post documents a personal journey of building a mobile application to display algorithmic trading signals and is not a recommendation of any specific stock, strategy, or investment approach. All investment decisions and their outcomes are the sole responsibility of the investor.
Comments
Post a Comment