This is the reason we have desktop computers. Lotus 123 (and then Excel) enabled ordinary folks automate bits of their jobs.
But it went through a pattern:
- Spreadsheet was created to help do task X
- Spreadsheet grew until task X was entirely contained in the spreadsheet
- New hires were trained to just use the spreadsheet instead of understanding the task
- The person who built the spreadsheet left the department
- The business needed a change in the task, and that meant changing the spreadsheet. But no-one in the department knew how the spreadsheet worked any more.
- The IT department gets a new urgent task to change the spreadsheet to allow for the change in the task. The spreadsheet is a complete mess of spaghetti, evolved over years with no documentation. It will take months of work to untangle it and make the necessary changes (and document it for next time). The developers pitch that they could build a VB app for the task in less time than solving the spreadsheet and that would improve the situation going forward.
- The IT department kicks off a project to build the VB app. Immediately the business department adds a ton of loosely-related requirements because they've always wanted them in the spreadsheet but no-one knew how to add them.
- The project founders under its own bloated weight, scope creep moving it from a couple months out to a year's project.
- Meanwhile the business department works out another way of doing the task
- 18 months later the IT department delivers the app as promised. But it's wildly out of date with what the business department is doing now, so no longer fits the use case it was designed for.
I've seen this happen a few times. It'll be the same with Zapier-derived solutions - in two years you'll have left the organisation and then an API changes and the thing you built falls apart, no-one knows how to fix it, and devs don't want to look at it. Everything is more painful this way. It's worth its weight in gold until suddenly it turns to shit.
But it went through a pattern:
- Spreadsheet was created to help do task X
- Spreadsheet grew until task X was entirely contained in the spreadsheet
- New hires were trained to just use the spreadsheet instead of understanding the task
- The person who built the spreadsheet left the department
- The business needed a change in the task, and that meant changing the spreadsheet. But no-one in the department knew how the spreadsheet worked any more.
- The IT department gets a new urgent task to change the spreadsheet to allow for the change in the task. The spreadsheet is a complete mess of spaghetti, evolved over years with no documentation. It will take months of work to untangle it and make the necessary changes (and document it for next time). The developers pitch that they could build a VB app for the task in less time than solving the spreadsheet and that would improve the situation going forward.
- The IT department kicks off a project to build the VB app. Immediately the business department adds a ton of loosely-related requirements because they've always wanted them in the spreadsheet but no-one knew how to add them.
- The project founders under its own bloated weight, scope creep moving it from a couple months out to a year's project.
- Meanwhile the business department works out another way of doing the task
- 18 months later the IT department delivers the app as promised. But it's wildly out of date with what the business department is doing now, so no longer fits the use case it was designed for.
I've seen this happen a few times. It'll be the same with Zapier-derived solutions - in two years you'll have left the organisation and then an API changes and the thing you built falls apart, no-one knows how to fix it, and devs don't want to look at it. Everything is more painful this way. It's worth its weight in gold until suddenly it turns to shit.