Looking for a SaaS idea? Ask random people in a target industry what kinds of things they do with Excel.
In a similar vein, there are plenty of small software teams that use nothing more than a whiteboard for project management. Yet there are teams tooled up with Jira/Trello/Slack with much less productivity.
The opposite is also true: You can make a decent living creating, customizing or even just maintaining domain-specific tools, no matter if the customer's business really needs them or not.
I one worked at a place where a key part of the finance system ran on a spreadsheet - turns out this SS had mess up or finances and was one of the reasons the company restructured.
I can't believe I'm about to sink so low, but... criteria!
Criterions are what one adds to soup ;)
You're thinking of crouta.
Besides, I wanted to make a somewhat self-deprecating comment, rather than - as you have here - regurgitate some half-arsed passive aggressive form.
If two business processes interact through a spreadsheet, or more than two people edit, you're going to immediately run up against the rough edges. Multiple people editing the same sheet inevitably ends in error. It can take a really gross amount of time to update the data when you're pulling/pushing from two sources. It may seem small on the surface, but even 2 hours a week adds up to nearly 3 weeks of work over a year. Can you replace this spreadsheet in 3 weeks?
I've seen this play out many times at large and small scale. The first example that comes to mind is a 10-hour day trip my wife took to go out of town and manually update a whiteboard because somebody messed up the shared spreadsheet. She was very unhappy, and this wasted a precious day during a _very_ busy period. Initially, the whiteboard and spreadsheet worked great, so they didn't "fix" it. It didn't scale to the busy times and really screwed them over.
At a much smaller scale, I wrote a quick SQL query to get some business metrics for the CEO. He asked if I could run it for him every week. Since I didn't have a good place to put this query, I just ran it manually and emailed it to him at first. Then he wanted to share it with someone on the opposite coast outside our network, so he asked if I could start putting it in a shared spreadsheet. My initial thought was to bang out a page they could pull up instead, but I figured it wasn't worth it. Then he wanted another metric. And another that required a bit of logic that couldn't be done in SQL. Pretty soon I was spending an hour a week manually running SQL and copying the results in to a spreadsheet. (We're a Google Drive shop. No way to connect Sheets to DB2.) That's simply not worth my time. I should've listened to my first instinct.
The initial investment in a spreadsheet isn't large, but the ongoing maintenance can really rack up hours. I think it's very often worth investigating any spreadsheet that users have been maintaining/recreating for more than a quarter.
This means that if your computing problem doesn't need to scale, a spreadsheet may just be the perfect tool.
However, I agree with you. The next Facebook might be of whomever builds a spreadsheet that scales.
I tried smartsheets but it’s more calc centric. Asana is great if you are task centric.
I can't count the many times a business process is done (poorly) by inputing lots of data in an excel file, running a huge (poorly written) macro, and spending the file via email to the next person and so on...
FWIW, Google has an API that can be used to get data into and out of things like Sheets. The documentation for it is abysmal and there are only a few libraries out there, most of which aren't complete. But, I've done it, and have some rough (but easy-to-understand) code that can "import" Sheets into MySQL. Going the other way should be a matter of tweaking the Google account permissions and calling a couple of different functions.
It's in PHP, but it's not gross PHP, so you can probably translate it into whatever you're familiar with.
You can for example set up a cron job to post some json to that endpoint and have the js validate it and update a sheet accordingly (or even create a new one).
Yes, the App Script API is kind of limited, but also extremely powerful for simple services or to glue services together.
I think something lost in this conversation is how spreadsheets are largely a part of general primary school curriculum. Generally people have a feeling of confidence around them that is lost with other tools. Particularly "easy database" applications that attempt to replace spreadsheets.
There's a reason Excel is so powerful, but it can't magically solve for people lacking a process and most software solutions solve it by using complex permissions, versioning and collaboration features. You can just easily lock down the shared spreadsheet to readonly and have 1 or 2 people who are designated editors and get the same effect, or just have the changes done on a new tab and compare that way.
Even the most amazing software can and will get screwed up by users who don't have a process.
The problem isnt Excel or any useful tool, its the misapplication of the tool and seeing people driving that same road already extremely well traveled.
If there's a better way then suggest it, or at the very least document the time and effort spent on these reports. If they are that critical (which they usually are for decision making) then it shouldn't be an issue when planning future work.
I’m not sure how “global level” organisations are, but mostly you just can’t convince a typical layman CEO that something looks easy, is really not easy.
Then when you serve the “small request”, next he’s in doubt why adding a small feature could increase the complexity of your work by a few order of magnitude.
You've never seen panic like a multi million dollar business discovering that excel doesn't allow more than some fixed number of rows (1m?).
If what you are doing is applying math formulas over small or medium sizes of data, then excel is OK.
Otherwise it will suck and will be a waste of man-hours at the Office.
It's very easy to criticize something by saying you don't need it. There are very few things in life that you absolutely need.
Yet there are things that add convenience, greater efficiency, etc, and people will pay for them.
And I've found out that having excel export of essentially any data in your line of bussines application is indispensable unless you expose some kind of excel-like querying and data manipulation mechanism to users as part of your application.
I work for a small company, we generally use Jira (which we all hate, some with more of a passion than others... ok mainly me).
More recently we sort of accidentally started using google sheets for managing issues on some long running projects: it's easier to get an overview, i can add and remove unnecessary attributes of issues and filter them appropriately and dynamically without having to define a whole new workflow and start over. It takes basically the smallest amount of time possible to log an issue... I can organise them however I want. Issue management is overrated, issues are simple, and having something as flexible as a spreadsheet is a surprisingly good fit for anything not customer facing.
Oh also, I don't need to _learn_ how to do all those things... it's a spreadsheet so it's obvious, but Jira - it's so hard to do anything unless you live by it, I don't want to live by an issue manager I want it to get the fuck out of the way so i can do work.
A spreadsheet works until it doesn't.
Maybe you load in past, say, 150mb of data.
Perhaps the last person to touch it linked it to a data or content source they only have access to.
Perhaps the person editing it has it checked out from a Sharepoint and forgot to check it back in.
Perhaps the person editing it left it open on their computer and forgot about it being hosted on a shared drive.
Perhaps the business critical sheet is hosted on someone's desktop.
Fundamentally, spreadsheets are cocktail napkins. It's fine to sketch out a basic idea. It's a terribly risky approach to run a business from it.
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.
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.
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.
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.
One also has to consider the cost of engaging the IT department or others who can do and/or manage development within the organization. That's NOT cheap. Many businesses can barely manage to handle their own shit, let alone successfully do even a small unplanned project to port an excel app running in somebody's cube to something more robust.
I understand where you're coming from, but this is just not good advice. Somebody (I can't remember if it was pg, Joel Spolsky, or someone else) once wrote an entire essay basically saying "DON'T make a startup that's just pivot tables. I have seen so many SaaS startups fail because they didn't realize they were just selling pivot tables at a much higher price than Microsoft wants for Excel."
Also take a look at this HN thread: https://news.ycombinator.com/item?id=12450802 where a whole bunch of people express bafflement of and loathing for people who unnecessarily replace Excel with half-baked software. It seems like a good idea; it's usually not.
Not for a startup, no, but in my experience it works well as a lifestyle business. Companies pay well for this kind of work and it seems the number of spreadsheets they want to have replaced provide enough work for the next few decades to come. Better the replacement isn't half-baked though...
True, but you also have to make sure that you can improve on the spreadsheet way enough to be worth potential customers' switching cost and money.
I actually wrote a post about exactly this only a couple of weeks back: "Your biggest competitor is a spreadsheet" - https://medium.com/@hjalli/your-biggest-competitor-is-a-spre...
- one spreadsheet is shared among more than about 5 people (or they each have their own version of it... shudder)
- the sheet has more than about 10,000 rows
That's the point where Excel truly starts to be not the right answer.
We have rather low requirements, which is why I'm resisting existing shop systems. They all seem like overkill to me.
But from time to time, someone wants a some statistics, or needs to send emails to "everyone who bought in the last four weeks". These are trivial for me to compile in SQL, but a spreadsheet would allow others to quickly work with the data.
Unfortunately, the Sheets API at around one second per request was too slow for my tastes when I last checked it out.
I agree this is a good place to look. I'm not sure a new tool will be an improvement as it will always have limitations and a learning curve Excel doesn't have.
Which is not to say that whatever replaces it is guaranteed to be better, but it will at least have a good start by using the right tools for the job.
What happens when this person leaves? What if business starts booming and you need to scale up? Are you really better off sharing a spreadsheet between a 100 or more people?
Just gonna focus on this part here. The last offices I worked in (and the last places I even dealt with tech stuff beyond teaching it to primary-schoolers), "Track Changes" was simply a godsend. One person "owned" the spreadsheet and could allow use or not; and we had it hosted on OneDrive - of course we all had the OneDrive client on our work PCs and it could tie into Excel natively, so we were all using the same document.
If the entirety of a large org needs the same spreadsheet, you're probably looking at a scenario where they really need multiple sheets, but haven't figured out how to do references to other files and sheets yet. But using Track Changes and having one person designated as Owner so that that one individual makes a decision to approve/disapprove all potential changes makes it much easier to let multiple people work together.
> What happens when this person leaves?
That's a management / succession-planning issue. Ad-hoc solutions shouldn't be kept secret, and allowing employees to just go off and do as they please in that regard is a major issue. If all work-related documents are required to be stored in the company cloud, and you storing a new doc alerts your manager, etc., you'll be able to deal with this much easier. One place I worked for a few weeks on a project did a reset on employee's terminals every Friday at around 7PM, and anyone who claimed they lost data or progress from that on Monday was in trouble, because they didn't save company-related data to the document & data server (which obviously did not get reset) - meaning they'd done something against company policy that they'd been told about the day they were hired.
I’m allergic to the over-engineered solutions so prevalent.
We sometimes even propose to build a native Excel based VBA app. The users can always use something like Dropbox sync or box sync on Google Drive sync to share their work with others.
Think of all the would-be SaaS businesses that have been disrupted by Airtable.
I've once worked with a trader whose magic sauce was encoded a spreadsheet he had been developing and carrying around for 10 years. It had tens of thousands of formulas and references cross ~50 sheets.
He suspected he had introduced an error somewhere, but gave up after a couple of months of trying to, you know, verify the whole thing.
When you have error-prone processes that you do hundreds of times a day based on those spreadsheets, that a bigger application can automate.
When ten of those spreadsheets could really be replaced with one.