No Export Button? No Problem. How I Used Cursor AI to Break Vendor Lock-in (Harvest Backup Tool)
In the past, the conversation was over at this point. The SaaS vendor in question doesn't provide an automated backup or export for our data, and that is it. The reason for our capitulation in face of the sad facts is that creating a backup tool for every single SaaS vendor we use was simply way too expensive and not feasible.
Today, with the friendly help of LLMs and vibe coding, the conversation is not over and we can simply help ourselves. Many SaaS offerings do have APIs and grant low-level access to our data, they just didn't bother to implement a backup and restore function.
For LLMs, create a tool to download all data via the API based on the documentation is one of the more simple problems to solve. Especially if the SaaS application is not overly complex and the data fairly simple. Creating a backup tool takes just a few hours of background vibe coding, which means that I only need to look at it from time to time while keeping the coding agent busy.
Why SaaS Vendors Don't Create Backup Tooling
In all honesty I don't know, however I can offer a very simple theory: The market currently doesn't put enough demand on exit strategies, data sovereignty and backup tooling when selecting SaaS vendors. Functional requirements typically beat all and any lacking non-function requirements. SaaS vendors are often selected by business units and not by IT departments, so again all the boring "we need this for proper operations" stuff gets forgotten, overlooked or de-prioritized. Also, as a SaaS vendor you measure your success by the amount of customers you attract and manage to hold, not by the ease of migrating away to another SaaS vendor.
As a result, there is literally no or very little business and market incentive for SaaS vendors to make it easy to take our data with us, while there is a lot of market incentive for the SaaS vendor around making onboarding and importing data as easy as possible.
If you read this and work at a SaaS vendor, please do reach out to me and let me know of the true reasons. I'll be happy to update this text accordingly.
An Example: Harvest Time Tracking
At Tektit Consulting, we use Harvest for time tracking and this is a SaaS application. Harvest is very typical as it doesn't offer a backup or export, but they do offer complete access to all our data via API. The API is well enough documented, even if it lacks an official specification. Luckily, an Open Source project exists already to provide OpenAPI spec file for the Harvest API. The API essentially provides direct CRUD access to the underlying data tables without much business logic getting in the way.
It took me a couple of hours of my own attention over the course of two days to motivate Cursor AI into creating our very own github.com/tektit/getharvest-backup tool. I was able to do this as a background task, letting the agents work while I do other stuff. From time to time I came back to try it out and give direction. The tool now works as a Docker container and runs on our backup server to pull nightly backups of our time tracking data. A typical run looks like this:
docker run --rm -t \
-u $(id -u):$(id -g) \
-e HARVEST_PAT=your_personal_access_token \
-v $(pwd)/backup:/backup ghcr.io/tektit/getharvest-backup:latest
[20:20:13] INFO Starting backup of all Harvest accounts...
[20:20:13] INFO Discovering Harvest accounts...
[20:20:13] INFO Found 2 Harvest account(s)
[20:20:13] INFO - Account 12345: Test Company
[20:20:13] INFO - Account 67890: Another Company
[20:20:13] INFO Backing up account 12345 (Test Company)...
[20:20:13] INFO Completed backup for account 12345
[20:20:13] INFO Backing up account 67890 (Another Company)...
[20:20:13] INFO Completed backup for account 67890
[20:20:13] INFO Backup completed successfully
[20:20:13] INFO ✓ Backup completed successfully
See the project homepage for more usage details, it only requires a Harvest token to work. To be honest, after this fairly short time I ran out of ideas what to implement. The code even has decent test coverage and skimming over it looked "good enough". I spent most of my time on validating that the backup data is actually correct 😁
I did not implement a restore for the backup data because
- the data is just plain JSON files that can be restored even manually via a PUT or POST to the API. That means that restoring our data back into Harvest is super simple and straightforward, it doesn't even need specialist software, plain curl is enough.
- the backup data is complete in the sense that it has all our customers, projects, and time tracking items. While it is in the specific format of the Harvest API, it is sufficiently self-explanatory to easily convert into any other format and doesn't depend on internal Harvest details. That makes the backup data future proof and usable without Harvest.
- we can safely postpone the creation of a restore tool to the time that we actually need it. ATM I don't even know into which service (SaaS or on-premise) I would want to restore my data.
Given the power of LLMs and AI-based coding, I think it would be a waste of time to create a restore tool for Harvest right now. Instead, we'll create the restore tool when we have the restore problem and once we know where we want to continue tracking our time after Harvest. Probably a future LLM will be even better at writing such code, so again it would be wasteful to do so now before we need it. For now it is enough to note that the data is complete and can be useful without the Harvest tool.
Conclusion: SaaS Backups Made Easy with Custom Software
In conclusion, we can observe a major shift happening in our reality: Previously we stayed as a victim to the product policy of SaaS vendors and simply accepted the lack of a true backup as a necessary price to pay. Now we can take matters into our own hand and simply create the missing backup tool and take back full ownership of our data.
The effort to create the missing tooling was low and cheap. The risk of losing all our time tracking data, which is the foundation of our invoicing, is much higher and the impact of losing a full month worth of time tracking would be much more expensive than the couple of hours that I spent once on creating a backup tool.
This significantly reduces our risks of losing our own data and solves, for this example, the conflict between enjoying the benefits of SaaS solutions while retaining full data sovereignty.
Welcome to the new age of disposable code that comes in to solve real business problems at a bargain rate. Let's all take back control of our own data and use backups as the first step towards better data sovereignty. With this approach we are sure to be able to recover from a SaaS vendor failure our outage and to continue our business operations quickly in case of need.
We at Tektit Consulting are specializing in IT strategy, compliance automation and achieving true sovereignty. We'll be happy to assist you in assessing your own SaaS vendor landscape and implementing your data sovereignty or SaaS exit strategy. If tools are missing, we'll simple create them for you as Open Source to make the world a better place for all users.


Comments
Post a Comment