Hey guys. I've been working on this as a side project on and off this year, and decided to finally polish it into a real product and share it publicly. It originally started as a way to explore Elixir & Phoenix. Would really appreciate any feedback!
I'm planning to write a blog post in the next few days about the development as my first foray into Elixir.
The idea for the app in general came from the fact that I'm working remotely from all over the place, doing the "digital nomad" thing, and thought something like this could be fun. But an app like this needs a critical mass to actually get off the ground and succeed, hence the dynamic growing and shrinking areas based on activity. The idea being it greatly increases the chance when you open up the app, you're there with someone else.
Anyway, I'm launching this from a cafe in Shibuya, wracked with nerves, but glad to have finished it. :)
An iOS first strategy might be an impediment to achieving critical mass for an application that depends on network effects. I mean, everyone I know does not have an iPhone nor does everyone in my favorite coffee house.
Yeah, to be honest I did contemplate getting the android version ready before launching, but honestly felt like there's already so much chance involved in whether it gets to the critical mass required for it to really work that it made more sense, time-investment wise, to see how it goes on iOS first.
It also really depends on who you're targeting. In Australia for example, in my professional work we see much more iOS usage than android for equivalent apps, despite the market share numbers.
My random internet advice is to build a web version first because:
1. You're going to build a website for a mobile app anyway.
2. It is easier to iterate than anything that has a dependency on an app store.
3. It minimally works for everyone.
4. The users are your users, not Apple's or Google's. You can talk to them directly. You can update them directly. You can market your app to them directly.
5. When someone lands on your app's page, they can try it out immediately. No going to the app store. No reading reviews. No looking at competing apps. No dealing with iTunes. No waiting while it downloads. No looking for the icon. No nothing. Everyone of those points is a place where the pure gold of a person landing on your page can drop out of the funnel. When someone drops out of the funnel for an app, there's nothing to bring them back. For a brick and mortar store, the physical reality can. For an ecommerce site, a new transactional need can.
Regarding market use, a shop specializing in iOS is likely to land work where iOS use is prevalent because iOS use tends to correlate to market segmentation and company's serving a demographic more likely to own iPhones are more likely to hire professional iOS developers in particular and professional app developers in general.
Anyway, the reason that I'm giving feedback on your 'business model' rather than app function is because I don't want another damn app on my phone in general, and I don't own an iPhone in particular. So when I went to the web page, it took me five seconds to decide "Not for Me." It doesn't matter how many features get added or how much is spent on marketing, or how many users are near me, the app is useless because of a design decision about non-core
functionality. And by 'functionality' I also include functionality in terms of the business behind the app getting users and possibly making money.
Thanks, I really appreciate the feedback, and they're totally valid points.
I think you're right about the web app -- I've already built the "web-app" worldwide preview, meant to tease you into getting the app, but there's no reason that couldn't be a functioning version of the app, similar to how it is now, but with the localisation working as an option if users allow the location request.
I have a few ideas to slightly pivot if this doesn't really work, or take off the way it needs to succeed, and concentrating around the web app for Android users in the mean-time is a great idea.
To me, localization isn't a first order function. Just something Apple is in a position to demand of every app.
Sure there's a scale at which it probably matters for some apps. Other than choosing ASCII, it's hard to accumulate significantly more technical debt without it than by building it in the MVP...actually because sunk costs create inertia, there might be more technical debt building it in up front than leaving it out.
Or another way, IP address localization is the least effort that might possibly work. There are more corner cases, but the expectation of a web app in regard to location are lower than for an iOS app and if the rest of the system is good, users are likely to ignore it.
It dynamically created a message board for geolocations and anyone was free to post to it. It got a bit out of hand with spam and cyber-graffiti... Looks like the service is long gone (some random housecleaning blog is on the domain now). A big limitation to the app's usability was you had to be within a certain distance of a location to access the "chalk" for it.
It sounds like a cool service to try out, just not an iOS user...
I'm planning to write a blog post in the next few days about the development as my first foray into Elixir.
The idea for the app in general came from the fact that I'm working remotely from all over the place, doing the "digital nomad" thing, and thought something like this could be fun. But an app like this needs a critical mass to actually get off the ground and succeed, hence the dynamic growing and shrinking areas based on activity. The idea being it greatly increases the chance when you open up the app, you're there with someone else.
Anyway, I'm launching this from a cafe in Shibuya, wracked with nerves, but glad to have finished it. :)
Edit: I've also open-sourced the Swift Phoenix WebSockets client I wrote to build this here: https://github.com/sjrmanning/Birdsong