00About us
An IT company built around
engineering discipline
TER MOTTE develops custom software, web and mobile applications, cloud platforms and the infrastructure around them. We work with organisations whose operations depend on software behaving correctly, and we stay with those systems after the first release.
01Mission
Software that removes friction
Our mission is to build software that makes an organisation's daily work simpler and more reliable. That means understanding the process before proposing a system, designing for the people who will use it every day, and delivering something that can be operated and changed without depending on us.
02Vision
Systems that stay maintainable
We want the systems we deliver to remain understandable and adaptable long after they are launched. Software rarely fails at release; it fails when it can no longer be changed safely. Our vision is a practice where clear architecture, tests and documentation make change routine rather than risky.
03Values
Five commitments
- 01
Clarity
Plain language in estimates, status and technical explanations. If something is uncertain, we say so and describe what would remove the uncertainty.
- 02
Craft
Code is written to be read, tested and changed by people who were not in the original conversation.
- 03
Responsibility
We stand behind what we deliver, including the parts that only become visible under production load.
- 04
Restraint
We add complexity only when a requirement demands it. Fewer moving parts means fewer failures.
- 05
Continuity
Documentation, handover and access are prepared so a system can outlive any single engagement.
04 Approach to technology
Chosen for the lifespan of the system
We select technology by asking how long the system must run, who will operate it, and what it has to connect to. Established languages, mainstream frameworks and managed cloud services usually win that comparison, because they come with documentation, hiring pools and predictable upgrade paths.
Newer tools are used where they solve a concrete problem better than the alternatives — not as a default. When we introduce something less common, we document the reasoning and the exit path.
We also avoid architectures that create dependency on us. Infrastructure is described as code, credentials and repositories belong to the client, and runbooks describe how to operate the system without our involvement.
05Engineering principles
How decisions get made in the code
- Design the data first
- The data model outlives the interface. We settle entities, relationships and invariants before building screens on top of them.
- Small, reviewable changes
- Work arrives in increments that can be understood, tested and reverted independently.
- Automate what repeats
- Builds, tests, deployments and environment setup are scripted, so results do not depend on who runs them.
- Make failure visible
- Errors are logged with context, surfaced through alerts, and handled explicitly rather than swallowed.
- Prefer boring technology
- Established tools with long support horizons beat novelty in systems that must run for years.
- Measure before optimising
- Performance work starts with profiling and ends with a measured comparison, not an assumption.
06Quality standards
The rules we do not skip
- 01Every change is reviewed by another engineer before it reaches a shared branch.
- 02Automated tests cover business logic, service boundaries and the paths a release depends on.
- 03Static analysis, formatting and dependency checks run automatically in the pipeline.
- 04Staging environments mirror production configuration so verification is meaningful.
- 05Releases are versioned, documented and reversible.
- 06Defects found after release are reproduced with a test before they are fixed.
07Collaboration model
Four ways to work together
Dedicated delivery team
A complete team takes responsibility for scope, architecture, implementation and release of a defined system.
Team extension
Our engineers join your existing structure, follow your process and add specific capabilities where they are missing.
Advisory engagement
A focused review of architecture, code quality, infrastructure or delivery practice, ending in a written assessment with options.
Maintenance agreement
Ongoing responsibility for a live system: monitoring, updates, incident response and planned improvements.
08 Security and privacy
Handled as a requirement
Access to client systems is limited to the people who need it, granted for as long as the work requires, and revoked at the end of an engagement. Credentials are stored in managed secret storage, never in code or documents.
Systems we build apply least-privilege permissions, validated input, encrypted transport and storage where appropriate, and dependency updates on a schedule rather than on incident.
We design for data minimisation: a system collects what it needs to function, stores it where it is documented to be stored, and provides a defined path for retention and deletion.
Client information shared with us during an engagement is treated as confidential and is not used for any other purpose. Details of how this website and our applications handle data are set out in the Privacy Policy.
09Contact information
Get in touch
- Company
- TER MOTTE
- [email protected]
- Website
- termotte.com