WerkZ

Technical details

Simple clients on top of a modular operational core.

The public website is marketing and documentation. Customer production data belongs in a separate WerkZ app/PWA or customer instance with its own login, permissions and storage boundaries.

Target architecture

Start as a modular monolith, keep clear internal boundaries.

ClientsMobile PWA · office/desktop · workshop/terminal · simplified management view
Business modulesCustomers · jobs · time · materials · documents · billing · analytics · simulation · approvals
CoreOrganisation/tenant · identity · capabilities · configuration · events/audit · offline/sync · data access
AdaptersAPI · OAuth · webhooks · import/export · email · messenger · maps/GPS · accounting/business systems
PersistenceAbstracted database plus separate file/object storage for photos and documents; simple locally, scalable when hosted.

Mobile & offline

Smartphone-only is a primary use case.

A solo user should be able to work through a separately hosted browser/PWA without owning an office PC. Field use can buffer assigned data and changes locally and synchronise later.

PWA

Responsive web app, installable on the home screen without making the app store a hard dependency.

Offline queue

Local IDs, queued writes and uploads, then explicit synchronisation when connectivity returns.

Conflict handling

Concurrent changes must be visible and resolvable rather than silently overwritten.

Events, analytics & simulation

Operational state plus a structured history.

Events & audit
Important state changes can record actor, time and context. This supports traceability, rework, analytics and later simulation.
Analytics
Metrics are derived from tenant-scoped operational history rather than from marketing pages or private reference dashboards.
Simulation
Versioned rules and scenarios create separate simulation runs. Real operational data is never mutated by a what-if scenario. Historical runs must avoid look-ahead bias.
Messenger approvals
WhatsApp, email or similar channels are adapters only. The WerkZ core authorises, links, timestamps and audits the actual approval action.

Deployment models

Managed cloud, hybrid connector, WerkZ Box or customer-owned infrastructure.

Feature scope and deployment location are separate decisions. Existing customer infrastructure is assessed before new hardware is proposed.

Managed Cloud

No local server requirement. Central operation, updates, monitoring and backups.

Hybrid + Connector

The core remains hosted while an outbound-only local connector reaches explicitly approved local systems.

WerkZ Box

A prepared small appliance on suitable hardware such as a business mini PC or Mac mini. Existing suitable hardware is preferred where practical.

Dedicated / On-Premises

An isolated hosted instance or deployment on the customer's own server or virtualisation environment.

Procurement rule: hardware is not bought speculatively. After technical assessment and customer order, WerkZ either reuses suitable customer-owned hardware, recommends a specific device for the customer to buy, or supplies and provisions the agreed hardware as a separate line item.

Scale path

Solo first, enterprise-compatible – without enterprise complexity everywhere.

One organisation may contain optional units, sites, teams and users. Capabilities are assigned independently from job titles. Larger deployments can later add SSO, stronger isolation, queues, high availability or on-premises operation only when required.