Agreed - I feel that as we have more filters, customisable searches, auto-folder moving and so-on then we're actually creating a big headache of curation, categorisation and taxonomy-creation for the end recipient.
What would be great IMO is for some of this to happen a little bit more automatically with the option for me to give the system feedback as to how well it did with it's filtering attempts. This would allow me to, over time, state my intentions (e.g. I really only want to be bothered with REAL problems) rather than implement the mechanisms to do so. I often feel I work for the machine - not the other way round.
>No, since the business objective is to make money. The
>software is the means to do that, and the choices you make >today limit the markets that you can expand into.
I guess then it's a question of the benefit of taking a tactical advantage vs. the opportunity cost of that decision (including the subsequent re-write)?
I would say that the risk of limiting future markets (or more specifically a prohibitive cost of entry into said markets) is only one of many risks that need to be considered in the decision making process.
Surely there are downsides to the inevitable re-invention of what a framework does if you roll-your-own? It's not a one-way bet.
The software choices we make also enable options whilst at the same time limit others - it's a trade off.
>If you decide that you're making a mobile app for android,
>then you are going to have to do a bunch of work (possibly
>including re-implementing the app) to get into the iphone
>or desktop market.
That's an interesting case (one I find myself peering at currently). Isn't the only real option to suck-up the fact that you'll need 3 versions on 3 platforms - or - build a product in a market that doesn't have diversity of platform as an issue (such as a browser-delivered app)? [That could be an argument against native apps on devices.]
How do you reconcile the need to move fast initially to release a product or service in order to build the market for it from a business perspective?
Does having to 'build your own framework' (my paraphrasing of your point) typically mean your software delivery is slower?
Is this detrimental to the business objective you're trying to achieve?
Does a 2-fold approach work - using a more substantial framework to begin with (for speed) followed by re-factoring into your own more specialised "framework of libraries" later?
Definitely some food for thought in your point - I presume it's based on actual experience of programming under both regimes?
Hi, I like the ability to rapidly get started and quickly share (far better than Remember The Milk on that point).
There are other apps/services in competition but that is ok - proves there is some semblance of a market out there.
I'd say you should get it infront of as many potential customers as possible ASAP so you can move from hypothesizing about customers to having validated learning about them.
You're right to release early - you need to start qualifying WHO will pay and how MUCH pretty soon (if you wish to turn this into a profitable business).
Your unique selling point may well be the speed/ease of use and ease of sharing. I'd pay at least £1 per month for that.
What would be great IMO is for some of this to happen a little bit more automatically with the option for me to give the system feedback as to how well it did with it's filtering attempts. This would allow me to, over time, state my intentions (e.g. I really only want to be bothered with REAL problems) rather than implement the mechanisms to do so. I often feel I work for the machine - not the other way round.