Ask YC: Feedback on our new service: messagepub.com
messagepub.com
messagepub.com
1) The color you've chosen for "pub" (#FFF191) doesn't contrast with the white background enough. I find it hard to read. The same problem arises in reverse on the "Free Trial" badge.
2) "A dead-simple messaging API and web service" doesn't do it for me. I still have no idea what your product is.
Spell it out for me:
"Get your app talking to Twitter, AIM, and Google Talk in 5 minutes."
3) The goal of the homepage is to tell me what your product is before losing my attention. The best way to do that is getting me to watch a video. Make your video the center of attention on the homepage and optimize for getting people to watch it.
4) I like the bullet points, but just stick with the first set (no animation). I would also remove the last one, "A cost effective solution!", as it sounds like you made up a 5th item to round out the list. I would also make the copy more active.
5) The upgrade IE6 message is inappropriate for a business website, especially when trying to sell a web service to web developers. You're trying to convince me that I can trust your library to handle all the nuanced use cases that would take me weeks to discover. Remember, I'm a developer so I'm looking for a reason to write my own library - don't give me one.
So if I see "function showUnsupportedBrowserAlert()" in your Javascript it says 2 things to me:
- Your site doesn't render correctly in IE6
- You don't care enough to fix it
That's doesn't give me confidence in your messaging library, which is far more complex than HTML/CSS.
Also, suppose someone does come to the site with IE6, or a browser incorrectly identified as IE6. You're effectively turning them away, is that really what you want to do? What exactly is broken in IE6 and what would it take to fix it?
6) The video on the homepage doesn't perform well as a sales tool (I'm not sure if it was meant to).
I'd make a video that starts with you typing a message into an example app and clicking send. Then your AIM, Twitter, and GTalk alert new messages while your phone rings to play the message back with surprisingly high fidelity. Then show me the 2 lines of code it took (but don't show the install process or have me watch you type out code).
7) Pricing - I'd switch away from using different prices for Email/GChat/AIM/Twitter. Even if I'm a current customer it makes them too tempting to replace one by one. If I'm already integrating with your web service whats so hard about integrating with theirs?
If its feasible I would include a ton of free credits for those services in a monthly subscription, and make your money charging for SMS and speech-to-text over the phone. SMS is a traditionally expensive technology, and both it and phone are much harder to implement than a web service.
I might also change from 1 cent per message to $1 for 100 messages. To me it sounds cheaper, even though it isn't.
I'd also provide a way for your website to call me with a message I've typed in to showcase your text-to-speech accuracy.
That's about all I've got. Best of luck with the service!
* It's not particularly cheap (vs doing it yourself which is effectively free for most delivery methods). Maybe you could compare yourself with other options. Maybe you're better in some ways, so it justifies being more expensive.
* I think a lot of people may only need one or two of the delivery methods. Maybe you can convince me I should be utilizing other delivery mechanisms to reach my users. How would it help me to do so?
Are you saying that DIY is a clear win in terms of those costs as well?
Best of luck to them, but pass.
And that's just one example.
I strongly believe that these things are not trivial to do well yourself and maintaining such an infrastructure will distract you from your core competency.
You should be convinced after reading our homepage that it is worth your money and maybe the current copy doesn't reflect that well enough. We'll keep iterating on that, gather more data points, analyze it, highlight success stories of integration, etc...
Thx for your suggestions.
Don't tell that to us here. Say that in a convincing manner on the homepage.
You theoretically could offer snail mail as well - there are services that translate from email to letters for you.
A left field comment -- Right now, this is a developer-orientated service. You could market it to consumers - e.g. This is my messagepub address, send your messages there. Then the consumer as a receiver gets to decide on how messages get routed to them.
A more difficult play, but it would be interesting to see. The revenue part might be more difficult, but perhaps there are ways around this.
It would also have the advantage that applications don't need to know and maintain everything about you (e.g email, phone, cell, twitter, etc, etc). Even in this model it looks like every app is responsible for maintaining all the required info.
The consumer could just maintain it in one place... Sort of like a Grand Central for the Web.
We built messagepub after a lot of ShareMeme users asked us for an API.
Very excited by the prospect of controlling my communication flow.
If it connected with Twitter and Email for free, and SMS, phone and even IM were pay to play, I'd be a lot more interested.
Were we to switch to MessagePub just for the e-mails we send from JamLegend for friend requests, challenges, referrals, new songs, etc, our communication costs would increase by 600%. For reference, we use sent.com at a price of $25 for 6 months, which lets us send up to 2K messages/hour. Paying $2500/month would be a vertical hike from $4.16/month. I know your pricing page lists that custom solutions are available for high volume, but I can't imagine that the price would come down enough to be reasonable.
So, I think the idea of one service to hit your users on whatever communication medium they like is cool, but the pricing isn't affordable at scale. Think about it like this: if somebody else had built MessagePub, could you afford to have ShareMeme use it?
It makes more sense for products that don't send a lot of messages, and need to be able to send to all sorts of devices. One example that comes to mind is for server monitoring: if a server is misbehaving, you want to be notified, and if you don't see the first message, the message needs to escalate quickly on multiple mediums, perhaps to other people.
For things without a fixed cost you should be charging pence for 1000s of results not 1s.
For phone and txt you have fixed costs and that's obvious, but I would reprice with everything except the phone and text at the same prices for CPM.
Also, how are you going to contact users on IM services? Don't the users have to add you as a friend first?
Some suggestions I would make:
1. drop the charges for sending emails and other forms of communication that don't cost anything, at least for people who make a small number every month. This will help build your user base and encourage open-source applications/libraries around your product
2. include UK SMS and phone messaging; the service is useless to me without it
3. I note you also have sharememe, an "intelligent outbox"; this needs to be more tightly linked with messagepub. How about an "intelligent inbox" too?
My criticism/questions:
- Price is way off: $10-100 CPM for simple message delivery? Does it come with delivery guarantees/retries? In fairness: What's the use case with which you would justify this pricing?
- (How) Do you ensure that email sent via your service is not marked as spam? Reliable mass email delivery is hard these days.
Just try this : curl -v -d "channel=email&address=EMAIL_HERE&commit=Submit&message=messagepub%20sucks%20I%20JustHackedTheirDemoAPItoSendArbitraryMessagesUsingCURLlolSpam&authenticity_token=1f52274baf9904dd33b012c1a4c1548afd197438" -b _trunk_session=BAh7BzoMY3NyZl9pZCIlM2JmZDg3ZDhlYTZjN2U3MzFkNmMyMWMyNGYxYmQ4YTQiCmZsYXNoSUM6J0FjdGlvbkNvbnRyb2xsZXI6OkZsYXNoOjpGbGFzaEhhc2h7AAY6CkB1c2VkewA%3D--2e9b47678c68095440f03ce3b7558712b4fba37a http://messagepub.com/demo/create
You'll have to grab the cookie and authenticity_token from a preceding GET request, as the cookie seems to change from time to time. The authenticity token does not change among successive posts.
Hello spam!
Guys, please fix your security.
This will not stop abuse of your canned messages, but at least messagepost's demo page will not become a spam gateway.
Though if you really want to brag effectively about finding an exploit here, you should probably just shoot an e-mail to the developers first and then, if you feel the need, mention publicly that you found something.
That way you look more like a white hat and less like a script kiddie or a troll.
Ok, it was a 5 min exploit, but I still lolled for most of the evening.
He later edited the comment to remove the part where he said that the site was down...
I got your email, too bad you decided to go this route rather than emailing me about it first. It's all good though. No hard feelings.
I confirm that in my initial post, I wrongly assumed the demo page was down. Downforeverythingorjustme.com confirmed afterwards that my IP was blocked - luccastera moved incredibly fast! And right now, the canned messages seem to be whitelisted, which fixed the problem for good.
* EDIT : I saw after posting that it was already possible. Maybe you should do a replace for send by send/receive and also, change the image to have two-way arrows. This way, it would be more obvious.
In my spam folder was not only the password reminder but also the account verification. Not such a good user experience.
On a side note, the fact that your emails to me go immediately in my spam (on my @yahoo.com account) doesn't give me confidence in using your email service.
The video is a nice intro for devs. You might consider preceding it with a less technical 'overview' video that shows your service in action.
Its tough for a startup to attract big players to use their messaging platform or service because it is difficult to guarantee uptime, reliable service, etc. Might be perfect for mashups and hackers, but they won't pay.
Cool stuff though; I had a lot of fun playing with it.
For example, I looked up the Google App Engine pricing for sending emails and it's $0.0001 for each email.
Additionally, it's unclear to me how your system handles things like bad emails, twitter being down, etc. From a custom standpoint, handling the messaging exceptions is nearly as important as actually sending the messages.
Is this sentence missing "message" after send?
BTW, I love the logo!
how does pricing scale with volume?
We use it and it's awesome. Pricing isn't too bad either.
Stupid move. If it's irrelevant to the business they should take it down. Only has the potential to turn away customers with no upside.
A more esoteric upside would be that a company that speaks out visibly against IE gives me, a technical minded customer, this warm tingly feeling inside. It suggests that someone in the company is like-minded with me. Which in turn suggests that their product and direction might appeal to me, too.
It'd obviously be a different story if this was a product aiming for joe sixpack and the mass-market. But since messaging APIs are a hard sell in the joe-sixpack market in first place I can only applaud their move; focus your resources on the product, not on the latest IE bug.