Research & methodology

We start from a real operational problem, describe the decision it blocks, and only then design the data model. Domain rules live in the database as auditable actions, so behaviour is identical whether it is triggered from a phone, a shared tablet or a manager's laptop.

• Shadowing real shifts: openings, rushes, closings, deliveries and counts.
• Mapping the paper, spreadsheets and messages a team already relies on.
• Measuring the time cost of each manual reconciliation before replacing it.
• Designing for the worst conditions: noise, gloves, shared devices, weak connectivity.

• Each domain action is covered by deterministic checks before release.
• Calculations (hours, cost, stock value, variance) are verified against worked examples.
• Every release is validated in English, French, Dutch and Spanish.
• Regressions are treated as defects of the method, not of the person.

Feedback is collected from the people who use the platform during their shift, not only from the person who bought it. Requests are grouped by the decision they improve, prioritised against operational impact and published on the public roadmap once accepted.

Modules ship in vertical slices: a complete, usable decision loop rather than a partial screen. Each slice is measured after release — adoption, time saved, errors avoided — and the next iteration is planned from that evidence.

• Access is denied by default and granted per role, per site and per action.
• Writes go through audited server-side actions, never through direct table access.
• Sensitive operations require multi-factor authentication.
• Every change to permissions, data or content is recorded in an audit trail.

• Personal data is collected only when an operational decision requires it.
• Data is scoped to the organization that owns it and isolated at the database level.
• Personal data is never sold, rented or used to train third-party models.
• Retention horizons are defined per data category and enforced automatically.