

Ask HN: Rate my startup (video) - cte

http://vimeo.com/2231638<p>Would love to know what you guys think.<p>Beware of the discontinuity @ 6:44 :)
Sorry, no public demo available (yet).
======
swombat
"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.

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

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

~~~
swombat
_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.

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

------
rgrieselhuber
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!

------
jacobscott
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?

~~~
cte
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 :)

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

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

~~~
wesley
And I guess it would also be nice to have just 1 single bot in jabber.

everything@mybot.im .. 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.

~~~
cte
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 :))

------
decadentcactus
I like it, I'd probably at least play around with it or integrate it if I
found a use. Great work!

------
guruz
I like it, it's cool :) Although I can't currently think of a use for it for
myself.

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

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

------
mikeyur
Looks pretty sweet, I could probably think of some way to use it :)

~~~
cte
Please do! :)

------
alaskamiller
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 :(

