From what you are saying, the split brain between front and back is what is killing your productivity. It also looks like you want to go mobile first, so to me, going with Supabase or another BaaS is the way to go (option 1). LV is not mobile ready (yet) and I don’t think JavaScript is going to avoid the split brain (plus JS frameworks tend to be moving targets).

You should also question if it is worth going with Flutter or focusing on one of Android or iOS. Check the demographics you are targeting. Most likely both have a large user base that will be more than enough to validate your product.

It is best to have something out there that you can iterate later on than nothing. Good luck!

Well, I will share a short summary of a journey I went through myself since your current conflicts are very related to the ones I had.

I have several app ideas (web & mobile), and started to try different stacks to see “what they taste like”.

I knew Elixir a bit, so I tried:

On mobile: Flutter, Swift & SwiftUI, Kotlin & Jetpack Compose.

On the backend: Go and Rust.

I work as Frontend/JS Developer, so I knew what was available in the frontend web space.

After several months of experiments, what I concluded was…

As a solo developer, creating an indie business, if I want to:

• create a mobile app, I would create a native iOS app with Swift & SwiftUI.
• create a web app, I would choose Elixir (with Phoenix and LiveView).

And the most important part of the message. Why would this be my choice?

The main reason: cohesive and convergent ecosystem. This is the most important thing a solo dev must have in order to have a chance to compete with a company with more resources IMO.

Both in Swift and Elixir ecosystems I felt that with very few tools I could create really solid applications, that in other ecosystems it would be nearly impossible to accomplish by myself with the same quality, velocity, and scope.

So my advice to you is, and what I am doing myself: do not try to win on all platforms at once as a solo dev. Choose one and nail it

If you go the mobile route, focus on the client and use a BaaS (in iOS you even have CloudKit “for free”).

If you go the web route, well, Elixir is my current bet.

I was really invested in mobile apps but in the end, I chose to go all-in in Elixir since it will give me more possibilities to create different types of apps in a high-level quality.

I also love functional programming, so it is a blessing to have this settled in the level of the language, without arguments .

ps: liveview native is very interesting since it is the only cross-platform framework AFAIK that uses the same building blocks that native frameworks use, so it is a better long-term investment knowledge-wise IMO. Definitely, I’ll try it in the future.

I don’t see them as popular at all, I see them as niche, a really very focus niche. In the web world they may be popular or not, it all depends on the bubble you are in. Due to work I am in the mobile bubble, and here native apps are kind of the kings, despite cross-native platforms keep trying to overthrow them from the ranking.

First, know your customer. Is it a an heavy mobile user? Are they from the younger generations?
If yes, then they may dislike to download an app from the mobile app store to realise that it’s not native, it lacks all the gestures and behaviours they are used in a native mobile app, thus they may uninstall it immediately, and you loose a customer, and/or you get bad reviews on the store.

The only way to put a PWA in the store is to wrap it in a webview. I don’t know other way, but I am not a mobile developer, just work on the security side.

When a user visits a web app in a mobile browser and the browser detetects the manifes.json file it may prompt the user to add the PWA to the home screen after the algorithm decides the user as interest on the PWA app. Another alternative is for you to detect the user is on mobile and show a popup with a button to add it to the home screen (not sure if his possible). The browser also as an option in the top menu to add the PWA to the home screen.

I didn’t say that they aren’t worth to distribute, I just say they are wrapped in web views and that may fireback against you. For example, you can buy fake iPhones, that are hard to distinguish by just looking to them, but easy once you get your hands on it, how would you feel by buying a fake one when what you wanted was a really iPhone? That feeling may be the one your mobile users will experience when they install an app from the store that turns out to not be a mobile app, just a website wrapped in a webview.

It depends on your use case and resources.
Most important, if you are competing with others that have a native mobile app then you may already be in the loosing side from day one.

FE/mobile dev is hard. You say the primary pain is the split but for a MVP I would think the Elixir side would be pretty frictionless. Maybe my perspective is skewed because I am primarily BE but I think the main problem with most indie app launches is the design/UX, because it takes a lot more resources to get that right than BE development does. Looking pretty, smooth transitions, etc are all critical.

From the POV of an informed user, rather than a dev, if I am testing out an app and it’s ugly/clunky, I am inclined to throw it out right away, even if potentially offers a lot of value in features. Conversely, if I am trying out an app that looks and feels great, but 3/4 of features are “pending”, I’ll hang around as long as it is adding some value. If I try to do something and it just errors out, but I get a slick notification and no FE crash, I sleep. Some action actually works but the page is ugly and I can barely tell it did work? Real shit. No thanks. And this is 10x as true for mobile apps as web apps.

So I guess my advice is, whatever helps you get the best looking UX as part of the MVP, do that. Skeleton prototypes really only work for internal purposes (even then you get complaints from colleagues )

Supabase is an excellent BaaS made in elixir if you want tips in that direction.