Ask HN: Rate my startup (video)
25 comments
"It's a platform for creating widgets for the mobile web". Platforms don't make money. A platform is not a business.
"We don't really know what widgets are." Following on the point above, you're creating a platform (a non-specific, generic "thingy") for creating widgets (non-specific, generic "thingies") for the mobile web (something that's not even really defined properly yet. Non-specific businesses are almost without exception failures. Only huge businesses like Sun and Microsoft and Amazon can afford to release "platforms" without going broke.
Here's the most valuable advice you can get at this point if you want to build a start-up (that's a business, meaning it needs a path to making money) is:
Find one or two specific customers who have a need that this fills, and fill it, and get them to pay for it. Specific wins the day.
Since you've built a platform, you may well have to go one step closer to customers before you can help them. Design an application that people will be willing to pay for, using your (admittedly very cool) platform. Then, once you have your app and you have profits, over time you might want to open up the platform to other people.
Repeat once more: a business is an entity that makes money. A platform is not a business.
"We don't really know what widgets are." Following on the point above, you're creating a platform (a non-specific, generic "thingy") for creating widgets (non-specific, generic "thingies") for the mobile web (something that's not even really defined properly yet. Non-specific businesses are almost without exception failures. Only huge businesses like Sun and Microsoft and Amazon can afford to release "platforms" without going broke.
Here's the most valuable advice you can get at this point if you want to build a start-up (that's a business, meaning it needs a path to making money) is:
Find one or two specific customers who have a need that this fills, and fill it, and get them to pay for it. Specific wins the day.
Since you've built a platform, you may well have to go one step closer to customers before you can help them. Design an application that people will be willing to pay for, using your (admittedly very cool) platform. Then, once you have your app and you have profits, over time you might want to open up the platform to other people.
Repeat once more: a business is an entity that makes money. A platform is not a business.
That said let me add that this does look extremely cool and promising, and developers will inevitably be all over this. But also remember that developers are unlikely to make you any money because a) they don't like to spend money, b) they are insanely creative about ways to "do it themselves" to avoid having to pay you money.
As a developer, I can vouch for that :)
In fact, I ended up building this because I didn't want to pay for the other mobile services platforms (there are a few of them) when attempting to add mobile features to another project I'm experimenting with.
But to your original point, I absolutely agree, pitching this as a "mobile" "platform" for "widgets" is probably hopeless. Quite simply, it must solve somebody's problem. And I believe that we can get it to do just that. One area that we think is promising is using email to invoke applications that do interesting things because (1) everyone knows how to send email, and (2) you can attach lots of useful things to email.
So, what if we added the ability to recognize a ton of different file formats and allowed you to query the data within an attached file to invoke other web services?
For example, lets say you have a site that does group payments, and you want to let your users send you an Excel spreadsheet with the names of your friends and how much they owe you for that trip you just took together and automatically create an invoice on your site, and then notify everyone that they owe money. That seems interesting, and our product could support that pretty easily.
Anyways, it is definitely our immediate burden to focus this technology on solving _real_ problems.
In fact, I ended up building this because I didn't want to pay for the other mobile services platforms (there are a few of them) when attempting to add mobile features to another project I'm experimenting with.
But to your original point, I absolutely agree, pitching this as a "mobile" "platform" for "widgets" is probably hopeless. Quite simply, it must solve somebody's problem. And I believe that we can get it to do just that. One area that we think is promising is using email to invoke applications that do interesting things because (1) everyone knows how to send email, and (2) you can attach lots of useful things to email.
So, what if we added the ability to recognize a ton of different file formats and allowed you to query the data within an attached file to invoke other web services?
For example, lets say you have a site that does group payments, and you want to let your users send you an Excel spreadsheet with the names of your friends and how much they owe you for that trip you just took together and automatically create an invoice on your site, and then notify everyone that they owe money. That seems interesting, and our product could support that pretty easily.
Anyways, it is definitely our immediate burden to focus this technology on solving _real_ problems.
So, what if we added the ability to recognize a ton of different file formats and allowed you to query the data within an attached file to invoke other web services?
You're still talking in terms of solutions. "Hey, we could build this cool solution! Would that solve any problems?" I've never managed to find a worthwhile business idea that way (not that I'm an expert at it or anything).. in my experience the way to do that is to find the problem first and then figure out what solution you could build (using your technology) to help solve that problem. Then figure out if there really is a market for that solution, and then build it incrementally and evolve it to serve that market. Then at one point flick the switch and start charging.
You're still talking in terms of solutions. "Hey, we could build this cool solution! Would that solve any problems?" I've never managed to find a worthwhile business idea that way (not that I'm an expert at it or anything).. in my experience the way to do that is to find the problem first and then figure out what solution you could build (using your technology) to help solve that problem. Then figure out if there really is a market for that solution, and then build it incrementally and evolve it to serve that market. Then at one point flick the switch and start charging.
Amen; this mistake killed a company I cofounded and got funded during the bubble. I'll add: you can't really build a platform without building and selling the specifics; without real customer drivers, you run out of oxygen in design and architecture wanking.
If you've built most of a "platform", you should be in a good position to turn out cool apps quickly. Hide the platform, let people wonder why you're so good.
If you've built most of a "platform", you should be in a good position to turn out cool apps quickly. Hide the platform, let people wonder why you're so good.
I second the notion. Read crossing the chasm. What swombat is saying is "find a beachhead, dominate it, then open the platform". Think about facebook and how they dominated one niche then opened it up to everyone else; this model has been used many times successfully for platform companies. The hardest part about this is maintaining focus on the beachhead when you get popular, and saying no to other segments. until you are ready.
Since when is Facebook an example of business best practices?
Well, they DID start with a niche, say no to the outside, dominate, then use that domination to leapfrog the competition into the mainstream, exactly how crossing the chasm says to. By design or fluke, it was certainly brilliant.
I follow your point, but I think you need to qualify it better.
I would argue that a platform can make money if structured properly–most notably if it allows platform developers/users to make money and takes a cut (a la iPhone apps or iTunes music).
If his widget platform allowed widget developers to sell widgets and/or process transactions, then it most definitely could be a business.
Maybe our definition of "platform" is different.
I would argue that a platform can make money if structured properly–most notably if it allows platform developers/users to make money and takes a cut (a la iPhone apps or iTunes music).
If his widget platform allowed widget developers to sell widgets and/or process transactions, then it most definitely could be a business.
Maybe our definition of "platform" is different.
I agree with most folks that it does really solve a problem, but in an effort to try and be constructive, one potential problem are forms on mobile devices. It is very difficult to port web applications or forms to mobile platforms because the display area is so small. Creating a conversational interface via chat might be a good angle to creating usable, yet complex, forms on mobile devices.
One good example might be ordering a pizza at a party. It is loud and you don't know the address. You can start texting a pizza place your order and let some other aspect of the application handle the GPS position.
Anyway, it looks like you guys have been doing a good job so if this idea makes you millions or something feel free to send an email or something ;)
http://ionrock.org
One good example might be ordering a pizza at a party. It is loud and you don't know the address. You can start texting a pizza place your order and let some other aspect of the application handle the GPS position.
Anyway, it looks like you guys have been doing a good job so if this idea makes you millions or something feel free to send an email or something ;)
http://ionrock.org
I think this is actually really cool. I agree with the other commenters that you're probably a long way from this being a "startup" (at least in the post-Oct2008 world that would like to see some business model), but you are certainly doing some interesting things.
How you turn this into a business is another problem but I think you will probably see people picking up on the ideas here and rapidly creating their own innovations. That might seem like a bad thing, but I think it's good because it means you've come up with something very powerful.
Probably the most interesting thing to me is the subset / scripting language that makes interacting with various services and providing the backend infrastructure for performing that automation.
Good luck!
How you turn this into a business is another problem but I think you will probably see people picking up on the ideas here and rapidly creating their own innovations. That might seem like a bad thing, but I think it's good because it means you've come up with something very powerful.
Probably the most interesting thing to me is the subset / scripting language that makes interacting with various services and providing the backend infrastructure for performing that automation.
Good luck!
What's the technical underpinnings of the stateful stuff? Is it more than multithreading? Ruby specific? Seems neat, but hard to tell if it will really be useful (in possibly the same vein as javascript-based "OS in a browser"s). Can you come up with a killer app? Or reproduce a well known mashup with very few lines of your own code?
On the backend, you'll definitely need sophisticated monitoring/resource allocation stuff once you have users, right?
On the backend, you'll definitely need sophisticated monitoring/resource allocation stuff once you have users, right?
I realize now that we didn't show a stateful app, but basically an application is run in steps, and the boundaries between steps are the calls for user input because the app must pause to wait for input. So we store the last instruction executed and halt the app. Then when input is provided, the app is restored at the proper point and continues running. It is not ruby specific, but it is _much_ easier to build this with interpreted languages.
I don't think we have the killer app yet, but we implemented a mobile interface to google calendar with ~5 lines of code which I've been using for a little while, and its surprisingly useful. When all is said and done, I think we might want to simply pitch this as a platform for adding mobile features to your existing app, so it becomes more of a developer tool than a consumer facing product.
As for monitoring, yes, it becomes a tricky task to achieve high availability (and scalability), but its a really fun problem to tackle :)
I don't think we have the killer app yet, but we implemented a mobile interface to google calendar with ~5 lines of code which I've been using for a little while, and its surprisingly useful. When all is said and done, I think we might want to simply pitch this as a platform for adding mobile features to your existing app, so it becomes more of a developer tool than a consumer facing product.
As for monitoring, yes, it becomes a tricky task to achieve high availability (and scalability), but its a really fun problem to tackle :)
Looks very interesting and promising. I'm not sure if I have much use for it just yet but I think I would be easily convinced after seeing more examples of useful apps. I also like the domain name and applaud you both on the immense amount of work I'm sure it took to make the product.
Very nice, but can you skip the first step? You have to send "ping" first?
If I use a service multiple times, I would already know what input the app needed. For example, "Weather NY".
If I use a service multiple times, I would already know what input the app needed. For example, "Weather NY".
And I guess it would also be nice to have just 1 single bot in jabber.
[email protected] .. instead of having 10 bots for 10 different things.. (would clutter things up pretty fast)
Just send an identifier to the bot when you first ping it to tell it what app you want to access.
[email protected] .. instead of having 10 bots for 10 different things.. (would clutter things up pretty fast)
Just send an identifier to the bot when you first ping it to tell it what app you want to access.
Definitely agree. And its really easy to do so because you control the code. I actually have a bot that just executes whatever function name I give it, and I have a bot that runs arbitrary system commands on my server, which is kind of like having an IM terminal (_not_ recommended for security purposes :))
If your first line of code is 'x = prompt', there is no ping needed to invoke the application. I should have touched on that in the video because it ends up being a very bad user experience if it requires a ping to start your app.
I like it, I'd probably at least play around with it or integrate it if I found a use. Great work!
I like it, it's cool :)
Although I can't currently think of a use for it for myself.
There were some mobile features that I wanted to implement on an orthogonal project that I'm toying with, and I noticed that there were no good APIs for IM-enabling your app, and I wasn't truly satisfied with the existing SMS solutions, so we built this. However, to your point, we need a killer app to really show the potential of the platform. Arguably though, it might make the most sense to simply target my original use case, and build the platform for developers who want to add mobile features to their products but don't want to spend huge amounts of time figuring out exactly how to do so in a scalable and highly-available way.
I don't have time to watch videos, sorry.
Meaning: I'll happily take a look at your site, and have many times in the past here. What I don't want to do is sit through a video that I can't jump around, explore, and so on, like I might with a site, or a brief article.
Meaning: I'll happily take a look at your site, and have many times in the past here. What I don't want to do is sit through a video that I can't jump around, explore, and so on, like I might with a site, or a brief article.
You've made a kind of Automator software (http://en.wikipedia.org/wiki/Automator_(software)) for the web. This is pretty nifty! With more integration with services it could actually be pretty useful.
Don't know how you can make money though :(
Don't know how you can make money though :(
Would love to know what you guys think.
Beware of the discontinuity @ 6:44 :) Sorry, no public demo available (yet).