views:

289

answers:

8

I believe that In the past the decision as to how to deploy your application was largely a technology / architecture problem. How must I implement my code to best solve the technical problem at hand?

Now I believe it is much more of a market decision. How can I reach the biggest market? What type of software do people now pay for?

This market for software spans laptops, desktops, mobile phones, multiple OSs and more...

So my question is how has your new startup, or existing small company, or hobbie project that you really want to commercialize chosen to deploy itself? Is it a web based service, a standalone application or is it targeting smart phones?

A: 

it depends on the kind of commitment you want/expect from your users.

if you want them to buy a service/application and then use it, an installable application can be seen as 'more professional'; while a web service can be 'more convenient'.

if you want to attract users on a whim, any step they have to take to use your service is a step away from you. therefore, it's almost mandatory to use a web app. even requiring any plugin, or not testing it on most browsers would diminish considerably your audience.

Javier
A: 

Should you not add applications that are installed on a phone to the list? With a higher penetration of smartphones such as the iPhone, Blackberry, Android phones, etc, I think that the next big wave is going to be smartphone development (probably backed by web services) and that is where I am looking to the future.

The ability to combine GPS, communications, cameras, etc in a mobile device opens up some amazing opportunities. I think we are really only limited by our imaginations now.

Rob Prouse
I've made the phone choice more explicit - i had hinted at it before but Itake your point
morechilli
A: 

I'm developing a mobile app, which will work with local offline storage which will sync when online to a web service backend.

Tony

Tony Lambert
+6  A: 

The trouble with the web is everyone expects everything to be free.

People quite happily pay $2.00 to doanlaod a thirty second joke ring tone on a phone, but, object to paying $10.00 to download a real album by a real musician.

Its not rational or logical, but, thats the way it is.

James Anderson
+2  A: 

We have written a locally installed app. Because:

  • We store some sensitive information, that some of our clients don't want out of their company environment
  • It is possible to host a web app on the Intranet, but we are small, and then we need to deal with the IT department of a large company. There are so many different Web platforms, that almost every platform you choose will be unknown to the local IT department. Unknown stuff will even create more resistance to our app, since the IT department does not use it theirselves.
  • It is much more easy to deploy a client app, inside a large company, with a central DB for the storage, than to host a server with a unknown platform.
  • You can always host your client app on a Terminal- or Citrix server, and deploy it that way over the Internet
  • Clients pay for installed software
GvS
A: 

When I consider implementing an idea, I tend to make that decision based on "where would I expect to use the app?"

  • If it's a mashup/extension to an existing web app, it's obviously a no-brainer. Same goes for the sort of applications that need Internet/web connectivity 24/7. As long as you can solve the data security issues if you are indeed holding user data, this would shout web app to me.
  • Something that you might want to use on a computer but irrespective of your Internet connectivity (ie it doesn't need any, or only sporadic one) should be implemented as a stand-alone app
  • Of course those very useful apps that you might want to carry 24/7, don't really need constant Internet connectivity but also shouldn't require you to lug around a laptop, well, they go on a smartphone

IOW, work out what you want to do and implement it in the way it makes most sense to a potential user. You don't necessarily want to have to incur connection charges to view your shopping list when you're at the mall, because it happens to be implemented as a web service.

Oh, and being able to keep your fingers in multiple pies also has the advantage that you'll find it easier to find consulting work to tide you over, if necessary.

Timo Geusch
+7  A: 

I belive that you were right in the past, and are now mistaken - deployment architecture very strongly depends on what problem will the software solve!

If your software is going to solve the problem of "portable to-do lists with reminders" then all three may be appropriate.

If your software is going to solve the problem of corporate resource allocations based on stochastic scheduling of enterprise services (whatever that is!) then a server app may be appropriate, or a web app, or both.

If your software is going to reorganize desktop icons and replace them with animated GIFs of fish in an aquarium, a web app will probably not be a good solution. But it might be a good delivery vehicle!

If you're talking about marketing and access to information, then all three are appropriate if not required. But there are still significant technical/architectural differences between web apps, desktop/server apps, and smart-phone apps.

Choose wisely!

Steven A. Lowe
Pretty much what I was going to say, we develop 'solutions' using whatever provides what the customer needs
Patrick
To be honest my own answer would probably have said something very similar - what you say makes good sense - however I'm interested in probing to see what range of opinions people come back with.
morechilli
A: 

Web application. It's the largest audience (compared to smartphones), the easiest delivery media (compared to installable app) and the lowest or none hardware costs (compared to smartphones).

User