Graham wrote: » Sorry ideaburst, my last post wasn't directed at you.
The Corinthian wrote: » I'm going to comment on some of the points made in this thread to date. To begin with there appear to be a few misconceptions from a technical point of view here. A dotNet back-end and PHP front-end makes no sense, as PHP is actually a back-end technology, while the front-end would denote the UI and unless you're going to compile PHP into an executable client, it's going to have to sit on a server. Also someone mentioned 'push' without needing to poll the server - it doesn't exist. All 'push' solutions there actually periodically poll a server, it's how TCP/IP works, I'm afraid, and all they're doing is managing this part of the process without you having to know anything about it. Especially as you want to plan for multiple chat applications having access to the same system, you're better off thinking of it in terms of client and server. This means that you'll have one server solution that acts as a relay or clearing house for all chats and identities, while you can have as many different clients (the chat application itself) in as many forms, on as many OS's as you like. The 'glue' between them will be an API, which you (or your development team) will develop - essentially a method and syntax in which client and server will be able to communicate over the Internet. And at a very top level, and before we get into trying to be clever and using server clusters or P2P or whatever, that's all there is to what you want to build. Prototypes can be pretty cheap to produce; they have to be as often they are used in the design process when interfacing with stakeholders, rather than relying on documentation. However, you will need to adjust your expectations on what a prototype is and what it's for. It is not a 'basic or alpha version' that you can build up from once you have more money. It is instead a proof of concept, sometimes employing nothing more than smoke and mirrors (e.g. using static rather than dynamic content) that is means as a tool in the design process and/or when seeking investment. Once it's served it's purpose, all that you'll retain from it are whatever design lessons you've learned. Approach a prototype like this and it should be relatively cheap and easy to get produced. Make the mistake of expecting the prototype to be an alpha version of your final solution and you'll be putting yourself through a World of pain and added expense in the long run. I'd have to agree that hybrid reduced fee / sweat equity deals will be taken seriously by serious developers. Nonetheless, the moment you include sweat equity, is the moment that you have to stop thinking about the relationship being one of you as the client and they as the supplier, as you will have to sell your business to them for them to accept the deal. Most important in this regard is that you've shown yourself to have done your homework - market research, revenue models (incl. verticals), believable projections (you get a lot of voodoo analysis out there) and funding. If you can't supply what is effectively going to be your business partner with those, then they're not going to take you seriously; no one is. Finally, as has been said, if off-shoring you want to have a very detailed technical specification done, not a functional specification. If you're unsure about the difference, then you shouldn't be writing it. For even a simple chat app, this is not going to be four pages long, but will likely be ten times that. For a simple app. Also with off-shoring, you'll preferably want to have both specific project management and development experience. It is very important to have someone like that on your side of the Skype window who can sanity check, spot misunderstandings (before they end up being developed) and, importantly, see through the bullshìt that many off-shore outfits in countries like India, Pakistan or pretty much everywhere, will feed you with. This is not to say they're all like this, but you should be aware that many are and unless you have prior experience of an outfit, you run the risk of hiring one who can talk the talk, but in reality either lack the skills and resources or make a living on intentionally maximizing billable hours at the client's expense. Anyhow, that's my 2c - hope it helps.
ideaburst wrote: » Cheers Corinthian, very detailed post. This is no longer a chat application though, as I said in my second-last post. It's going to be Twitter effectively, with a custom design. It won't be a clone, but will carry most of the same functionality, with lots more features planned as it scales up.
On revenue models, I agree in principle, but with tech start-ups you also have to factor in the fact that a lot of the time it is finger in the air stuff (necessarily), as with certain products it is almost entirely dependent on gaining traction and user numbers starting out. This is firmly going to be a network, as opposed to a subscription based model, or similar.
The Corinthian wrote: » Technically speaking, it's still same client-server model as I gave above. I'm well aware that it is very commonplace that the business model of an IT enterprise will morph into something that no longer resembles the model you started with. I've seen it happen lots of times as companies see the original model fail, but luckily stumble upon one that turns out to be profitable. Most are not so lucky and fail. However, if you've not already got an idea of what to expect where it comes to gaining traction or user numbers and projected growth, then you've not done your homework. Approaching things, this early on, in a cavalier 'finger in the air' fashion is essentially the old 'if we build it they will come', and I assure you, they won't. I cannot underline enough how important it is to do your homework on the business model at this stage; reading case studies and figures from other enterprises, looking at advertising CPA's and seeing how different demographics behave; then making realistic* projections (pessimistic for you and separate optimistic ones for any potential investors) on how they'll play out for you. As the principle of the enterprise, who's looking for a technical partner, this is your responsibility. Without this, all you are really bringing to the table is an idea, and that will neither impress any serious future partners, nor bode well for your enterprise's survival.* I've seen business plans that have clearly looked at only one case study or just made up a few figures, then project growth in such a way that if continued a few more years would imply that the customer base would be greater than the population of the planet. None even remotely hit the figures they claimed they would achieve.
ideaburst wrote: » It's going to be Twitter effectively, with a custom design. It won't be a clone, but will carry most of the same functionality, with lots more features planned as it scales up.
stevenmu wrote: » The functionality you are describing is commonly known as "micro blogging". If you search for things like "micro blogging software", "microblogging software open source", "microblogging software cms" etc you will find some of the software that's already out there. With a bit of research you might find some that meet, or are close to, your needs, which would be a big help in building a prototype quickly and cheaply. If nothing else, looking at the available solutions will help you to crystalise your own requirements.
ideaburst wrote: » As for convincing a technical partner, I am actually not looking for one as much as I am looking to speak to one from the point of view of paying them to build the application at the lowest cost possible in an x + y = product delivered as per initial brief (i.e. our developer says we need 'x', 'x' fulfills the brief at the lowest possible cost - and 'y' is the rate we pay them to build it).
The Corinthian wrote: » Well, you are at the end of the day. You suggested a hybrid payment model to remunerate a potential technical resource, and so the moment you pay in equity, even if the person getting that sweat equity will have a non-executive role in the enterprise, is the moment you effectively make someone your partner rather than a supplier or employee. When, as a developer, you get paid a fee or rate, then your remuneration is associated only with what you need to deliver and/or the time and materials involved in that delivery. It's not unusual for a developer to get a paid gig that they can see a mile off will fail, but that's not their problem, as they'll get paid either way. With equity, you have a stake in seeing the value of the enterprise succeed and to only invest your time in an enterprise that is likely to succeed. Some or all of their payment becomes dependant on that. Just like an executive partner. This is why I said in my first reply that the moment that equity comes into the picture you have to throw the client-supplier paradigm out the window. As such, the greater the confidence you can instil in a potential technical resource you plan to pay, at least in part, with equity, the better the price you'll end up paying; 1% of a well researched, solid business is worth a lot more than 50% of something that could have been cobbled together after an hour's worth of Googling and mucking around on Excel for a bit. And you'll be surprised how that can be easy to spot. And that's all I'm really trying to impart.
doopa wrote: » Exactly - have a play with identi.ca (pump.io) and see if it can be skinned to meet your needs. The project looks abandoned. wave - from google is also potentially interesting. Unfortunately its depreciated now. But worth looking at who and why other people took on aspects of the micro-blogging/chat interface/api: http://en.wikipedia.org/wiki/Apache_Wave
ideaburst wrote: » Cheers, going to look more closely at the micro-blogging software alright. I actually mentioned identi.ca / pump.io earlier in the thread (it's a lengthy thread now though ). We did the same Google search!
doopa wrote: » I've used identica before and set up my own pod or whatever they are called now. Its pretty easy to get going but since it largely just replicates twitter its not clear what the point is (unless you are really into free culture). So it wasn't a google search that I performed in response to your query!
doopa wrote: » Another one worth looking at is LINE from Naverline. Its massive in far east and has a lot of chat functionality, video, phone, status updates etc. Its available on most phones, desktop OS's but has no market penetrance in the West.
ideaburst wrote: » Oh right, I see! Since you set it up before, can you say whether it is quite easy to customise? I presume so, but since we are looking to add in other elements (nothing major at all in fact), it's important. Cool, thanks. Just checked that out there - can it actually be used as an open-source application? Looks good anyway.
Colonel Panic wrote: » Do you have a prototype?
The Corinthian wrote: » Also someone mentioned 'push' without needing to poll the server - it doesn't exist. All 'push' solutions there actually periodically poll a server, it's how TCP/IP works, I'm afraid, and all they're doing is managing this part of the process without you having to know anything about it.
counterpointaud wrote: » I don't think this is correct, doesn't SignalR maintain a socket connection from server to client in order to call functions on the client when necessary? Correct me if I'm wrong, I know it falls back on polling when sockets are not supported.
The Corinthian wrote: » Still, the thought of keeping socket connections to multiple clients open indefinitely, just fills me with dread...
ideaburst wrote: » We have just seen that the exact app we are looking to build is in existence, having only been launched a few months back by the looks of it. This is validation for the concept for us really, we see it as a good thing, especially as the market for it is so vast.
We are looking at all options now, even the possibility of crowdfunding. I know there are lots of crowdfunding sites out there, but if anyone has any feedback on this avenue would be good to hear your thoughts?
The Corinthian wrote: » Well, if the idea isn't original, you might as well tell us what it is at this stage. The following article would be typical of what I've heard of people's experiences of crowdfunding:http://www.bbc.co.uk/news/business-25403081
ChRoMe wrote: » The demographics of kickstarter are really important to understand. Its typically male geeks between the ages of 25-40 with high disposable income. This is the reason that nostalgic gaming projects are by far the most successful.
howamidifferent wrote: » Sounds like Skype... :P
ideaburst wrote: » This would be a way to make new connections, discover those you might already know if your new location, and also seek information / tips on your location. After all, if you're Irish and abroad, who do you want to hear from more than other Irish people in the same boat?
The Corinthian wrote: » Actually, sounds pretty much like Meetup.com.
The Corinthian wrote: » Not really. It's nice when you come across other Irishmen and women, but there's simply not enough of us in many countries and so will mix with other Anglophones just as easily. It works more on the basis language than nationality, TBH; even for other nationalities. Personally, I avoid other Anglophones, for the most part.
The Corinthian wrote: » Anyhow, all of these things tend to be based on existing Web-based communities, using mobile simply as another means to access the community. So an app-only approach may not be the best, if that's the plan.
