I have a business idea which I want to materialize for sometime .. I recently shared my idea with 2 close friends who also found it very interesting, new and doable plus the cost included for the project to start is reasonable and they have planned to invest in it. Much of the success of this project app depends on the proper marketing element out of which most of the time, you have to personally meet up with clients/vendor and make them use your application.
The idea is to connect local ecommerce (retail shops, businesses, vendors, etc.) with users/customers through a messaging app mostly similar to whatsapp. I have already started to look for a xmpp/jabber developer who can accomplish our requirements. We are expecting him to develop the app and also set-up the server requirements. Our budget lies within $3000-4000 range for the project to initiate.
I want the app to have the following aspects:
a) user friendly GUI
b) highly scalable (planning to start within my city located in south asia)
c) location sharing (want users to navigate nearby shops/vendor offering their type of goods/services)
d) have a user review feedback against vendors and an additional page for vendor profile/rating system
e) only customer - vendor chats with functionalities like camera snaps, audio recording (just like whatsapp).
f) both for ios and android
Now the whole idea outlaid, after reading lots of articles, discussion and tutorials, I have some questions (I am a non-technical person btw):
1- I believe ejabberd is the best option as compared to tigase or prosody due to high scability. Is this ok to go with or should I look at other xmpp servers?
2- Currently, I am planning to launch this application within my city (rated as worldwide no.2 as per population stats of above 25m people), should I set-up a local server with high internet bandwith and a powerful machine or should I outsource it to some xmpp hosted server in the US (as their technological infrastructure has always provided quality service).
3- Should I be worried about the developer stealing the source code or is there any effective way to minimize this risk?
4- Any ideas what other things I am missing. This is dead serious for me and I am willing to do anything to get this project on the road.
(P.S.: The idea for this app is similar to the existing app called Lookup but I am planning to add some variations to it)
Thanks and sorry for being a bit lengthy ..
Regards,
Ahmed
ejabberd is indeed likely your best bet. However, be careful about the budget. To launch a quality service in an highly competitive area you have to have a significant budget, both development and marketing, if you expect your project to succeed.
Related
I'm going to be creating a few small mobile applications and have managed to find a great online Git repo hosting services that is free. It even comes with online issue tracking software but appears to be mainly geared towards the development team. I was hoping it would also have an interface for end-users to log issues/features and allow them to vote on what they wanted but it does not have this. It does expose an RESTful API but I didn't want to go down that path and wanted something ready to go (once configured).
I don't think I need it to be integrated with the Git repo so having something that is purely standalone would be great but I would definitely want something that is online as I don't want to install software on my local PC.
In summary, my requirements are:
Free or very cheap
Simple end-user interface to allow users
to submit issues/features
Allow end-users to vote on their own or other users issues/features
Visible status of issues/features (i.e. whether they are pending, in progress, rejected, fixed etc)
A more advanced management system for me as a developer to manage the
issues
Some basic reports/charts/graphing would be great
Email/RSS notification of new issues/suggestions would be great too
Something that is ready to go after some configuration/settings.
Can anyone recommend something that would be suitable for this?
TIA
I based my question on a website I saw a while back but couldn't find it. Anyway, I've now found it again (it's called http://www.uservoice.com/). It's not really issue tracking but more of a way of letting end-users report features and allow them to vote on them. The important thing is that it is a very user friendly interface which is perfect for end-users. Obviously, I would then need to maintain issues/features in my own system (e.g. Mantis) and then manually sync features requested in uservoice to Mantis but that shouldn't be a big issue. Anyway, this perfectly meets my needs for my low volume applications at the moment.
I'm developing an iOS social networking application that will involve users sharing and rating photos. I've spent about the last year or so on and off teaching myself how to develop in cocoa touch and now I'm ready to get started with the networking aspect of the app. Unfortunately, I have 0 networking / database experience and was wondering if anyone had any good advice on what things to consider and where / how to get started. In all likelihood I'm probably not going to build my own server and instead will go with something like rack space. Any advice would be appreciated.
Getting started to iOS Networking application. Here are the required things:-
You really need good backend developing experience in MySQL and complex database queries Plus experience in developing web services. At the root you need server host for backend and Admin module as you mentioned in question like race space or any other. You need to spend some months with mysql backend,web service and admin module implementation.
For fully functional social networking app your first task will be to manage users. Log in/Sign up will be there. Every user can post his status and can comment to other user's status.All status posts or comments will have their unique id and relationships to userid's table. May be image uploading and comments on photo will also be there So there will be lots of tables and relationships between them on backend side.
For Social Networking app, amount of work will be bigger on both backend/web service side and iOS side.
This is a pretty abstract question.
Eventually, you're going to have to focus on a particular architecture ( which database, which network technology), but before you do that, you need to get an outline idea of what the available options are and what the strengths and weaknesses of each are.
The server database is probably the easiest, as it doesn't make such a big difference. The choices are an sql database ( mysql, sqllite ....), not an sql database ( nosql, in memory tables) or some higher level abstraction where you can hide the differences and decide later ( core data for example). This may be constrained by your deployment decisions, you'll have more choices of rack options if you go for LAMP (Linux, Apache, MySql, PHP) for example. If you stick with apple kit and use a MacOS X back end, you may have additional options for network architecture ( DistributedObjects for instance.
The network architecture is also a difficult choice from a wide range of choices. There are really dozens of options with lots of different pros and cons. As this is your first foray into this area, I'd count ease of use and availability of help high among your priorities. Here are a few popular technologies you might want to investigate ( in alphabetical order to minimise flammability :) ). DistributedObjects ( apple), JAXP, JSON, RPC, SOAP, XML ( bare, without the soapy bits).
One more question you should ask yourself is "Can you get away with just a database connection, or do you need to do processing on the back end?". If you can, you might be able to get away with just using a remote database and then you only need to learn core data ( which will still keep you busy for a long time).
Once you've decided what technologies you want to use, then you can start learning.
You mentioned using a hosted server. You'll want to be able to run a test server locally. Fortunately almost all the worthwhile options for both database and network technology will run on any unix-like machine, so you can probably use your regular dev machine.
Also bear in mind that some of these choices are religious, so everyone you read will have strong biases ( myself definitely included).
is it possible to let my own facebook apps (not generating revenue) being hosted by facebook?
The problem is that by using the iframe-version the traffic/requests are killing the server :-(
But I need to connect to a database and print/calculate values, so I think there is no other way than hosting everything on own servers. But maybe there are things I don't know.
What is the way you would go?
I don't think Facebook has an option to host apps, at least not that I've ever heard of or was quickly able to find on their developers site.
Honestly, when it comes to hosting a high-demand website, there's no free way to do it. Resources cost money. You can pick from tons of hosting providers and see who gives you the features you need at the best rate. Maybe some will offer free hosting if you include ads in the Facebook app, maybe some will offer free hosting for other means, etc.
For a non-revenue-generating app, when it becomes popular and successful and requires real resources to keep it running, it's generally time to start thinking about how to generate revenue from it. Maybe use it as a free gateway app to other revenue-generating apps (a loss leader), maybe have ads, maybe use it to generate useful marketing data, etc. For a successful site it may involve a good bit of personal investment and risk before the profits roll in (Facebook being a good, though extreme and uncommon example of this).
You have to host the application on your own, there's no way that FB does it for you.
What is the most typical structure of business where you want to develop several web services? Should one establish a company for each of them or keep under one? I would like to hear your experiences maintaining such situation, keeping in mind the global focus.
By far the two most critical sets of issues determining the answer to this question are legal and financial (including, but not mainly, accounting). So it's hard to see how this question fits with the intent of this site.
It is advised to provide more background information on the topic. Business plans for SaaS companies can range from large cloud computing service vendors (with integrated solutions) and up to business analytics providers targeting specific market niche.
Business is a bit like programming: Keep It Simple (Stupid). Do not create multiple companies, unless there is a good reason to do it.
If You Planning to use python, you can use Django to build saas application,
this video Build SaaS application in Python django will explain about getting started with Sass.
Thanks
Most of the work I do is with what could be considered enterprise Web applications. These projects have large budgets, longer timelines (from 3-12 months), and heavy customizations. Because as developers we have been touting the idea of the Web as the next desktop OS, customers are coming to expect the software running on this "new OS" to react the same as on the desktop. That includes easy to manage automatic upgrades. In other words, "An update is available. Do you want to upgrade?" Is this even a realistic expectation? Can anyone speak from experience on trying to implement this feature?
At my company we have enterprise installations ranging into the thousands of seats. If we implemented an auto-upgrade, our customers would mutiny!
Large installations have peculiar issues that don't apply to small ones. For example, with 2000 users (not all of whom are, let us say, the most sophisticated of tool users), tool-training is a big deal: training time, internal demos, internal process documents, etc.. They cannot unleash a new feature or UI change without a chance to understand how it fits in their process and therefore what their internal best practices are and how to communicate that to their users.
Also when applications fail, it's the internal IT team who are responsible. Therefore, they want time to install a new version in a test area, beat it up, and deploy on a Saturday only when they're good and ready.
I can see the value in making minor patches more easy to install, particularly when the patch is just for a bug-fix and not for anything that would require retraining, and if the admins still get final say over when it's installed. But even then, I don't believe anyone has ever asked for this! Whether because they don't want it or they are trained to not expect it, it doesn't seem worth it.
Well, it really depends on your business model but for a lot of applications the SaaS model can end up biting you. It's great for a lot of things but for some larger applications the users are not investing as significant amount up front and could possibly move to something else before you've made any money.
See
http://news.zdnet.com/2424-9595_22-218408.html
and here
http://www.25hoursaday.com/weblog/2008/07/21/SoftwareAsAServiceWhenYourBusinessModelBecomesAParadox.aspx
for more information
One of the primary reasons to implement an application as a web application is that you get automatic upgrades for free. Why would users be getting prompted for upgrades on a web app?
For Windows applications, the "update is available, do you want to upgrade?" functionality is provided by Microsoft using ClickOnce, which I have used in an enterprise environment successfully -- there are a few gotchas but for the most part it is a good way to manage automatic deployment and upgrade of Windows apps.
For mobile apps, you can also implement auto-upgrades, although it is a little trickier.
In any case, to answer your question in a broad sense, I don't know if it is expected that all enterprise apps should make upgrading easy, but it certainly is worth the money from an IT support standpoint to architect them to allow for easy upgrading.
If you're providing a hosted solution, I wouldn't bother. Let the upgrade happen silently (perhaps with a notice that you did it). If you're selling an application that's hosted on their servers, let the upgrade decision be made by a single owner, not every user of the app.