DEV Community: Brian

I Shipped My App to Production. An Hour Before Upload, I Realized I Was Wrong About My Own Paywall.

Brian — Wed, 15 Apr 2026 14:37:21 +0000

Two days ago I thought I was done.

My Flutter journaling app, Eventide, was approved for Google Play production. The AAB was built. The store listing was polished. I'd spent 30 days writing code and 5 months refining it. All that was left was clicking "Start rollout."

Then, an hour before upload, I asked myself a question I probably should have asked weeks ago:

How many entries should a user get for free before the paywall shows up?

I had it set to 3.

That number came from my original spec. I wrote it months ago and never questioned it. Three felt "fair" — enough to try the product, not so much that the free tier eats premium conversions. Clean. Decisive. Done.

Then I actually looked up the research.

The Data That Killed My Plan

I spent 20 minutes searching for paywall best practices for subscription apps in 2026. Here's what I found:

Paywall fatigue starts at ~2 exposures per user. After that, click-through drops by -0.40 per additional exposure.
23% of freemium conversions happen 6+ weeks after download. These are users who needed time with the product before committing.
Hard paywalls filter 90% of users before they see the paywall at all, which means the "high conversion rates" on hard-paywall apps are measuring survivors, not strategy.
Wellness apps have the highest trial-to-paid conversion (35%) but the lowest first-renewal retention (30.3%). Easy to sign up, hard to keep.

Translation: showing a user the paywall after 3 entries would trigger it before they'd built enough habit to want what's behind it. Most users wouldn't even open the app a second time, let alone value the features I was gating.

The research was clear. 3 was wrong. I needed 7.

Seven entries ≈ one week of journaling. By then, a user has:

Experienced the AI reflection loop (the hook)
Started to build data (mood patterns, entries worth searching)
Opened the app multiple times, creating habit anchors

That's the natural moment for a paywall. Not day one.

I updated one line of code:

// Before
const _freeEntryLimit = 3;

// After — research-backed: 7 entries ≈ 1 week of journaling
const _freeEntryLimit = 7;

Rebuilt the AAB. Uploaded version 15. Shipped.

An hour later, the production release was live. The next morning — yesterday — the first six people installed Eventide.

What Else I Got Wrong on Launch Day

That wasn't the only thing.

My X account got suspended two days before launch. "Inauthentic behavior." I'd been using Buffer to schedule posts (a legitimate tool), but posting the same type of content multiple days in a row during launch week apparently triggered a spam filter. I appealed. Still waiting.

Lesson: don't rely on any single channel for launch day, especially platforms you don't own. I recovered by leaning harder on LinkedIn, Instagram, and direct texts to friends. The X account was less than 1% of my planned launch reach. Losing it hurt ego more than outcomes.

My notification plugin silently fails on Android 16. The user on my Galaxy S24 Ultra (Android 16, API 36) gets a "reminders aren't available on this device" error when they toggle morning reminders. The flutter_local_notifications package hasn't fully updated for API 36. Most users are on Android 13–15 where it works — but the bug is real and I shipped anyway.

Lesson: if a feature affects under 1% of users and can be fixed in a point release, don't block launch. Document the issue, prioritize the fix, and keep moving. I tracked it in a known-issues doc before upload.

Ambient audio doesn't play on one Pixel 9 Pro XL user. The breathing exercise audio works. The background ambient music doesn't. Same just_audio package, different file (9MB MP3 vs 689KB WAV). Haven't isolated the cause yet. Also shipped.

Three known issues at launch. Zero of them were showstoppers.

The Unexpected Part

The thing that surprised me most wasn't any of those.

It was how much of launch day was psychological, not technical.

I had decision fatigue by 2 PM. When my store listing needed a short description rewrite, I stared at the field for 10 minutes before doing it. When a tester reported the ambient audio bug, my first instinct was to push launch back a week. When I found the paywall research, I almost ignored it because I'd already decided.

The discipline of "trust research over instinct when you're tired" is the single most valuable thing I learned today. I have no data to support it. Just one observation from one solo dev who almost shipped a broken paywall configuration because he didn't want to rebuild the AAB one more time.

The Numbers (First 24 Hours)

Here's exactly what Google Play Console shows:

Closed testing (April 8–14):

38 testers across 3 release iterations (builds 11, 12, and 13)
32 monthly active users
0 crashes reported
Zero showstopper bugs surfaced before production

Production launch (April 14, first 24 hours live):

6 device acquisitions
0 crashes
0 reviews yet
Production release cleared Google's review in under 48 hours

Small numbers. I'm fine with that.

The research I quoted earlier says 23% of conversions happen 6+ weeks after install — which means Day 1 isn't the game. Day 30 is. Day 180 is. Six installs today. Whoever those six people are, they're the first real humans to experience the product I've been thinking about for half a year. That's enough.

The 38 testers across three build iterations is actually the number I'm proudest of. It means I shipped, broke something, fixed it, shipped again, broke something else, fixed that, and shipped again — instead of pushing version 11 to production and hoping. Closed testing is the cheapest mistake you'll ever make. Use it.

What's Next

Android 16 notification fix — priority for v1.1
Pixel 9 ambient audio fix — same point release
Breathing v2 — more patterns (4-4-4-4 box breathing, 5-5-7 deep relaxation), sampled audio instead of generated sine waves
Home screen widget — daily inspiration quote, passive re-engagement
iOS port — once Android feedback stabilizes

And I'm going to keep writing about it, because apparently the thing I got most wrong about launch was thinking I was done at the upload.

For Other Solo Devs Shipping Soon

The lesson that cost me the least but saved me the most: look up the research on every decision, even the ones you feel certain about. I was most wrong about the things I was most confident in.

If you've launched recently — what did you get wrong and only realize after shipping? Comments open. Genuinely want to hear it.

Eventide is a private journal and mood tracker with AI reflections that respond to your actual words, not generic advice. No streaks. No guilt. Free every day on Google Play.

Get Eventide on Google Play →

Find more at reflektapp.net.

How I Built a Journal App as a Solo Developer with Flutter + Firebase + Claude AI

Brian — Sat, 28 Mar 2026 08:49:01 +0000

Six months ago I was a solo developer with an idea: build a journaling app that uses AI to give people genuine reflections on what they write, not generic motivational quotes, but responses that actually engage with their words.

Today that app is live on Google Play. It's called Eventide: Journal & Mood, and I built every screen, every animation, every backend function myself. Here's the full technical story, the decisions that worked, the ones I'd reconsider, and what I learned shipping a real product alone.

The stack

Layer	Choice
Framework	Flutter (latest stable)
Language	Dart, strict null safety
State management	Riverpod + riverpod_generator
Navigation	go_router
Backend	Firebase (Auth + Firestore + Cloud Functions)
AI	Anthropic Claude API via Firebase Cloud Functions
Subscriptions	RevenueCat SDK
Local storage	Hive
Charts	fl_chart
Design	Material 3, Google Fonts (Lora + Inter)

Why Flutter

I needed iOS and Android from a single codebase. React Native was the other contender, but Flutter's rendering engine won me over. When you're building something with custom animations (breathing exercises, mood selectors with radial pulse effects, a Year in Pixels grid with 365 tappable squares), having full control over every pixel matters.

The hot reload cycle is genuinely as good as people say. I could tweak an animation curve, save, and see the result in under a second. For a solo dev iterating on feel and polish, that speed compounds fast.

The tradeoff: platform-specific plugins can be rough. Speech-to-text, local notifications, and biometric auth all required platform channel debugging that ate more hours than I'd like to admit.

Why Riverpod over Bloc or Provider

I evaluated all three seriously. Provider is simpler but doesn't scale well when you have computed state that depends on multiple sources. Bloc is powerful but the boilerplate for events and states felt heavy for a solo project where velocity matters.

Riverpod with code generation hit the sweet spot. Providers are testable, composable, and the ref.watch pattern makes reactive UI straightforward. My insights screen computes a 30-day rolling mood average, weekly summaries, a Year in Pixels map, and entry mode breakdowns, all derived from a single list of journal entries through chained providers.

One pattern I landed on: every screen handles three states explicitly. Loading, data, and error. No exceptions. This sounds obvious but it's easy to forget error states when you're moving fast, and users notice.

The AI architecture (and why the API key never touches the client)

This was the most important architectural decision in the entire project.

Eventide uses Anthropic's Claude API to generate reflections on journal entries. The temptation as a solo dev is to call the API directly from the Flutter app. It's faster to implement, fewer moving parts, ship it and move on.

Do not do this.

Any API key embedded in a mobile app binary can be extracted. It doesn't matter how you obfuscate it. Someone will decompile your APK, find the key, and either abuse your quota or do something worse. I've seen indie devs get surprise bills in the thousands from this exact mistake.

Instead, I set up a Firebase Cloud Function as a proxy. The Flutter app calls the Cloud Function (authenticated via Firebase Auth), the Cloud Function reads the Anthropic API key from environment config, calls Claude, and returns the reflection. The key never leaves the server.

Flutter App -> Firebase Auth Token -> Cloud Function -> Claude API -> Response

Three callable functions handle the AI layer:

getAiReflection — takes entry text, mood score, and entry mode. Switches the system prompt based on whether it's a full entry or a quick check-in. Full entries get a three-sentence reflection (empathy, pattern recognition, open question). Quick check-ins get one to two sentences max.
getWeeklyInsights — fetches the last seven entries, generates a two-sentence pattern summary, caches it in Firestore for 24 hours so repeat loads don't burn API calls.
getDailyPrompt — returns a random prompt from a server-side bank of 60 prompts across six categories. No AI call needed, just a JSON lookup.

The system prompts took more iteration than any other part of the project. Early versions produced generic therapy-speak. The final prompts explicitly ban words like "journey," "validate," and "self-care," and instruct the model to mirror the user's emotional register rather than defaulting to cheerful encouragement.

Offline-first with Hive

Journal apps have to work offline. People write on planes, in bed at 2 AM with bad signal, in waiting rooms with one bar of service.

Every journal entry saves to Hive first, then syncs to Firestore when connectivity returns. The sync flag (isSynced) on each entry tracks what needs uploading. This means the app is fully functional with no internet connection. AI reflections queue for later, but the core writing and mood tracking experience is instant.

Hive was chosen over SQLite for simplicity. It's a key-value store that handles Dart objects natively with type adapters. For a data model as simple as journal entries, it's more than enough.

RevenueCat for subscriptions

Implementing in-app subscriptions from scratch across both platforms is a notorious time sink. RevenueCat abstracts the store-specific APIs into a single SDK. I defined two products: monthly at $4.99 and annual at $29.99, both with a three-day free trial.

The free tier gives users three journal entries with AI reflections. After that, the paywall appears with a blurred preview of premium features (insights, Year in Pixels, weekly summaries). The blur is intentional. People need to see what they're missing, not just be told about it.

Lessons from shipping solo

Scope is everything. My original feature list was twice as long. I cut printed book export, multiplayer shared journals, and three other features that sounded great but would have delayed launch by months. Ship the core, iterate from feedback.

Design polish is not optional. Users judge apps in the first five seconds. I spent meaningful time on the onboarding flow, the animated lotus logo, the glassmorphic card effects, and the completion celebration screen. These don't affect functionality. They absolutely affect whether someone keeps the app installed.

Test on real devices early. The speech-to-text feature worked perfectly in the emulator and crashed on three different Android phones. Platform channel issues are real and you won't find them in simulation.

Your build environment will fight you. My project path had spaces in it, which broke a native build hook. I ended up using subst drives on Windows to work around it. Embarrassing but true.

What's next

The app is in closed testing on Google Play now. Firebase Auth and Firestore sync are being wired up to replace the local stubs. The Cloud Functions are deployed and tested, just waiting to be called from the client.

If you're a solo dev considering a similar project, my honest advice: pick a stack you can debug alone at midnight, design for offline from day one, and never put an API key in your client code.

Eventide: Journal & Mood is live on Google Play.

Download on Google Play

Check out the landing page at reflektapp.net

I'd love to hear from other indie devs building in this space. Find me in the comments or on the site.