Ask HN: What can we do with our messaging platform startup?

Hey guys, head of engineering at Layer here. If you actually try to go down the road of building a platform for other developers then you are very quickly going to discover that you need to build a bunch of other stuff totally separate from the core messaging service. You are going to need solutions for getting data in/out, dashboards, billing systems, sample code -- on and on. Plus you have to provide an SLA to close any meaningful business. And you'll need a pro sales team to get those opportunities interested and through the funnel. We are 35 people and I could easily keep another 5 engineers fully loaded to attack the roadmap as aggressively as we'd like. And we've been at this for 2 years. There's a lot of surface area and you need to be very good on both technical and sales dimensions to make a platform play work.

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.

agree with blake here. we're also working on a similar product, but we had customer base from the start with actual use cases, which lead to bookings/revenue early on. you have to look at from the customers' perspective to see which problem you are actually solving and how you are creating value/saving cost for their business.

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.

Slack is extremely expensive for large "community" chat rooms. If you could handle a several-thousand user room and offer full functionality for a fraction of Slack's price you might have something that could get some traction.

Could you describe a usecase for that?

Let's see:

- Large open source projects

- MOOCs with many students

(Taken from discussion of this post from yesterday):

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

Yeah! I saw this post today and we thinking about building something for communities.

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.

I was going to suggest contacting freecodecamp.com and seeing if they would like to partner with you to develop a product that suits their use case.

Why would latency be a practical issue on such a platform?

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

User groups, open source communities, game clans, etc.

Slack is also not exactly just chat. It's actually a whole eco system of features and polish that would be hard to replicate.

Very true, but for some, it is just chat (in the same sense that Github isn't just a source code repo or Freshbooks isn't just invoicing - there will always be a subset of those users that don't know or care about non-core features)

What would the user experience of several thousand people in a room be? If a significant number are talking, it would be a stream impossible to keep up with, but it makes no sense to arbitrarily choose users to partition into different channels or rooms.

There are freenode channels with 1,700 or more people in them. It works because most people don't talk most of the time, they're listening or just waiting for someone to ping them about something specific.

> Anyone can join experimental chat by opening URL

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

yes, I wanted to try the service, but stopped when it asks for phone number.

IMHO:

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)

> We don't solve any specific problem;

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.

Consider option: 4) Start doing consulting work. That way you can survive as a team and gather resources for the next phase. Whatever it will be, productive dev team is an asset and it can be worth something.

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

I don't know this market well. But I can suggest three tests that you should apply to any potential niche you're considering.

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

I have very simple advice: Get people using your product and ask them what they like/dislike about it. I wouldn't try and compete in the messaging space as it is saturated. In enterprise there is Slack and Hipchat, and in the consumer space there are so many I won't name them. You can stay in communication, but change your product a bit:

> 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 wouldn't try and compete in the messaging space as it is saturated"

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.

> during winter we lose 50% of our money

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.

I can't believe in releases. Just release meant nothing usually, isn't it?

No, focus on getting the release out. Then focus on what comes after that. Keep your head down for now.

the problem is that developers tend to develop when things go south

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

Have you looked at enterprises?

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

Take a look at layer.com. Perhaps you could find something that sets you apart (low latency and lots of connections, plus a good price for Android devs, for example) and market to developers.

You have a platform, build an fun app that uses it. For example: ask yourselves what twitter would be like if it allowed people to exchange markup or bytecode that defines applets instead of 140 character texts? What is the most application you can ship in 32 KB of data? Yes, Kilobytes.

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

Publish your code on a github repository and become a platform as a service. People need to adopt your platform as a foundation for anything. At the same time offer messaging as a paid add on service with a revenue model tied directly to use. Eg. * > 100,000 messages per month is 1.00 per month. Sell your support and integration services.

I'm keen to understand exactly what parts of a 'messaging stack' you guys have built. Feel free to drop me an email (details in my profile).

Perhaps you could provide your messaging platform as infrastructure as a service for startups?

Here comes another question: what's the difference with https://layer.com?

If the technology is 10x better, there doesn't need to be much difference. There's room for more than one provider.

Offer reliable voice/video conferencing supported on all platforms.

We can provide voice/video with 3rd party services and it works good on stable networks, but does it add enough value or we need to spend half-year on optimizing webrtc?

The keyword is "reliable". Solve this problem and you have a product.

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.

Good chat application is not like hello world app. You can build something like chat, but it doesn't have most required features and performance.

I would be careful about this. They are building a product with simple messaging and you are adding 2 very large feature sets.