Page 01
Home / About Us
An engineering practice, described plainly
VED MANAGEMENT is an IT company that builds and maintains software systems. This page describes how we work and what we hold ourselves to — nothing here is a claim we cannot demonstrate in an engagement.
Introduction
We were formed around a simple observation: most software problems in established organisations are not problems of ambition but of maintainability. Systems get built quickly, then become expensive to change. Our work concentrates on the opposite outcome — software that remains understandable and safe to modify over time.
Engagements are staffed with small, stable teams that stay with a system rather than rotating through it. Clients speak directly with the engineers responsible for the code, and decisions are recorded so that context survives beyond any individual.
Mission
Build software our clients can operate without us
We deliver systems together with the documentation, tests and infrastructure definitions needed to run them. Dependence on a supplier is a risk, and reducing it is part of a good delivery.
Vision
Engineering treated as a long-term commitment
We want to be judged by how the systems we build behave two years after release: how easily they are changed, how rarely they fail, and how well the teams around them understand what they do.
Values
What we will not trade away
Honesty about risk
Estimates include what we do not yet know. Bad news is delivered early, not managed.
Simplicity
We prefer the boring solution that can be maintained over the clever one that cannot.
Respect for users
Accessibility, performance and clear interfaces are requirements, not refinements.
Continuity
Knowledge is written down so a system never depends on one person's memory.
Working principles
How engagements run
- 01
Written scope before code
Every phase begins with agreed acceptance criteria and a list of open technical questions.
- 02
Short feedback loops
Working increments are demonstrated regularly so direction can be corrected cheaply.
- 03
One backlog
Client and engineering priorities live in the same place, visible to everyone involved.
- 04
Reviewed changes only
No change reaches production without peer review and passing automated checks.
- 05
Decisions on record
Architectural choices are written down with their reasoning and their trade-offs.
Team culture
Teams are small enough that everyone understands the whole system. Code review is treated as teaching rather than gatekeeping, questions are expected, and time for refactoring is planned rather than requested. We work asynchronously by default and keep meetings to the ones that produce a decision.
Technology philosophy
Conventional by default
A technology earns a place in a system by solving a problem the project actually has. We favour widely supported languages, databases and platforms because they are easier to secure, staff and hand over. When a specialised tool is genuinely required, we introduce it deliberately and document why it is there.
Architecture follows the same rule. We start with the simplest structure that meets the requirement and split it only when a measured constraint — load, team boundaries, deployment independence — justifies the added complexity.
Quality standards
Verification is part of building
- Automated tests at unit, integration and end-to-end level, run on every change
- Static analysis and formatting enforced by the pipeline rather than by convention
- Performance budgets and accessibility checks defined with the requirement
- Release procedures that are repeatable and reversible
- Defects tracked to a root cause, with a test added to prevent recurrence
Security and confidentiality
Access limited to what the work requires
Confidentiality terms are agreed in writing before technical work begins. Access to client systems, data and repositories is granted per engagement and per person, and revoked when it is no longer needed. Credentials live in managed secret storage, never in source control, tickets or documents.
Where an engagement involves personal data, we work with the minimum necessary, prefer anonymised or synthetic data in non-production environments, and design retention and deletion behaviour together with the client rather than afterwards.
Contact
Get in touch
- Company
- VED MANAGEMENT
- [email protected]
- Website
- vedmanagement.com