51 tables and 12,039 rows rescued,
then an ERP the factory runs on daily
A supplements factory lost access to its production and stock ERP on a third-party cloud. We exported everything through the API (51 tables, 12,039 rows), rebuilt it self-hosted on PostgreSQL and PostgREST, hardened access with database roles and JWT, translated 3,040 interface strings, added cost accounting, plan-versus-actual reports and Excel exports, fixed a double write-off bug and set up daily backups.
The situation
A factory’s production and raw-material accounting lived in a cloud backend set up by a departed contractor. Access was gone, data was at risk, and production could not stop.
What we did
Recovery. Restored access, exported all 51 tables and 12,039 rows through the REST layer, including 161 MB of photos stored inline, and verified counts.
Rebuild. A self-hosted stack on a separate isolated server: PostgreSQL, PostgREST and nginx, no third-party SaaS. Full technical documentation with line-by-line comments on the inherited code.
Hardening. Role-based access moved from the client to the server: PostgreSQL row-level roles and an RPC login with JWT. 42 of 50 admin pages visible to the new roles, 8 restricted by design.
Language. A runtime translator turned about 3,040 Thai strings into Russian and English for the new management.
Features. Cost of goods per raw material, per kilogram and per unit; Excel exports from more than seven screens and an “export all” report; plan-versus-actual, labour, rent and depreciation reports; cost printed on production forms; a stock audit that restored 44 material cards and removed 71 orphaned ones; a double write-off bug found on two production orders and corrected with explicit approval.
Operations. Daily database backups with a mirror off-site. The system is used by the factory every day, with changes requested and shipped almost daily.