One API, three clients
Web, iOS and Android all speak to the same Go API and see the same records. There is no mobile-only subset and no separate sync database to reconcile.
Under the hood
Built to be run for years, not demonstrated once
RampWorks is a conventional, boring, durable stack on purpose. A compiled Go API, PostgreSQL, one client codebase across three platforms, and deployment as versioned containers.
Principles
Decisions that shape the product
Authorisation on the server
Role, station and provider scope are enforced in the API, not in the interface. Hiding a menu is a convenience; the API refusing the record is the control.
Tenant-ready by design
Stations, provider companies, roles and reference data are workspace-owned, and tenant branding is configuration rather than a fork.
History is kept, not overwritten
Work-order status changes, checklist edits and stock movements are recorded as history with an actor and a timestamp, so a record can be explained months later.
Migrations, not manual schema changes
Every schema change ships as a numbered migration that runs on deploy, so environments cannot drift apart quietly.
Portable deployment
The whole platform is containers and a database. It runs on a single well-specified host or a managed platform, and moving between them is a deployment change, not a rewrite.
Fitting into what you have
Getting data in and out
Most operations arrive with a register in a spreadsheet and a reporting habit built around one. RampWorks meets both rather than demanding you abandon them.
Bulk import
Assets, work orders and checklist items all import from XLSX or CSV against a template you download from the module itself. Imports upsert, so a corrected sheet can be re-uploaded.
Scheduled PMI generation
Due-work-order generation is an idempotent operation designed to be driven by a scheduler for unattended nightly running.
Structured exports
Excel and CSV exports carry the on-screen filters, which makes them a practical hand-off into whatever analysis or finance system already exists.
11Modules in the workspace
1API serving web, iOS and Android
3Scoping layers enforced server-side
PDF + XLSXExport formats across the operational modules
Operations
Run as versioned releases
Each release is built as container images pinned to a specific commit and rolled out together with its database migrations. A rollback is a tag change rather than a rebuild, and every build is scanned before it is published.
Scanned before publish
Secret detection, dependency and static analysis, container scanning and an SBOM run ahead of every image push.
Migrations with the release
Schema changes are numbered and applied on deploy, so the database and the binary never disagree about shape.
Backed up on a schedule
Database backups run nightly, and restores are a documented procedure rather than an improvisation.
See RampWorks against your own fleet
Tell us how many stations and how much equipment you run, and we will walk the workspace through your operation rather than a demo dataset.