Regretting/Questioning my current stack Flutter + Elixir as solo dev for mobile app

Chat / Discussions
1

Hey everyone. I’m feeling a bit conflicted. I’ve learned Flutter and built a somewhat MVP of this app. I’m a solo dev and throughout this time though I’m realizing that I really don’t like having to maintain an elixir backend with a Flutter mobile. Also, wow the flutter web is so bad.

The concept was supposed to be simple. A way for you to write thoughts from the ‘voices’ in your head. You can take a look at the ‘MVP’ so you can see the basic specs of what I’m trying to do.

app.mentalkit.app
u: test@test.com
password: test@test.com

I feel like I’m at the point that I have a few routes in my mind:

  1. Drop the elixir backend and go all in with flutter and a BaaS-like pocketbase until it’s off the ground and just have mobile apps only. Not scalable but good enough for starters I guess.
  2. Pick up the old liveview code and somehow make it so I can turn this into an app. Although I really want offline mode and if I want that, then why bother doing this.
  3. Use the JS ecosystem, make it into a PWA, and find a way to put it into the stores. I’ve already written a significant version in Svelte but decided to drop it as well because I was thinking I can have all 3 with Flutter.
  4. A more brilliant option than in my list.

I’m only one person and I want to put this milestone of the project. I fear that if I don’t put it on the app stores, and potentially offline ability it won’t even have a chance. I really love the idea of this app and I can see the future of it but I feel that the flutter elixir combo isn’t the way until I get it off the ground.

For other MVP (and beyond) peeps in the space, I really need your advice on what to do. I know the Elixir bias is there but mine is too haha. If I could I would really prefer to just use Liveview and stick with that but it feels wrong and limiting for what I aspire this thing to be.

Anyways, would love to hear everyone’s thoughts on this. Thank you <3

7 Likes
2

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

5 Likes
3

Is maintaining the Elixir backend your only problem? Is there any other issues related to Elixir that made you regret your decision? Because if there isn’t, then whatever backend you decide to have you will have to maintain it. Unless you can go full Firebase but that comes with its own limitations.

Also, if web is involved, Flutter Web is a bad, bad framework. For MVP you could maybe stick to familiar tech stack and do something like OnsenUI or Ionic, and then move to more native solution when you have some dedicated availability? I haven’t been on this space since 2017 but those were good enough back then.

Edit: I wouldn’t bet on LiveView for mobile apps just yet. You need to keep your options open and having an API is optimal for that. You can wrap a web view or move to native and even switch from flutter to compose etc if you have this option. With LiveView you might have to touch some backend code again to switch front end to native if (and with mobile, it’s more of a when than an if) needed.

5 Likes
4

How is Flutter/Supabase friendliness? I know it has some magic when Firebase is involved.

1 Like
5

If you still have the Svelte code, live_svelte might be worth a look.

2 Likes
6

For me maintaining the server isn’t the issue, it’s having to manage both front-end and back-end codebases as a solo dev while also dealing with Flutter’s quirks. I’m also questioning if I can see myself coding long-term like this because it’s a lot of dev time to give people native apps like this, and it’s not even out. You can see that it looks meh, and the onboarding has a lot to get through. It’s difficult concepts to teach people on how to use the app unless they’ve gone to therapy, so I need to nail the onboarding.

Essentially there’s a lot of mental overhead for my small brain to upkeep with both client and server, and I’m not too content with the client

3 Likes
7

My hesitation is vendor lock-in when it comes to superbase, but it is really solid when it comes to DX. Had a shot at it for this app and it was smooth!

1 Like
8

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!

32 Likes
9

Very valid points. Thank you Jose for weighing in! You’re right :slight_smile:

10

I can’t say much about flutter, but I can say about native android development, it is and was a big failure from the start, the abstraction level is too low, you need to understand a lot of android internals, the material is scattered and mostly consists of low quality answers on stackoverflow, the amount of scaffolding to get something going is insane, bad and opinionated practices that hug both old applications and new ones.

As much as I hate js, I would go almost always for a web application instead of a native one, solely from upfront investment you have to make.

5 Likes
11

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 :wink:

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 :sweat_smile:.

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.

12 Likes
12

As I can’t log in, I can’t tell if Elixir is needed on the backend. If the backend is trivial enough it can easily be done with firebase (+cloud-functions) or sth similar. Elixir shines brightly on the backend when it gets a little more involved.

What don’t you like about flutter-web? Isn’t that just a “normal” flutter app compiled for web?

For a MVP/POC I can’t imagine anything more productive than LV, just throw it away if you think it works (or keep the backend maybe).

2 Likes
13

The way the compile their code to JS leaves bugs that are really hard to hack around. For example when typing, depending on the component the text in the input will move up and down. Took me a good 3 hours for a work around. This is due to carat rendering and so you need to shrink the carat. That’s just one off the top of my head.

2 Likes
14

It looks like it is TypeScript, not Elixir, isn’t it?

15

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 :joy: )

7 Likes
16

Any web app in any programming language can be a a PWA, but PWAs cannot be uploaded to Android or Apple stores, because they are just web apps. A web app just needs a manifest.json file to instruct mobile devices how to add it to the home screen to then open them like if they were a “native” mobile app. So, this is all you need to have a basic web app working on a mobile device as a PWA app. Off-course more can be done to leverage the PWA concepts in a web app.

5 Likes
17

Supabase is built with Elixir but they have different client libraries with for example Typescript. So the backend Supabase is running is in elixir (meaning you get many of the good stuff from the beam) but you interact with it using client libraries like typescript. So the backend is elixir but yea you don’t really see any of the elixir.

3 Likes
18

I see a “realtime” repository using elixir, but I do not see a core repository with Elixir ( Supabase · GitHub ) so I’m not really convinced.

19

They use a whole slew of technology building on top of postgres, but afaik realtime is a core part of their offering. But yes it’s not a big elixir monolith + postgres.

2 Likes
20

This has a bit more on what they use elixir for: Thinking Elixir Podcast 73: Elixir at Supabase with Paul Copplestone

3 Likes