02-07-2011 07:43 PM - edited 02-07-2011 07:44 PM
@John With all the other developers out there what are the chances that you will capture 10% of the market? High ambitions.
02-07-2011 07:55 PM
Ok, since we're being nit-picky, thats not true either - at least in USA. You can deduct expenses even if you have no income from that business, if you are operating as a pass-through entity (sole-prop, LLC or S-corp). These deductions 'pass through' the entity and go against your earned income (ie JOB income).
Just in case any Canadians try to read too much into that, I'm pretty sure it doesn't work that way here. You'd need revenue from the business side in order to claim it as an expense, period. It can't be applied against "job" income. Same disclaimer applies, etc..
Personally, I'm not much interested in IDEs. I always found myself getting too dependent on certain features, and was then entirely unable to function when I didn't have the tool, such as when I moved to a new platform, or tried to work from a non-usual location, etc. I now use a simple text editor (SciTE, and the only feature it has that I can't live without is automatic save-on-loss-of-focus), command line and, when needed, purpose-built tools generally written in Python.
To each his own...
02-07-2011 09:25 PM
I agree completely. Perhaps not so much for ActionScript at the moment since I am not that familiarized with the different packages/classes so well, if I were to use a simple Text Editor my code would be prone to mistakes and errors. (Import paths etc..)
02-08-2011 12:13 AM
I know it's been mentioned already (first reply) but I really find that FlashDevelop is the way to go, and with the fruitbat app and template provided it makes it a bit easier.
02-08-2011 06:31 AM
After I got that first reply I downloaded FlashDevelop. I will start using it once my trial is up but from the look of it, there is no reason not to use it. It fully supports the Blackberry Tablet SDK and provides support for multiple languages. The only thing it doesn't have (unless I have simply missed it) was a WYSIWYG for MXML. Even if that is the case I havn't been using MXML with Flash Builder anyway.
02-08-2011 08:45 AM
@noahnu: Market share deals with what share of a particular product category within the PB device. If you're the only one with an email client and it is good, then you will have a 100% market share for that product category. If 10% of the PB sold want an email client, then you have captured 10% of the users for your product. If you have competition, then the 100% will decrease accordingly. Since all the apps are "first to market", there is a very good chance that many of us will have a significant portion of the market for their application category. If you have an email client (for example), and BB comes out with their own email client, it is likely that your share will dramatically evaporate unless you can demonstrate better features and benefits over the strong contender. All this depends on how well BB/RIm will market the product, clearly define who their primary and secondary market is, and help ISV to bring their products to market in a fair and level playing field. A year from now, there will likely be many competing apps in the same product category. It is up to the ISV to maintain any competitive edge from new competitors that might enter their space.
02-08-2011 09:12 AM - edited 02-08-2011 09:14 AM
The thread seems get into price / market / cost ... etc discussion, I am not sure that I need to open a new thread to discuss such thing or not...
Anyway, below is my question:
I know that PlayBook is brand new device and there is no many applications (yet) compare to Android and iPad world.
So, there is many chances that developer (include me) will try to develop "almost" the same application that already existed on Android and iPad. Or, some developer may port their existing Android/iPad app to PB.
Now, the question is, how to price your app? Like John said the benefit is N * unit-price. But it is difficult to tell the "N".
At least, at the beginning, IMO, the N is lower for PB compare to Android and iPad.
And since the N is low, the unit-price needs to be higher to catch up.
But if the unit-price is higher, than user will think, for the same stuff, why I have to pay more to have it ?
( of course, the answer is, it is because you are using PB instead of Android Tablet / iPad )
Take a look on smart phone world, I found the "same rule" too:
The "almost same" app cost more on BlackBerry phone compare to iPhone / Android Phone.
This seems catch 22 for me. ( again, it is due to the unknown "N" )
What's your suggestion/opinion for unit-price ( higher or lower ) for the app that almost same on other world ?
02-08-2011 09:31 AM
You're getting into consumer price sensitivity. The consumer does not care about the number of units you need to get to cover your cost. Please dont do:
price = cost / N;
Because N has time associated to it. Is N units sold in the first month or the first year? So you ammortize how many units you want sold over some period of time. You do not want price to be a barrier to entry for your consumer. So it is best to price at a compariable level as compariable products are at on compariable devices (iPad,Android,etc.). You have to show some value to the consumer for what they are paying for. If you have half the number of features as a competing product or similar product on another device, it probably should not be twice their price.
I'm pricing competitive so it is a 'no brainer' for the consumer to purchase and elliminate any risk that they may have in their head to test or purchase your product. I'm counting on volume sales, vs. lower volume/higher price which have longer time to close on each purchase (consumer has to think about it. Thinking=delays or require approval, which decrease probablity of purchase).
You can always adjust pricing up if the demand is high. It is normal in a high volume market, for a company to change pricing and plot it to see what sensitivities exist (ellastic or inelastic). You have to ask yourself, if you are "joe consumer" how much are they willing to pay for your product. Ask friends and family how much they think the product would be priced at with features XYZ.
02-08-2011 11:39 AM
Aside from the tax implications, the point being made here is that the cost of the dev tools are expensive, which is usually only an issue when you don't have the funds to buy it.
I think I should point out that my suggestion not to bother using a proper IDE is based on more then just cost. Even when there are plenty of free options avalible (such as Java IDE's) I still prefer to code in notepad++ and compile form the command line. It is just a set up that I find simpler, and easier to manage...