How we handle your systems and data
Manufacturers give us access to the systems that run their business. This page sets out how that access works, what we commit to in writing, and what stays with you when the work is done.
How access works
Data moves one way: from your systems into the software we build. Write-back to any system is a separate project, scoped and approved in writing.
Your systems
Your ERP, SQL Server or PostgreSQL databases, production records, approved exports and supported APIs. They keep running as they are.
Read-only adapter
A read-only account on one approved source to start. It reads. It does not write back.
Validated and logged
Every load is checked, logged and reconciled against the source before anyone relies on it.
Manufacturing data model
Jobs, labour, inventory and costs in one model, on infrastructure you approve.
Your apps
Portals, floor tools and customer views, each with role-based access.
What we commit to in writing
The same for every client and every project, before any work starts.
- Access
- Read-only access to one approved source to start. Write-back to any system is only ever a separately scoped project.
- Credentials and hosting
- Agreed in writing before work starts, along with backups and who is responsible for each.
- Security controls
- Secrets handling, role-based access, audit logging and backups are standard in every build, not extras.
- Infrastructure
- Preferably your own, for a clean handover and no lock-in.
- Your data and AI
- Your data is not used to train any model without your written consent.
- Ownership
- Your data, configuration and agreed deliverables are yours. Our reusable foundation is licensed to you, with exit terms in the contract.
- Scope and price
- Fixed scope, price and acceptance criteria, in writing, after the audit. No open-ended retainers.
What we ask of your IT team
Little, and nothing open-ended. The audit confirms each item before a build is scoped.
- Read-only credentials
- For one approved source to start. More sources are added only when a later scope covers them.
- Somewhere to run it
- A server or cloud account you own is preferred. Where it runs is agreed in writing before work starts.
- A named approver
- Usually your operations lead, who agrees the KPI definitions and signs off the figures.
- Time for reconciliation
- A short session with your team to check the numbers against your systems before handover.
What you hold at handover
Preferably on your own infrastructure, so there is nothing to migrate if you stop working with us.
- Documented deployment
- How it is installed, configured, scheduled and backed up, written for your team.
- Data mappings
- Which source fields feed which figures, and the KPI definitions you agreed.
- Access
- Role-based access configured, with credentials held by you.
- Exit terms
- Written into the contract, so your own team can run the system without us.
What we do, and what we don't claim
We do
- Read your systems, and write only when a separate scope says so
- Reconcile every figure against source before sign-off
- Put scope, price, access and exit terms in writing
- Hand over a documented system your team can run
We don't
- Present our audit as a cybersecurity assessment or penetration test
- Claim certifications we don’t hold
- Use your data to train any model without your written consent
- Replace your ERP, MES or IT provider
If your procurement process needs a security questionnaire, raise it on the discovery call. Engagement handbook
Have a problem worth building software for?
Start with a free 20–30 minute discovery call with the engineer who would build it. If there's no project worth doing, we'll tell you.
On the call
- The problem that costs your operation most
- Your ERP, databases and spreadsheets
- Whether a fixed-fee audit makes sense
- A straight answer, even if it is no