As a teenager I worked at a company that rented rafts for a short trip down a river. We’d take the rafts from the customers at the end and truck them back up to the start. As they became bigger and busier, it became more important to keep track of the status of rafts and know when they were going to be getting back to the top.

They paid tens of thousands to have software made for this purpose. It sucked and was totally unable to handle the simultaneous realtime access and modification that was required.

They knew I was good with computers, so asked me if I had any ideas. In about an hour I made them a Google Sheet that worked great for the next several years until I left.

I've just spent a few weeks making a tool in our software to replace a complicated google sheet, and it was surprisingly hard. I think the most important thing was that our designer really figured out what the tool should do. If we've just replicated what they have and made a columnar editor of sorts, we would've just made a less flexible tool for them. But in the end, we made something not even resembling what they had, but which actually solved the core issue, and I think that's important.

And when you take away their sheet, you better be ready to support them. If they need to track new data, they could just add a new column in their sheet. Now they have to talk with tech. If tech blocks operations, they're quickly back to their sheets. The tool made by tech should be an enabler, not something to force compliance or whatever.

Sheets are so, so flexible. This can be really hard to replace. At the same time, they're also brittle with little system support. Like the example above, what if you assign someone not working that day to a boat? Or accidentally put two boats in the same location? Lots of small issues that proper tooling could handle, especially when backed with more data inside the system.

What made the operators happy to use my tool in the end was that they didn't have to punch so many numbers. They would copy paste numbers from various systems into their sheet every hour to keep track. The tooling pulls it in real-time.

So we replaced this one sheet, because it would help them a lot. But their other sheets we're leaving untouched for now. Nothing to gain by moving them. So judge each sheet individually.

My startup used Google Sheets as a CRM until we discovered there’s a 3 million row limit (by running into it) and had to build something else. Sheets is amazing. Don’t forget to lock that first header row, though.

I'm there with you... maybe, maybe using the sheets API to create a simpler front end for very specific use cases, like an individual seeing their assignment for the day, or maybe texting everyone that info.

As much as people will rely on databse (rdbms/sql) backed applicatons, in the end a lot of the business world runs on spreadsheets... Not only that, but excel, and I'm assuming plenty of others have integration points for pulling data from other resources... Spreadsheet masters can do very impressive things with what appears to be a simple tool.

I've seen suppliers using google sheets for a list of tens of thousands of items. Also color coded and filterable and what not. It worked. I could access it programmatically, I had no complaints. (Especially with an experience of some of these suppliers having shitty hosts and shitty platforms and their massive XMLs taking forever to load.) Then again I'm sure I would speak differently if someone just decided to rename a column randomly :D

We have no idea if its a good solution or not. It depends upon, among other things: how long it takes to update it, the error rate, and how acceptable those errors are.

All fun and games until an Intern deletes the original sheet or fatfingers critical information.

[dead]

[dead]