My best advice for you is to either find a unique value prop in the consumer space where you can perhaps gain a foothold and access virality or focus on finding a nice home for your engineering team and technology. I've seen a lot of advice here about how you should start consulting to create runway. This is terrible advice and you should face reality. Nobody is going to build an app and a business on top of a messaging platform that is a part time project of a handful of developers without any runway. It's just not a rational business decision and nobody who is capable of paying you real money would make that call. You are in a market with existing well funded players that are rapidly evolving their product and addressing that market through sales and marketing. You either have to build something that you can give away for free and generate traction that you can raise money against or you need to focus on selling the core assets that you do have: the people and the tech. You may want to reconsider releasing that code if you want a shot at an aquihire outcome. Best of luck.

in the age of over-supply, it's definitely never enough to just create technology and expect it to sell automagically. go talk to your existing/potential customers and get their feedback. start with a local optimum product catered to their needs, and generalize towards global optimum from there. even Einstein started with a special relativity and not general relativity. ;)

to offer a realistic advice, unless you have a customer-development cycle in place with a target customer base (who has at least signed a MOU/LOI/Purchase Agreement/etc.), I'd stay frugal until you have something like this, then raise money. and yes, I'd definitely stay away from consulting kind of work if you are serious about your business/product. this is a short-term way of staying afloat, but once you build your company's cycle/rhythm/culture around b2b human-labor business, it's hard to turn that around towards a product-driven business.

- Large open source projects

- MOOCs with many students

(Taken from discussion of this post from yesterday):

https://news.ycombinator.com/item?id=9754626

It sounds to me that this use-case is more like a public forum than a chatting solution.

May be some app for easy find right group chat (Android global group, hacker news group, SF Local Tech group, etc...). May be someone know such apps? I try to find it, but no one tries to implement this.

Why are you asking for my phone number just to try a demo? You are creating unnecessary friction IMO.

Short Term:

- You need time => consult to get money => to get time

- Be careful with this path => make sure it stays only short term

- if possible consult in the same space of your product.(best case: your clients pays your future platform development)

Mid Term:

- You think like a developer atm - unless you plan to sell to developers this wont solve your core problem (understanding the market)

- tech can be completely useless with one usecase or extremely valuable with another. Figure out who could be potential customers (it's product thinking not dev thinking, best case: you learned this in your consulting period)

- when you figured out who "could" be your customer make sure it's actually a customer you can/want to deliver for. If you sell to enterprise it will be a sales operation and you need to learn this.

In any case: Head up and be confident. Things are not as bad as they seem and there will be a good end (maybe not directly afterwards but in the years to come)

This is your major problem. You built technology without a specific business case. Now you are trying to turn that into a business. This is a terrible position to be in for 2 reasons: You will be trying to fit problems to match your solution. Your solution doesn't have the nuance or context associated with a specific problem, which is usually required to have a compelling product.

Of the options you list, #3 is just silly. No one is coming to save you. #2 is your best bet. Then again, I have no idea how you got $100K of funding for not solving a problem, so maybe you can convince those suckers to re-up for #1 again.

Building technology is not the same thing as building a business. You guys blew $100K on technology, and now have no money to make a business. And now your are entertaining the idea of open sourcing the one resource you do have: your technology.

Stop all this. It's tough, but fire everyone. You can't pay them and taking more money with no idea how to get more is, at least in my opinion, unethical. Go do consulting in spaces where this technology might be applicable. Understand what problems they have and try your best not to assume your messaging technology is the solution. If you are a lucky, you will find an actual problem that you can repurpose some of this technology to solve. Then and only then can you re-build this as a business.

PM me if you are willing to explore that scenario and consider relocating to Poland.

"Jobs-to-be-done" (JTBD) is useful analytical tool here. A "job" is a thing that someone is trying to accomplish. Harvard's Theodore Levitt expressed it well in this quote:

"People don't want to buy a 1/4 inch drill. They want a 1/4 inch hole."

It reframes the discussion away from features to customer objectives.

As you look at your platform, think about different market niches and the things they're trying to get done. Here are three tests to apply as you consider a given niche.

1. Is it an actual JTBD for a large enough target niche?

This is the most basic test. Do people actually have the need that your product/service addresses? Not only that, but can you characterize the the number of potential customers with the JTBD?

2. Does your product/service/idea meaningfully improve on the incumbent solution(s)?

This is a tougher test. How does your idea outperform the current way customers address the JTBD? You need to have a clear view on this. And the improvement needs to be significant, not just a little. Customers will overvalue their incumbent solution's benefits, and undervalue the new product's benefits.

3. Is the total incremental cost to the customer of your idea less than the total incremental value to the customer?

This test is the toughest. You need to consider monetary costs of course. But there can be many other switching costs as well. Loss of existing data, new time required to learn, new formats that have upstream and downstream impacts.

My take is that successful products can get to clear yes's on these three tests. But it takes some work, experimenting and seeing where your idea falls short if it's not getting yes's on the three tests.

> Provide simple encrypted messaging, like GPG but for people who have no desire to manage their own keys/ aren't tech savvy. This could work if you want to stay in enterprise.

> Target things regionally. Maybe you can provide a product that works better in Russia than Slack or use some advantage of knowledge of the culture to make a great product for a specific region.

You really need to be out talking to customers and potential customers. I don't think making a simple messaging app will work in this market, you need to find a competitive advantage. You only find this by knowing it already or talking to customers.

edit: or you could pivot into customer support chat communication.

I don't think so. I think there's lots of room in enterprise chat space for differentiated products... it's not just slack or hipchat. E.g., a on-premise hosted chat with actual native clients for OSX, Windows, iOS, and Android would find buyers. IRC has traditionally been the solution for this but IRC doesn't have a uniform mobile client experience and the backend integrations (notifications for github, gitlab, bug tracking systems etc. etc.) are not as rich and diverse as slack/hipchat.

so, "winter is coming" might really be a thing there, huh!

> P.S.: Right now we are preparing our sources to release, and they will be available in a week or two.

Don't worry about anything for now. Just do that release, having those doubts before a release is fatal. Just focus on the release for now. Things will be different after the release.

but usually the "development part" wasnt the thing to worry about in first place

(same with bizdev who go to networking events or arrange meetings, designers who redo landing pages or ceo's who spend time chasing investors)

my thoughts a bit longer explained: http://klinger.io/post/36585126176/the-founders-lie-about-co...

AFAIK Slack and Hipchat are cloud based, which is fine for some but not all enterprises due to obvious security concerns, and if you can make self-contained and easily deploy-able system that can integrate with enterprise IT systems, particularly authentication, you may have an interesting use-case.

Healthcare is another big space, where there are several startups looking at messaging where Slack etc. won't work due to HIPAA compliance and other specific scenarios.

P.S. Didn't try your demo, since it wanted phone number, and sorry we don't know each other well at this time to trust you with it. :)

Or just make a clone of this for mobile: https://en.wikipedia.org/wiki/The_Palace_(computer_program)

Perhaps you need to think bigger than your own project, but develop something that others can incorporate into their product. Designing a basic chat service is relatively easy and will become even easier in the future with programming languages like Erlang/Scala becoming more popular and widespread. (Chat programs are often the "hello world" programs of these languages in tutorials). But designing a robust video-chat service is something that not many companies can pull off.