Understand before building
No architecture is proposed before the current process and its constraints are understood in concrete terms.
About us
A practice built
around clarity
VEWAI LTD builds software systems and explains them in language the people who depend on them can follow.
01Company overview
VEWAI LTD is an independent software engineering company working across custom development, web platforms, cloud infrastructure, integrations, automation and interface design.
The company's focus is the part of technology work that resists packaging: processes specific to one organisation, systems that must exchange data reliably, and interfaces that have to match how work is actually done rather than how a generic product assumes it should be.
This page describes how the company works and what it offers. It does not describe past clients, project outcomes or organisational history.
02Mission and working principles
Build only what is needed, and build it so it can be changed
Prefer the simpler system
Additional components are added only when a measured problem requires them, not in anticipation of one.
Make decisions visible
Design choices and their trade-offs are written down so that later teams inherit reasoning, not only code.
Optimise for the second year
A system is judged by how easy it is to modify long after the people who wrote it have moved on.
Say what is uncertain
Estimates, risks and unknowns are stated plainly rather than smoothed over to sound reassuring.
Leave working handover
Documentation, environments and access are part of delivery, not an afterthought at the end.
03Approach to technical problems
Reduce the problem before solving it
Most technical difficulties are stated as symptoms: something is slow, something breaks under load, something needs copying between two systems every morning. The first task is to translate the symptom into a statement about data, state or responsibility.
From that statement the possible solutions narrow quickly, and the cheapest adequate one usually becomes visible. Where several options remain, they are presented with their consequences — cost, operational burden, and what each one makes harder later.
Measurements come before optimisation. A change made without a baseline cannot be shown to have helped.
04Collaboration philosophy
Fewer surprises, more written detail
Good collaboration is mostly a matter of rhythm: predictable updates, accessible decisions and no silent divergence between what was agreed and what is being built.
Work is planned as a sequence of deliverables that each stand on their own, so progress can be reviewed against something that runs rather than against a status report. When priorities change, the remaining sequence is re-planned openly.
Questions are asked early, in writing, and grouped so they can be answered efficiently. Feedback is treated as information about the problem, not as a verdict on the implementation.
05Engineering standards
The standards applied to every system
- Version control with reviewable history and meaningful commits.
- Reproducible environments defined in code rather than configured by hand.
- Automated tests concentrated on business rules and integration boundaries.
- Typed interfaces and explicit contracts between modules and services.
- Structured logging and error reporting sufficient to diagnose live issues.
- Secrets handled through managed mechanisms, never committed to code.
- Accessible, semantic markup with contrast and keyboard operability verified.
- Documentation maintained alongside the code it describes.
06Contact
Discussing a project
Enquiries are handled by email. VEWAI LTD — jamamcnulty105@gmail.com — vewaigroup.com