About us
An engineering company, described plainly.
AVEL VAT designs, builds and maintains software. This page describes how we think and work. It intentionally avoids claims we cannot support: we do not publish invented history, headcount, awards or client names.
Mission
To build software that organisations can rely on and change without fear.
Reliability and changeability are the same problem seen from two directions. A system that cannot be modified safely eventually becomes unreliable, and a system that is unreliable is rarely safe to modify. Our work aims at both at once.
Vision
Engineering work that remains legible to the people who inherit it.
We would like the software we deliver to be readable years later — by a different team, in a different context — with its structure, tests and documentation explaining themselves without archaeology.
Operating principles
Six rules we apply to everyday decisions.
- 01
Understand before building
A requirement is not understood until we can describe the failure cases it implies.
- 02
Small, reversible steps
Change is delivered in increments that can be reviewed, measured and rolled back.
- 03
Write things down
Architecture decisions and trade-offs are recorded so they survive staff changes.
- 04
No hidden complexity
If a solution is complicated, the reason for the complication is made explicit.
- 05
Respect existing systems
Software already in production carries knowledge; we study it before replacing it.
- 06
Say what is uncertain
Estimates state assumptions, and unknowns are named rather than smoothed over.
Approach to technology
We treat technology choices as long-term commitments. A framework chosen today has to be supportable for as long as the software runs, so we favour tools with active maintenance, clear upgrade paths and a wide pool of engineers who know them.
New technology is adopted when it removes a real constraint, not because it is current. When we do introduce something unfamiliar to a client's team, we document the reasoning and make sure knowledge is transferable.
We keep architecture as simple as the problem allows. Distribution, caching layers and abstractions are added when there is evidence they are needed.
Collaboration philosophy
Good software is produced by teams that share context. We work closely with the people who understand the domain, and we expect to ask a lot of questions early rather than to guess and correct later.
Our default is written, asynchronous communication in English, supported by regular short conversations. Progress is shown as working software rather than status percentages.
We can lead a full delivery or integrate into an existing team. In both cases we make our work reviewable: open repositories, readable pull requests and explanations of what changed and why.
Quality standards
Automated tests accompany production code. Every change is reviewed by another engineer. Builds run the full check suite before release, and releases are reproducible. Defects are traced to a cause and, where possible, covered by a test so the same failure cannot return silently.
Team culture
We work in small groups with direct responsibility for what they build. Questions are welcome at any level of experience, review comments are about the code rather than the author, and time is reserved for learning, refactoring and paying down technical debt instead of only shipping features.
Security mindset
Security is treated as part of engineering, not a review stage at the end. We consider data sensitivity and access boundaries while designing, keep dependencies tracked and updated, limit privileges by default, and prefer designs that fail closed. We describe the practices we follow rather than claiming formal certification.
Contact details
Enquiries reach us by email.
- Company
- AVEL VAT
- [email protected]
- Domain
- aveltax.com