Skip to content
KramviaTECHNOLOGIESTalk to us

Local-first ERP

Designed around the pharmacy location.

Kramvia ERP uses a local-first design: the location service and database are authoritative for local operational records. This architecture supports the goal of reducing dependence on cloud connectivity for daily work, with deployment and recovery validation still required.

FOLLOW THE WORKFLOW

See how the work fits together.

  1. Run operations on the location service
  2. Keep records local & permissioned
  3. Agree backup responsibility
  4. Demonstrate a restore

FICTIONAL WORKFLOW EXAMPLE

A local database is not a backup plan

A fictional single-location pharmacy runs its daily work against the local service and database. That design reduces dependence on a cloud response for each action, but it does not by itself protect the business against a failed disk.

Local-first describes where the authoritative operational records live. LAN/TLS hardening, a signed installer and a measured restore drill remain release gates.

Keep local work grounded in local records

The ERP core stores operational, accounting and audit data in a location-scoped service. Permissions determine which records a user can access.

  • Use the agreed location and distributor scope.
  • Keep transactions linked to their accounting records.
  • Validate the intended hardware and user workflow before rollout.

Treat connectivity and recovery as separate responsibilities

A local database does not remove the need for secure deployment, backup and tested recovery. LAN/TLS hardening and a measured restore drill remain release gates.

  • Agree the local server and network configuration.
  • Define backup responsibilities and key custody.
  • Demonstrate recovery before making continuity promises.

Do not assume complete central synchronisation

Delivery components exist, but configured external delivery and complete central synchronisation are separate work. Local-first should not be marketed as a finished all-location cloud platform.

  • Confirm required multi-location views.
  • Agree remote-access and synchronisation requirements.
  • Keep current capabilities distinct from future integrations.

Questions about local-first operation

Does local-first mean the system works offline indefinitely?

No offline uptime guarantee is made. The design reduces dependence on cloud connectivity for local operational work; deployment, network and recovery validation are still required.

Is data synchronised across locations automatically?

No. Delivery components exist, but configured external delivery and complete central synchronisation are separate work. Confirm any multi-location or remote-access requirement explicitly.

What to bring to the discussion

  • Locations, expected users and local hardware.
  • Network and remote-access needs.
  • Backup ownership and recovery acceptance criteria.
Discuss your requirements