I was a heavy evernote user a few years ago and then migrated to OneNote. I think one of the challenges that is causing evernote users to drain off is as its organization model for notes is broken unless you are highly disciplined in using tags.
As your usage grows the product becomes worse for you for non-search navigation and discovery.
MS OneNote on the other hand feels like an upgrade from evernote in terms of its ability to provide a simple hierarchy for organising and navigating between notes and notebooks.
A key thing for any productivity tool is to balance between it being easy to adopt for new users and continue to improve its utility as usage grows over time. Very few companies have managed to do this effectively.
I'm struggling to understand the purpose of this compared to other collaboration platforms. Could you elaborate why this should matter to a team above and beyond other collab platforms out there?
This is such sage advice and almost never mentioned. As an entreprenuer who's obviously over optimistic about the startups probability for success and the speed that it occurs you usually skip and sacrifice a lot in life.
One thing I learnt the hard way is that the best way to ensure personal success is to plan your life's goals as if you have a 9-5 job with secure income. Major investments (housing, loans etc) and relationships should not be on hold till the next company milestone. Having a spouse kind of forces this upon you, but getting a supportive parent/mentor to help you plan your life apart from your startup will really help.
Platforms like Node become a necessity as you'd rather be faster to market and be more agile vs. being caught out building something that is useless in a nicely scalable platform over a longer period. Lean startups FTW.
Same applies for things like Meteor.js which are based on Node.
Lot's of people dabble in it but to truly know how to not screw it up when building something bigger it takes patience, experimentation and serious effort.
This is somewhat compensated by the speed of development you have with such platforms and is a tradeoff.
The key is to find customers first. If you have a hunch that something should work, there is always a possibility that you can uncover some pain points that you can build a business around.
You need to speak to enough customers and iterate on what you offer to figure out the validity.
Coding stuff up is always a lot more comfortable, and a no-touch approach like adwords based validation is 'easy', but really, you need to be in front of people to understand if there is any validity to your thinking.
Open ended conversations around the problem area usually results in great insight and can lead to some valid ideas you can work off of. Also, speak to more than one person in a given problem area and it's not too hard to ask 'do you know anyone else that has this kind of problem?' to find a common theme and get an idea of a market size thats worth your time.
I'm running a Meteor production app myself and found similar performance bottlenecks.
However, the Meteor community has really done some great work in solving some core issues and others are on the 1.0 roadmap.
Some comments on this below based on our own experience.
> 1. Collection synchronization does not really work even for relatively small amounts of data (say 10k records).
The issues around polling and how the server side cursors/observe works is definitely not perfect. Started using the SmartCollections package which ditches polling altogether and goes with the MongoDB OPLOG for synchonization. Has been performing well for us so far and solved many issues around performance.
>2. Minimongo is interesting concept, but fails on many levels:
Really depends on the usecase. I'am not sure if there is any other alternative to MiniMongo at the moment for other frameworks.
The key thing is you really shouldn't expect to do many MB's of client data storage in your app.
>3. Client-side is not as convenient as current MV* frameworks
The key issue here is the how the DOM is re-written with the current rendering engine.
The new 'Meteor UI' rendering engine and component architecture is promising to solve this issues with html element level reactive-rendering as well as an method for proper UI components delivering similar capability to what Angular offers.
---
The framework is still growing up, but we are hard pressed to find something that delivers similar developer productivity.
Once you understand the framework and IF it fits your needs, Meteor can work well for production.
Keeping customers inside the site is a priority for some (vs. pushing some discussions to say zendesk) and this fits in perfectly.
btw, may be make the 'try live demo' link a bit prominent and have a hint about how to close the fullscreen carousel on the homepage? had me confused there for a moment.
Do you have a 'no questions asked' refund policy? Do you still ask questions as of to why?
We do have such a policy, but we do ask 'why?' in a manner that aims to clarify and improve our service. A subset of the users are nice enough to explain and sometimes addressing that root cause cuts refund rates by about 25%.
Btw, would you mind sharing the points in your refund response email template? I would assume the effectiveness would depend on the nature of product, but it'll still be educational me thinks.
Nothing fancy really. Use the "Properties" panel to change signals of inputs. The UX can be better - bringing me to the point of purpose built apps. :)