The problem
Scoperly Studio runs in the office: a server on one computer, desktop clients on the others, all on the office network. There is often no IT department, and “first install Java, then PostgreSQL, then Docker” is where such a product loses its customers.
Everything in one installer
The Windows server installer brings its own Java runtime and its own PostgreSQL, set up as private services on their own port, so nothing else on the computer is touched. Each component is pinned to a checksum when the installer is built, and a mismatch fails the build.
Running it again is a repair
Setup is written so that it can run twice. Existing secrets, data and services are reused, so the installer that installs is also the one that repairs. It checks that the database tools can start before it touches anything, and it waits out what a fresh Windows does on its own, such as an installer already busy with updates.
Updates that can go back
An update starts with a backup of the database. If the new version does not come up healthy, the previous one is put back. A system like this is trusted with the day’s work, and an update must never be the reason that work stops.
Sync that expects a bad connection
Offices sit behind routers and lose their connection. So Studio pulls changes from the cloud through the Connect API instead of waiting to be called, and the office keeps working on its own network in the meantime.