What I think you should also consider is the MS Access angle. What made Access so popular in enterprises was that they could basically build a Windows app with almost no programming skills. Define your tables, build some forms, install the runtime for people–BAM. You're done.

In my opinion, that would be a necessary component to this idea. You need to have both spreadsheet-like data viewing and form-based data entry.

I suppose that's what Wufoo and Dabbledb already do to some degree, but I think there's more you can do.

If you combined: - spreadsheet-esque data viewing (maybe with some formulas) - form-based data entry - good sharing tools - permissions - import/export tools - some database templates that let you spin up stuff fast

Then targeted it at some big verticals, I think that would be a good start.

Hi, OP here. Thanks for all the replies. Unfortunately I don't have anything to show at this stage. I always keep rewriting this thing in different languages, then leave it to do some other stuff.

It would seem that the most efficient thing to do would be to develop a data entry + reporting solution for some vertical first, while keeping the back-end flexible enough that other verticals can be added later. It's just a matter of finding the right vertical (ha ha).

The generic DB idea has the virtue that to implement it one doesn't need to get out of the house, so to speak -- to go look for a specific problem in the real world and develop a real solution.

Thanks again, and if you can think of any vertical in need of an almost-generic DB, please let me know.

This stuff was one of my first personal projects. I wrote several versions and demoed them around to maybe tens of people. Typical response was mild interest but no one wanted to use it. Too generic. In fact, it's more generic than Excel: Excel is packed with features that solve specific customer needs.

Dabble DB seems to have carved out a niche, but they executed exceptionally well: they have map integration, natural language parsing, all kinds of charts, all kinds of import/export formats... I'd recommend learning from them and copying them shamelessly (features, promotion, pricing, every aspect where you're not completely confident) instead of choosing a vertical.

Don't market it as a "database". That scares people. Don't market it as a spreadsheet either, because they'll think it's for financial number crunching stuff which Excel does well.

Now, ask anyone: do you sometimes use Excel for lists and storing information? Try not to say the database word, but if you're with a techie, they'll understand it fine without being scared. I bet you most will say "yes".

Blist tried doing this, but failed for a few reasons. There is without a doubt a need/market to do this, but it requires such a perfected formula mix. I hope somebody does do it.

I worked at blist a year ago. Their original product was an online database/spreadsheet product aimed at business collaboration (like a web-based version of MS Access). Recently they renamed the company to Socrata and now they are focused on helping government agencies publish data on the web using the same basic database/spreadsheet interface.

hi matt!

ya - my take on web spreadsheets is that there is this awesome combination of a) being really hard to build well, and b) dont solve a specific problem that people want to pay for (applications are too generalized)

Actually a lot of high ups like CEOs and senior staff email excel spreadsheets around. You'd be surprised.. I can think of about 3 or 4 examples of these types that I've come across off the top of my head.

Do you have anything we could look at? =) I think if you have the right approach and decent marketing you definitely have a market..

but the description you have is a little vague so it's hard to figure out what makes your app interesting and therefore hard to advise..

This was also an idea that I was playing around with in 2008. The basis of the idea is that millions of people have knowledge of using a speadsheet but not many of then can develop and launch a web app.

So my idea was to provide the missing link, a web service that takes a spreadsheet and puts out a web app/site hosted. I did not pursue that when google docs released web form for your spreadsheet.

Have you "dabbled" with dabbledb.com?

came here to post dabbledb -- seems exactly the sort of thing described in the OP http://dabbledb.com/

similarly, queries in google spreadsheets are pretty amazingly powerful.

Everyone emails Excel spreadsheets around. The only problem is getting into email jail.

I think your problem is Sharepoint solves this problem (emailing spreadsheets) and is pretty standard these days.

Sometimes spreadsheets are too big to email, then people split them up manually, or try to get some one else to transfer it for them.

Sharepoint can solve this problem but setting up and using it is non-trivial if your not a techie (and maybe even if you are).