Compare
Faber vs building it yourself.
You could build this, and the first working version really is an afternoon. The question is who keeps it working after that, when a field gets renamed and the job quietly stops doing anything.
| Faber | Your own build | |
|---|---|---|
| First working run | Minutes, and you read a preview of it before it is real. | An afternoon, if the APIs are friendly. |
| Auth and tokens | Handled. You connect an account and approve the access. | OAuth clients, refresh, revocation, and secret storage, per provider. |
| When a provider changes | The connection is maintained for you. | You find out from a user, or from nobody at all. |
| Approvals | Built in. Mark any action to require your approval after each run. | Another feature to design, build, and put a UI on. |
| Where it runs | On our servers, whether your machine is on or not. | A box, a scheduler, and something watching the scheduler. |
| Who can change it | Whoever owns the work, in plain words. | Whoever wrote it, and only while they still work here. |
| Adding the tenth one | The same afternoon as the first. | Ten things to keep running, and they are not the job you were hired for. |
| Pick this when | The work is standard business plumbing across common apps. | It touches your own systems, is core to the product, or nobody else could ever run it. |
The real comparison
The question is who maintains it.
A script that works is not the deliverable. The deliverable is work that still happens in six months without anyone thinking about it. If that is going to be you, build it: you will do a good job and you will know exactly how it works. If it is going to be somebody who does not read code, and who will not know it broke until the money does not arrive, that is the case for Faber.
See what it builds before you decide.
Describe a task, read the preview run, and judge it on the output.