What we commit to — and what that means in practice.

Codebase ownership

What was built for you is yours, on delivery.

All source code, configuration, and documentation produced during your engagement is transferred to you according to the terms of your engagement. There is no arrangement where pyes.software retains rights over your domain models, workflows, or business logic.

What is transferred: full source code, version history, environment configuration, deployment scripts, and module documentation. Nothing is held back.

When it transfers: at the close of each agreed delivery phase, before the next phase begins. You are never waiting on ownership.

Intellectual property: the specific encoding of your operations is your intellectual property — your particular quoting rules, your pricing structures, your job lifecycle definitions, and any business logic derived from how your business works. General knowledge of how quoting, workflows, or pricing logic work is not owned by anyone; what is yours is the precise implementation built around your data structures, domain assumptions, and operational decisions.

What pyes.software may and may not reuse: generic abstractions — frameworks, patterns, and modules that can be demonstrated to function independently of your domain, data structures, and workflow assumptions — may be reused in other systems. Anything that is specific to your domain or reconstructable as your business logic is never reused.

No vendor lock-in

Built so any competent team can continue it.

We do not build on proprietary platforms, bespoke frameworks, or toolchains that require our ongoing involvement to operate or extend. Every system is built with documented, widely-supported technologies and clean module boundaries.

What this means in practice: after handover, you can work with any developer — internal or external — to maintain, extend, or migrate the software. You are never dependent on pyes.software to keep your operations running.

What this does not cover: third-party services your system integrates with (ERP platforms, cloud providers, payment processors) have their own terms. Lock-in to those services is outside pyes.software's control.

Data ownership

Your data is yours. Always.

All operational data generated or stored by the software we build belongs to you. We do not retain, analyse, or share client operational data for any purpose beyond delivering the project. Access to any data environment is revoked on project close unless explicitly continued by you.

During development: access to test and staging data is limited to what is necessary for delivery. Production data access is only used when explicitly approved by you for a specific task.

After delivery: data schemas, storage configurations, and database credentials are documented and transferred alongside the codebase. You have full control from day one.

Handover & documentation

Documented so any developer can pick it up.

Every module includes written documentation covering its purpose, data model, integration points, configuration requirements, and known edge cases. The goal is a codebase that a developer unfamiliar with your project can understand and extend without needing to contact pyes.software.

Documentation is produced during delivery, not after. It is reviewed and approved as part of each module handover — not added as an afterthought.

Transparency & governance

You are kept informed at every stage.

Client visibility is maintained throughout delivery. Progress is reviewed regularly, decisions are logged, and risks are surfaced early — not after they become problems. You are never left wondering where your project stands.

What gets escalated: any change that materially affects cost, timeline, architecture, or user-visible behaviour is surfaced and documented before being acted on. Material means a cost impact greater than 10%, a timeline impact greater than 2 weeks, or a change to module boundaries, integration patterns, core data model assumptions, or compliance-relevant outcomes.

What is handled in normal flow: routine low-impact implementation decisions are handled within normal engineering delivery without formal escalation. Only changes that meet the materiality criteria above require a documented sign-off before proceeding.

Privacy & security posture

Privacy-first by design, not by compliance checkbox.

We build internal software, not consumer platforms. Every system is designed with a minimal data collection posture: only the data your operations require is captured, stored, and surfaced. We do not introduce telemetry, analytics pipelines, or external tracking into the systems we build unless you explicitly need them.

Architecture defaults: access controls scoped to role and function, no unnecessary external service dependencies, data stored in your infrastructure or a provider you choose and control.

What we do not cover: compliance certification (e.g. ISO 27001, SOC 2) is outside scope unless explicitly contracted. Security architecture principles are applied by default; formal audit engagements are separate.