Interesting idea, since most websites at the start rely almost entirely on simple CRUD operations. However, this is extreme lockin of an application's foundation, which is why I would never consider it.
This was a good response, if a little arrogant. But they have a right to be arrogant. SendGrid is an amazing story. The execution has been exciting to watch from afar. A great example. I have been a customer since they launched.
My issue is the pricing model, where you pay for 50k (or whatever) emails "per month" but don't get them. If I send 45k one month, and then 55k the next, I have to pay more for those extra 5k emails. I will pay a premium for a premium service, but this is irritating. Irritating enough that I have been monitoring the space waiting for a viable competitor. And with this policy, they are certainly not earning any loyalty on my part. I would leave in a heartbeat.
There's a reason for that - ISPs throttle delivery based on message type - bulk vs. transactional. We work very hard to make sure that transactional emails have NO reason to fail to be delivered, or even delayed. By allowing bulk sending, your message is likely to get through eventually - but it might end up behind a several hundred thousand/million message bulk email queue - meaning that your customers' "forgot password" email or account verification message could take hours to show up. For our customers, that's simply not acceptable.
We've got 5+ years of experience with our bulk email service, Newsberry, to back this up. Not only are our IP reputations carefully monitored and maintained, but we keep bulk and transactional as far away from each other as we can because they're treated SO differently by ISPs.
I've been sending both transactional and bulk email using SendGrid. If I understand you correctly the only downside to that approach is that transactional email may be delayed because it is coming from an IP that also sends bulk email?
I was aware of Newsberry, but I still think that it is not comparable to SendGrid.
Even when we concentrate on bulk email, on one hand there is Newsberry, MailChimp, Campaign Monitor, Constant Contact, etc. And on the other are SendGrid, AuthSMTP, and now Amazon. The former provide an all inclusive solution: WYSIWG editing, templates, subscriber management, analytics, etc. while the latter are an order of magnitude cheaper, but offer a bare-bones solution that doesn't have much in the form of niceties and UI.
SendGrid is somewhere in the middle actually (and so is their pricing). They have analytics (and subscriber management if you wish) and even a crude UI where you can define email campaigns and newsletter templates (although clearly not their core business.) These feature put them above and beyond AuthSMTP which is basically an SMTP server. If Amazon has per campaign analytics (from my very brief look they do), then SendGrid should really be shacking in their boots, because Amazon has just undercut them big time without compromising on core competencies.
We certainly didn't mean to come across as arrogant - just confident. While your frustration on the pricing structure is understandable/reasonable, we don't have immediate plans to make significant changes. If there is anything else we can do to earn your loyalty, we'd be grateful to hear what it is.
Not really. This is partly a reaction piece to what I posted yesterday, but it is not "hate" or "envy" to analyze a company's product, its technical basis (or lack thereof), and discuss it logically. Qwiki has no defensible business model, no compelling technology, yet gets massively funded anyway. We can all learn from exploring this.
I agree that we can learn from this, but then again Twitter doesn't really have a defensible business model, yet it is a wonderful product. I do find the technology to be potentially compelling, as there are many audio-favoring learners in the world who would much prefer a visual representation. With work, it could become something more than a picture aggregator and Wikipedia regurgitator.
Pixelmator is perfectly positioned, which wont be very common. A good solid application, easier to incrementally learn and much cheaper than the primary competitor.
These are some use cases that I do not deeply consider, actually. They might change the context a bit.
I still don't see it as anything more than a toy, even in these cases, and how the valuation could be at all justified, especially given their usage trend while in the alpha, even with all the TC hype.
I can only think of a weird elementary school analogy to this whole Wikipedia/Qwiki thing.
Back in the days when I was a student, there were two easy (read lazy) ways out of reading a book/play: Cliff's Notes (in Canada, they were called Cole's Notes) or watching the movie version.
Neither was really a good substitute for the original, although the Cliff's Notes were invariably better than watching a movie.
If you were to see Wikipedia as the "Cliff's Notes" of a particular subject area, then isn't Qwiki just the "movie version" of the Cliff's Notes?
It is both a blessing and a curse to judge these things based on your own opinions and maybe that's what I'm doing right now.
Because I actually want to use this. Not for everything, but I for many things I can imagine myself using this. At least I've put it in chrome's search bar under the keyword qwiki, let's see if it sticks :)
Twitter development is transitioning into a hobby. As a business opportunity, it sucks. Anything of real business value you create will get sucked into the platform, so, really, there is not much point to it.