7 ms·
I'm going to throw this one back at you: > "I'm sick of waiting for Google's Keep team to improve their app, or even to respond to feature requests. (Crickets.
by wtmt 8y ago
I'm going to throw this one back at you:
> "I'm sick of waiting for Google's Keep team to improve their app, or even to respond to feature requests. (Crickets.)"
Choose a stack that:
a. has many developers using it on GitHub (since that happens to be the most popular platform for hosting open source code)
AND
b. is easier to use or fork as well.
Life will take over at some point after you develop some version of a Keep alternative. It may be the same as Keep today or lacking a lot comparatively or better than it. In any case, you'd need something that others can contribute to (sending pull requests), fork and create different/better versions of, etc. If you go with some relatively obscure stack or a dying stack because it promises to be fun or promises that you'll learn something new or promises something very fancy, then you'd either not get many users for your application or would have people in the future screaming the same sentence you started with above.
In other words, try not to do to others what you imagine the Google Keep team has done to you (or not done for you)!
- sitkack 8y agoI second this. Build abstraction ladders. Built platforms, and build it such that you don't have to build everything, something users can extend to meet their own needs. Application developers need to open their platforms. Had Keep made their application open and layered, your new features would be locked behind the Keep gate.