It's astounding how useful and intuitive they are, but my biggest gripe is how easy is for anyone to mess calculations, say, SUM(<RANGE>), by simply adding one row/column/cell.

I use Google Worksheets frequently to track new things that fit into lists/tables, and giving someone else editor access without them knowing a few worksheet nuances means I have to recheck and correct them every month or two.

This happened not so many years ago, in a certain small European nation, where official government housing valuation numbers were incorrect for some years due to a flaw in a spreadsheet.

I remember my apartment got a ~10% bump in value one year due to this flaw being fixed (fix didn't apply to all housing, just those who were on floors 5 or above).

I don't think though that a SaaS would have solved anything here.

Counterpoint: if a small part of the process is getting tweaked, how responsive can the team responsible for these apps be? That’s the killer feature of spreadsheets for business processes: the accountants can change the accounting spreadsheets, the shipping and receiving people can change theirs, and there’s no team in the way to act as a bottleneck.

That’s also the reason that so-called “Shadow IT” exists. Teams will do whatever they need to do to get their jobs done, whether or not IT is going to be helpful in that effort.

It's rare than a third-party SaaS can approximate one of these "core sheets" and most of the exceptions have already been explored over the last several decades years.

You have to remember that an SaaS, just like shrink-wrap software, reflects someone else's model of of a process or workflow and the model and implementation evolve per the timeline/agenda of its publisher.

For certain parts of certain workflows, where there's a highly normative and robust industry standard, like invoicing or accounting or inventory tracking, that compromise is worthwhile and we've had both shrink-wrap and SaaS products servicing those needs for a very very long time. We see churn in which application is most popular and what it's interface and pricing look like, but the domains being served have mostly been constant (mostly only growing as new business lines/fashions emerge and mature).

Most of the stuff that remains in a "core sheet" could benefit from the attention of a practiced engineer who could make it more reliable and robust, but almost always reflects that the represented business process is somehow peculiar to the organization. As Access and FoxPro and VBA and Zapier and so many tools have done before, LLM coding assistants and software building tools offer some promise in shaking some of these up by letting orgs convert their "core sheets" to "internal applications".

But that's not an opportunity for SaaS entrepreneurs. It's an opportunity for LLM experts to try to come in and pitch private, bespoke software solutions for a better deal than whatever the Access guy had promised 20 years ago. Because of the long-term maintenance challenges that still plague code that's too LLM-colored, I wouldn't want to be that expert pitching that work, but it's an opportunity for some ambitious folks for sure.

> a lot of core sheets I see in businesses need more structure round them

We had this decades ago, it was called dBase, but FoxPro (pre-Microsoft) was great too. Visual For Pro or MS Access were a brutal downgrade of every good aspect of it.

Imagine if today some startup offered a full-stack(TM) platform that included IDE, a language with SQL-like features, visual UI designer, database; generated small standalone binarires, was performant, and was smaller than most web homepages.

There are modern options, like Servoy or Lianja, but they're too "cloudy" to be considered equivalents.

Edit: seems like there's OpenXava too, but that is Java-based, too hardcore for non-professional programmers IMO. The beauty of xBase was that even a highschooler could whip out a decent business application if the requirements were modest.

Programming in a spreadsheet is an anti-pattern. Does anyone review your workflow? Write tests for it? Use a real programming language; a notebook at least.

Streamlit apps or similar are doing a great job at this where I'm at.

As simple to build and deploy as Excel, but with the right data types, the right UI, the right access and version control, the right programming language that LLMs understand, the right SW ecosystem and packages, etc.

maybe the strategy in those cases is to augment the core spreadsheet with tools that can unit test it and broadcast changes etc

I disagree. I have seen many such Excel applications in many companies, paticularly in the finance and controlling departments that were delivering key numbers to the C-class which would never have allowed the sheets, applications or calculations out of the house, let alone to a cloud service or an out-of-company consultant/programmer. There were always backups managed by the department themselves and in one case, even entry to the room with the relevant machine was restricted to authorised personnel only. If I have learned anything in my 30 years of consulting, it's that you always take Finance at its word when they tell you No to your SaaS or ERP solution.