Hacker News Reader

Comment by dpandya | Hacker News Reader

> Looking for a SaaS idea? Ask random people in a target industry what kinds of things they do with Excel.

Strongly disagree with this based on personal experience in "traditional" spaces that rely heavily on spreadsheets. There's a reason most of the financial industry uses Excel spreadsheets and it isn't because they can't afford to pay for specialized software. Excel spreadsheets are incredibly versatile. Your data format can change a little bit over time and you'll still be fine. With a custom software solution, you're kind of stuck within the confines of what the developers/product managers gleaned from your working process.

View on HN

I'll strongly disagree in turn. I personally know some successful founders whose business, in one important facet, could be summed as "get rid of those painful Excel spreadsheets". It's not the use or not of Excel. As with most things, and as TFA discusses, it's about the pain factor. Spreadsheets are, far and away, the greatest success in end-user programming to date. But like all software tools, their usage can grow into painful places.

Do the users have massive, error-prone and/or time-consuming workflows built around those spreadsheets? Is it very hard to bring new staff up to speed, or to keep existing staff compliant with process, or to meet day-to-day business goals with those spreadsheets? Is there no solution between "painful spreadsheet" and "$X,000,000 contract w/ bigcorp" to solve those problems? If 'yes' is cropping up in answer to those questions, then lifting the logic from ad-hoc process around spreadsheets into software may be a good idea and/or a good business.

I worked at a mid-size startup where all of the customer-facing people were ex-finance---I was consistently amazed by the stuff they did in Excel using just pivot tables, rudimentary graphing, and (VBA? I don't think you could use Python at the time) scripts to do data cleaning, ad-hoc CRM, even rudimentary procedural generation of web content. 90% were one-offs, so it was totally appropriate to not throw developers at the problems (recurring things eventually got built out as microservices).

The main downside was that the functions and transformations weren't sharable across documents, and often there ended up being several mildly tweaked versions of the same functions across a bunch of documents. But I think I learned something about human tool use: when motivated, people will find a way to use the general purpose tools they know to improve individual efficiency.

I generally agree with you, but you picked sort of an exceptional example. As far as I know, Finance/Accounting is one of the explicitly defined use cases for Excel. For finance people, it's actually the best-in-breed tool for what they're doing.

GP is talking about people outside Finance who use Excel as a database. Though he's being a bit facetious, he's actually not far off. For the store data/retrieve data/share data workflows that most of these folks have, there actually is a good SaaS business in putting Excel on a server, wrapping it with a database, putting a nice UI on it and adding a few industry specific features.

Excel is the best tool in the world for quantitative exploration because the data flow and logic are incredibly easy to change. This makes Excel spreadsheets extremely versatile but also extremely easy to fuck up.

The basic counter argument to this is software engineering tools. If you have a more than trivial SS you end up needing tests, version control with branches, merge, and rebase, and an automated process for applying both.

OP referring to all use cases outside of pure financial. Basically where excel being used for managing a list.

Reply on news.ycombinator.com