4 ms·

Your barrier in gaining popularity once you launch is going to be cross-platform support. It sounds like you started wholly with Android, with other platforms c

Your barrier in gaining popularity once you launch is going to be cross-platform support. It sounds like you started wholly with Android, with other platforms coming further down the pipeline. These days a product that does not have apps for at least Windows, Android, iOS, and OS X severely limits its customer base. Android essentially represents only a subset of phones and tablets. An app like yours is useless to many people unless it has desktop equivalents, as mobile-only access heavily restricts a user's ability to be productive where and when they need it. I might be an edge case, but I use Windows, OS X, an iPhone, and an Android tablet. Your app could be the most functional and usable todo app out there, but a competing product with 10% of your features is going to wind up being my choice simply because I get to use it across all my workflows. Platform support beats out the quality of the app, every time. Based on your screenshots, the app is wonderful. I simply suspect you have focused too much on launching a 100% complete product instead of starting with an MVP. Obsessing over having a perfect product that launches too late to market, while your competition launches early and takes your cake, is all too common a scenario.

VladimirGolovin 9y ago
Yes, we started on Android, because that's the most efficient way for me to dogfood the app. Another reason why we didn't start developing for more platforms in parallel is that the concept was unproven. I wasn't sure it would work. (Under "the concept" I mostly mean the approach where all non-snoozed or dateless tasks are shown in Today, and you swipe away the tasks that are not yet "ripe" to be done -- whereas in traditional apps you do the reverse - you select tasks to do by starring them during a review). Now that I found out that the concept clearly works well at least for one user (me), the next step would be to validate the concept on a wider group of users. An Android-only soft-launch, or even a closed beta should be enough for that. And if the concept is valid, we'll definitely develop for other platforms, the ones you mentioned. iOS and Android clients will be native, and the desktop apps (Windows and macOS) will probably use some cross-platform technology. And thank you for the kind words :)
- developer2 9y ago
  First of all, clearly the advice I'm giving is a bit too early for where you are at presently. I think that's giving credit to you for the quality of the work you are producing. Basically, I want this app. You might want to dial back just a tad on the intricate details, out of fear you may wind up never shipping an initial version. Being a software dev myself, I understand that you could spend another year (hell, even 2-3 years) completely hashing out every minute detail. However I think that what you have is getting to the point of being "above and beyond what is necessary" that you need to stop tinkering so much, and find a way to ship something sooner rather than later. When you get around to desktop clients, ignore the seemingly negative consensus regarding Electron[1] if you think it's the right fit for you. All the negativity I've read about it is from "purists" who aren't specifically singling out Electron; rather they are hating on all non-native implementations. I noticed the mention of Xamarin on your site; never heard of it, but I'd be weary as they seem to be oriented more towards mobile whereas you're looking for a cross-platform desktop solution which is where Electron shines. If your goal were to be the gold standard for apps, you should be developing using native OS X APIs; the performance you get from a native implementation on OS X is astounding. However, if you do native OS X you're putting yourself in a position to do native Windows and possibly Linux apps, and the collective work required for native-everywhere obviously does not come easy or cheap - particularly if you are doing this as a solo project without assistance from a team. Electron is a perfectly fine balance for most UIs that are fairly simplistic, which is going to be true even for the most advanced todo-type app. Extra bonus being that if you put in the effort to plan out the Electron app side-by-side with your web/browser-based app, you can share the frontend development between the two, resulting in less overall work. [1] https://electron.atom.io/ https://electron.atom.io/
  - VladimirGolovin 9y ago
    Being a software dev myself, I understand that you could spend another year (hell, even 2-3 years) completely hashing out every minute detail. I won't do that :) I stopped working on the spec the moment I handed it down to coders, and my total time spent on the spec since then is around one week. When the spec is written well, and you simulated all important situations in your head before encountering them in the wild, you actually don't need much extra time. There's almost no tinkering happens on the app right now. I'm fixing critical bugs and smoothing out rough details that manifested after months of my dogfooding. Regarding the desktop solutions: yes, going native would be perfect, but that is not feasible for a 4-man team. We'll go with Electron or Xamarin or, less likely, Qt - we haven't decided on the exact technology yet.

VladimirGolovin 9y ago

Yes, we started on Android, because that's the most efficient way for me to dogfood the app. Another reason why we didn't start developing for more platforms in parallel is that the concept was unproven. I wasn't sure it would work. (Under "the concept" I mostly mean the approach where all non-snoozed or dateless tasks are shown in Today, and you swipe away the tasks that are not yet "ripe" to be done -- whereas in traditional apps you do the reverse - you select tasks to do by starring them during a review). Now that I found out that the concept clearly works well at least for one user (me), the next step would be to validate the concept on a wider group of users. An Android-only soft-launch, or even a closed beta should be enough for that. And if the concept is valid, we'll definitely develop for other platforms, the ones you mentioned. iOS and Android clients will be native, and the desktop apps (Windows and macOS) will probably use some cross-platform technology. And thank you for the kind words :)

developer2 9y ago
First of all, clearly the advice I'm giving is a bit too early for where you are at presently. I think that's giving credit to you for the quality of the work you are producing. Basically, I want this app. You might want to dial back just a tad on the intricate details, out of fear you may wind up never shipping an initial version. Being a software dev myself, I understand that you could spend another year (hell, even 2-3 years) completely hashing out every minute detail. However I think that what you have is getting to the point of being "above and beyond what is necessary" that you need to stop tinkering so much, and find a way to ship something sooner rather than later. When you get around to desktop clients, ignore the seemingly negative consensus regarding Electron[1] if you think it's the right fit for you. All the negativity I've read about it is from "purists" who aren't specifically singling out Electron; rather they are hating on all non-native implementations. I noticed the mention of Xamarin on your site; never heard of it, but I'd be weary as they seem to be oriented more towards mobile whereas you're looking for a cross-platform desktop solution which is where Electron shines. If your goal were to be the gold standard for apps, you should be developing using native OS X APIs; the performance you get from a native implementation on OS X is astounding. However, if you do native OS X you're putting yourself in a position to do native Windows and possibly Linux apps, and the collective work required for native-everywhere obviously does not come easy or cheap - particularly if you are doing this as a solo project without assistance from a team. Electron is a perfectly fine balance for most UIs that are fairly simplistic, which is going to be true even for the most advanced todo-type app. Extra bonus being that if you put in the effort to plan out the Electron app side-by-side with your web/browser-based app, you can share the frontend development between the two, resulting in less overall work. [1] https://electron.atom.io/ https://electron.atom.io/
- VladimirGolovin 9y ago
  Being a software dev myself, I understand that you could spend another year (hell, even 2-3 years) completely hashing out every minute detail. I won't do that :) I stopped working on the spec the moment I handed it down to coders, and my total time spent on the spec since then is around one week. When the spec is written well, and you simulated all important situations in your head before encountering them in the wild, you actually don't need much extra time. There's almost no tinkering happens on the app right now. I'm fixing critical bugs and smoothing out rough details that manifested after months of my dogfooding. Regarding the desktop solutions: yes, going native would be perfect, but that is not feasible for a 4-man team. We'll go with Electron or Xamarin or, less likely, Qt - we haven't decided on the exact technology yet.