Hacker News new | comments | show | ask | jobs | submit login

Just some hopefully constructive feedback here: for Excel power users, you're not just competing with Excel, you're competing with Excel+ODBC+SQL+Workbench which is basically an Excel/DB hybrid, just not web based.

I read your "how this is different than a spreadsheet" blog, and none of the examples struck me as compelling, even though I use my Excel/SQL toolchain every day. Given how strong the ecosystems are around those tools, I think it would be very challenging to convert power users without some really obvious hook.

That one hook COULD be a good mobile client. For example, I have a dashboard built in Excel with an ODBC connection to a few of my company's DBs. However, I obviously can't see this on my phone, since no mobile Excel client supports ODBC (not to mention the macros I have built in).

I could maybe see a "disruption" angle, where you provide 75% of the functionality of Excel+ODBC+SQL+Workbench in one easier to use package, but I wonder how large the market is for people who want to work with that level of data but don't want power tools. I guess that's one area where you'd have to trust your market research/gut.

He could readily target the market of people who use Excel for things they shouldn't be doing, because they don't know how to encorporate SQL+Workbench, and don't have the time to learn.

Yea, it seems like this is a pretty market position if you ask me -- if you need DB like tools, why not just use a DB? This product would have to be an order of magnitude easier to set up and use to get people to use that instead, IMO.

Could be wrong though -- would be great if something like this could improve the data/analytical literacy of the general population.

"if you need DB like tools, why not just use a DB"

A) people don't really know they need db-like tools. B) even if they did, setting up a database to have even a portion of the "up and running" aspect of Excel is extremely time consuming.

The closest I've seen is some companies that get advanced enough set up a database engine somewhere, then set up Excel to connect to it as a datasource (ODBC or whatever). This still requires them to understand how to set up a database, secure it, and model table structures around their data, which is asking quite a lot from someone who really just wants to create a few short forms to collect data.

One big point that we forgot to mention in that blog post is that Excel is hard to work with when multiple users are involved.

It would be quite a bit of trouble if Excel users want to implement access control on whether some users can read or write certain entries.

So for "collaboration," I'd almost rather see something like Spotfire's publish/view model, where not everyone has edit permissions, but power users can publish their sheets for people to view.

This more closely mirrors the workflow in my office at least, where only a handful of people create reports, but maybe 10-20x the number of people just want to consume it.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact