Looking for a starting point for building a 'chat' application

ideaburst

Graham wrote: »

Sorry ideaburst, my last post wasn't directed at you.

Oh no, I didn't think that. I knew you were talking generally

The Corinthian

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

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.

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

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.

Technically speaking, it's still same client-server model as I gave above.

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.

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

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.

Yes agreed, however I am not saying we are going to be putting a 'finger in the air', only that this is frequently the way it is done - regardless of how 'official' or 'researched' the figures might look.

We are doing our research for sure, we have a meeting next week and already have a presentation with a variety of stats on the market opportunity as it stands. We need to do some work on projections though, those will be very approximate, but thanks for the reminder on that.

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).

I think I would rather find someone I am happy and keen to work with and pay them to build the application, than take on another partner (there are two of us already). Pros and cons to both of course, and we will be looking at all options.

stevenmu

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.

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.

doopa

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.

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

The Corinthian

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).

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.

ideaburst

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.

Yep, I know what you're driving at alright. I know I mentioned the hybrid model, we will have to see what way it is going to develop. One thing I do know though is that any revenue projections are going to be very approximate.

We are not going to be building something where you can say 'ok well we're going to have a core product which we will offer at $49/month, and we envisage a 5% conversion rate based on prospects targeted', etc. It is going to be much more like 'this is how many people who fall into our target market, this is how much we project this market will grow over x months / years, etc'.

Some reasonable projections are better than none in any case!

ideaburst

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.

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

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

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!

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!

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

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!

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.

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.

Cool, thanks. Just checked that out there - can it actually be used as an open-source application? Looks good anyway.

doopa

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.

I haven't looked at the code so can't comment on customisation.

Line is not open source. Just pointing it out as it has some neat features that are not present in other apps.

ideaburst

Hi guys,

So fast forward a couple of months and this project is still very much alive. We have realised a couple of things:

-We will need a custom, bespoke website solution and a provider with the required expertise and experience to deliver it.

-We have had a positive reception to the idea from different people, including those who would see a lot of ideas.

A very cool name has also been agreed on!

We have also been invited to pitch for acceptance onto an accelerator programme in the New Year. While we know that our idea is solid and has a very real and very, very large market, obviously nothing is guaranteed and so I am posting to invite any experienced developers to contact me if they would consider a reduced fee + % equity arrangement.

I also welcome any further feedback, questions or comments

Colonel Panic

Do you have a prototype?

ideaburst

Colonel Panic wrote: »

Do you have a prototype?

No prototype, not as of yet anyway and the plan is really to build a fully-fledged solution which 'looks the part', as we believe this is what is needed in order to get people signing up.

counterpointaud

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.

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

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.

You could well be right and what I wrote might well be totally out of date.

SignalR seems to be based on WebSocket in HTML5, which does appear to fit the bill of being a real implementation of push, rather than a polling based solution.

Still, the thought of keeping socket connections to multiple clients open indefinitely, just fills me with dread...

Procasinator

The Corinthian wrote: »

Still, the thought of keeping socket connections to multiple clients open indefinitely, just fills me with dread...

I suppose when making a chat application, where updates are expected to be almost instant, you are probably going to have similar number of concurrent connections anyhow with a polling implementation. With the HTTP overhead when polling, web sockets would probably make the most sense to both improve client UI responsiveness and server efficiency.

GreeBo

A lot of the node.js tutorials use a multi-user chat app as the project, I guess because node lends itself well to that usecase.

You could also look at something like Scala/Akka, if you want it to scale you need to think this way from the start, if you are only ever thinking 12 users then it can be written in anything and will be fine. Even 12 concurrent users wont stress any modern hardware.

GreeBo

The Corinthian wrote: »

Still, the thought of keeping socket connections to multiple clients open indefinitely, just fills me with dread...

It certainly does seem counter-intuitive from the "old" days, but with asynchronous functional programming (such as node) unless those sockets are actually doing thing then arent really using up and resources. Its not like the old days of specifying threadcounts in your app server.

ideaburst

A further update!

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.

These guys have also received over $100k in funding, which is even further validation imo.

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

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.

Well, if the idea isn't original, you might as well tell us what it is at this stage.

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 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

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

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.

ideaburst

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.

I agree, Kickstarter is for more 'arty' projects. I am thinking more of the likes of Crowdcube et al.

ideaburst

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

What idea is original really?

It is basically an app that would allow people who have moved abroad to connect with people from their home countries in their new location.

howamidifferent

Sounds like Skype... :P

ideaburst

howamidifferent wrote: »

Sounds like Skype... :P

More for people you already know, of course

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?

Same goes if you're American, Polish, British, Australian...

The Corinthian

howamidifferent wrote: »

Sounds like Skype... :P

Actually, sounds pretty much like Meetup.com.

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?

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.

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.

ideaburst

The Corinthian wrote: »

Actually, sounds pretty much like Meetup.com.

I don't see a strong similarity. This would be for interacting online primarily, whilst Meetup is more a platform for driving offline interaction.

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.

Well it would be a global proposition, even though we'd focus on the Irish angle first. I don't really agree though, you can see how Polish people hang out together even here in Ireland, same goes for Irish people abroad to a large extent. Plus the meeting up aspect is only one element, it's more about sharing information online, helping each other out, and generally capitalising on the 'we're in this together' aspects, etc.

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.

This is where I definitely agree, in fact it is one of my concerns. There are 'x nationality in x location' groups all over Facebook and then of course you have the expat / moving abroad forums, Meetup groups as you mention, etc.

I think the big question is whether our app or website would prove enticing and / or valuable enough to have users spend time on it, when strictly speaking they could be spending all their time on these other sites. We'd be starting from scratch while these other platforms obviously have a massive head start (and huge existing communities).