PWA
Responsive web app, installable on the home screen without making the app store a hard dependency.
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.
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.
Security & control
Easy to use does not mean loose access control.
Explicit permissions, tenant boundaries, traceable approvals, revocable integrations and recovery paths appropriate to the actual risk.
Capabilities
Permissions represent concrete actions. “Manager”, “office” or “field worker” are bundles, not hard-coded security models.
Tenant isolation
Customer organisations require server-side data boundaries; hiding UI elements is never sufficient access control.
Audit
Important changes and approvals can record actor, timestamp and context for later review.
Least privilege
Users and integrations should receive only the access required for their agreed task.
Revocable access
OAuth, scoped tokens and renewable credentials are preferred over unnecessary password sharing.
Recovery
Backup, restore, error handling and controlled correction flows are considered according to business impact.
Technical details
Security follows the data and the action.
Offline devices
Only data required for the current work should be available offline. Sessions, device loss, queued uploads and conflict handling need explicit behaviour.
Files & photos
Documents and photos should follow the same organisation and permission boundaries as the job or record they belong to.
Integrations & secrets
Secrets stay out of public client code and normal logs. Expired or revoked provider credentials are part of the failure path.
Messenger approvals
A messenger is never the database. It is a notification/approval channel; the core validates, de-duplicates and audits the actual action.
Simulation
Simulated data remains separate from real operational data, and analytics follows the same tenant and permission scope as daily operations.
System boundary
The company website is not the customer app.
1 · Company sitePublic information, price guidance, references, forms and technical explanations. No production jobs database.
2 · WerkZ appSeparate customer access with login, modules, permissions, offline behaviour and operational records on phone, tablet or desktop.
3 · AdaptersReplaceable connections to calendars, accounting, email, messaging, CRM and specialist systems.
Organisation before job titles
One data model can serve a solo user and larger teams.
“Management”, “office” and “field worker” are interface profiles and bundles of specific capabilities, not fixed data structures. A solo user may create a job, record time, approve billing and see analytics; a larger company can distribute the same capabilities among people, teams, locations and optional organisational units.
Practical mobile limit
iPhone synchronisation must be explicit.
The architecture must not depend on iOS keeping a web app running in the background indefinitely. Important queued work must synchronise when the app opens or is actively used, and failed uploads or conflicts must remain visible. Offline access should contain only data needed for the current assignment.
Data, history and simulation
Operational records and what-if results stay apart.
Customer and job records hold current operational state. Important changes can retain actor, time and context for audit and correction. Analytics derives metrics from tenant-scoped history. Versioned scenarios create separate simulation runs and must not silently rewrite real work. Historical tests must avoid looking ahead at information that was not available at the time.
The abstracted database plus separate file/object storage described above is a target architecture. The current pilot still stores many business and document records in files; an SQL connection alone does not move all those records. Production deployment needs durable storage, backup and a tested restore across every relevant store.
Additional security details
Permissions follow the record and the action.
Identity, capabilities and tenant boundaries
Every operational record needs an organisation context. Server-side checks enforce capabilities; team or site filters add detail but never replace tenant isolation.
Photos, files and retention
Large evidence files belong in appropriate file/object storage, not oversized base64 columns. Access follows the related job and organisation. Retention and deletion depend on purpose and applicable requirements.
Devices and sessions
Device loss, logout, revocable sessions, queued uploads and correction flows need explicit behaviour before customer rollout.
Integrations and secrets
Prefer official revocable access methods with only necessary scopes. Keep secrets out of public client code and routine logs. Test with realistic user permissions and handle expired tokens and provider outages.
Messenger approvals
The messenger is a notification channel, never the source database. The WerkZ core authorises, correlates, de-duplicates and audits the action; repeated delivery must not approve it twice.
Customer control
Customer access, integrations and support access should be revocable. Central, local and existing-system data locations are decided deliberately. Exit, export, retention and deletion are agreed in the project scope.