1. Dev Bundle + us doing the technical side

Honest answer: that combination isn't something we offer. There's no "Dev Bundle with us managing it" — they're two separate tiers. Managed is the done-for-you service on our accounts, and the Dev Bundle is full source ownership that you run yourself.

But you can get exactly what you're describing by doing them in sequence: start on Managed, buy the Dev Bundle when you're ready to take over.

On Managed, everything runs on our accounts — Expo, Apple, Google — and we handle setup, deployment, builds, updates and releases. You don't touch any of it. When you want full ownership, you buy the Dev Bundle at that point and we hand it over.

2. Switching later — no rebuild, ever

It's the same dashboard either way. Nothing gets rebuilt from scratch.

The handover is: you create your own Expo/Apple/Google accounts, we export a snapshot of our dashboard for your app, you import it into yours, and you're running the identical app with the identical config. Then you remove us as admins on your accounts and it's 100% yours. That's it.

So there's no lock-in and no penalty for starting Managed — it's the same product, just a question of whose accounts it lives on and who pushes the buttons.

The one thing worth being straight about: once you take it over, you're the one maintaining it. It's a React Native / Expo app, so the handover lands best with someone who's comfortable in that stack.

3. The $50/year on the Dev Bundle

That's for future core updates only — roughly $4/month. It's not a license fee and it's not required to keep your app running. Your app, your source code, yours forever whether you renew or not.

Plenty of Dev Bundle owners cancel it: if you're forking the code and taking it in your own direction, our updates stop being useful to you anyway. Keep it if you want to keep pulling in new features and fixes we ship; drop it if you don't.

4. Facebook / TikTok / Google pixels

Yes — and this is worth explaining properly, because it's central to how the app is designed.

The app is built in two halves. The native React side covers all the Fluent Community experience — feed, spaces, courses, messaging, profiles, notifications. That's the part that has to feel like a real app, so it is one.

Everything else runs through the in-app browser, and we've put serious work into making that first-class: users stay logged in, pages render properly, and they never get bounced out to Safari or Chrome. So your custom pages, sales pages, payment portals, funnels — all of it opens inside the app, looking and behaving like part of it.

That's deliberate. It means you're not waiting on us to ship a feature every time you want to do something. Build the page on your site, and it's in your app.

For your question specifically: your Facebook, TikTok and Google pixels fire in there exactly as they do on the web. Same tags, same events, same attribution on your checkout and landing pages — nothing to install on the app side.

The one distinction worth knowing: native app-install tracking (Meta/TikTok/Google Ads reporting installs and native in-app events) is a different thing — that needs each platform's mobile SDK compiled in, which isn't in the core app. But if what you're tracking is page views, leads and purchases, your existing pixels already cover it. And on the Dev Bundle you own the source, so your team can add any SDK they want later.

No rush on any of this — take a look through it and talk it over with your team first. The main question worth answering on your side is who the React Native person would be — the one who'd eventually own the builds and releases. If you've got that person, the Dev Bundle path makes sense whenever you want it. If you don't yet, Managed is the obvious starting point and you lose nothing by going that route first.

Happy to answer anything else they come back with.

On the UI refinements

Short answer: yes, all of that is possible. Like a few other requests I've had recently, it's less about "can it be done" and more about finding the version that works for everyone — so the direction I'm heading is opening these up as options in the customizer rather than hardcoding one look. Font size in chat and article typography/spacing are good candidates for exactly that, so each community can pick what fits.

The one thing I'd push back on slightly: my goal is to stay feature-identical to native Fluent Community. I'll happily tweak layout, spacing and typography, but I won't strip features out to get there. Within that, there's a lot of room.

Could you give me a bit more detail on "a cleaner community feed"? That's the one I can't picture yet. If you can describe what you'd add, remove or tighten up, I can tell you straight away whether it's a customizer option, a layout tweak, or something that'd conflict with feature parity.

Since you're using this as a personal article/journal rather than a course, the Substack comparison actually maps well — articles and chat are the two screens I'd be tuning, and both are native.

On the shop layout

This one works differently. The shop isn't a native React screen — it's a webview. It's literally your existing web shop page, loaded inside the app, with the login carried over and the site header/footer hidden so it feels native rather than like a browser.

That's deliberate. Apple and Google don't allow selling digital goods in-app unless you use their in-app payment systems, and they take ~30%. So the app is built to do the native Fluent Community social side — feed, chat, spaces, profiles, notifications — and use webviews for everything else: shops, custom plugins, and the hundreds of custom pages people have on their sites that no app could cover natively.

Practical upshot: whatever your shop looks like on the web is what it looks like in the app. Whichever theme and cart you use (FluentCart, WooCommerce, etc.), a 2-column product grid is a change you make on your site — and the app picks it up automatically. That's actually the easier path for you, not the harder one.

On future costs

Beyond my $100 setup and $33/month, the only other costs are the app stores' own fees, paid directly to them, not to me:

• Apple — $99/year for the Apple Developer Program
• Google — $25, one time

That's it. Expo (builds and over-the-air updates) and Firebase (push notifications) both sit comfortably on their free tiers, so there's nothing to pay there. No other recurring costs on my side — builds, store submissions and ongoing updates are all covered by the monthly.

On annual billing

Not something I offer at the moment — but the flip side is you're not locked in. If you ever decide you'd rather take it in-house, you can move to the Dev Bundle instead and stop the subscription.

One thing worth flagging on timing: every site is different — some onboard in a few days, others need more work — so I only take on a handful of Managed clients at a time. There's a waitlist signup on the page if the current batch is full. The Dev Bundle is always available with no wait. We are currently working with a few sites onboarding so could be a week or so before we open up for a new batch.

Send over the feed detail whenever you get a chance and I'll give you a straight yes/no on each piece.

Thanks, James