It looks like Shaper continually saves data to a database as you work rather than relying on the user to click a save button to update a local file. As a former software developer who has used this method of saving project work, I can say it works great until the unthinkable database corruption happens, then the user loses all project data all at once. With the cloud sync you would still be protected from this scenario possibly, unless the sync transferred the same corrupted data to the cloud and corrupted it as well. Is there any kind of local database redundancy to protect against DB file corruption? Also, where is the DB file located so I can add it to my backup service?
There are a few advantages to individual file based data storage that would be good to emulate somehow. Data isolation between projects so that the situation above can’t wipe them all out at once is one advantage. Another advantage when working with files is if I botch something up in the current project to a point where undo or anything else can not recover the model to its former state before the FUBAR operation, there is always the option to close the file without saving so that the last known good state can be opened again. Or sometimes I will try an experiment that might screw up the model and I’ll save before doing it so that I can reload the saved version if I mess things up beyond repair. With continual database updates while working, any model breaking mistake is instantly made permanent. If I thought I was about to break something, I would have to export to Shaper format before trying an experiment, then if I needed to recover I would have to open a new project and then import the saved model. Even if that works it is an inconvenient multi-step process that is going to result in a cloned project showing up in the project list.
Some kind of user initiated entry into a version history that could be restored would be a cool feature. With support for multiple restore points that would be even better than the file based method of recovery, which can only recover to the last known working state.
Maybe this is all too complex for how often your average users would need it, I’m just spit balling ideas. But knowing where that DB file resides would allow me to use the version history of my backup service to get out of a bad situation if needed.