AAbout us
A practice,
not a pipeline.
JER Legal is a technology practice that designs, builds, integrates and maintains software. We work with organisations that need engineering handled deliberately: a defined scope, a written record of decisions, and software that another team could pick up and continue.
BMission
Make software
a manageable asset
Our mission is to make software something an organisation can plan around: understood, documented, safely changeable, and priced against a scope that was agreed in advance.
That means treating documentation, tests and operational readiness as part of the deliverable rather than as optional extras. It also means being explicit about what a system does not do, so expectations and reality stay aligned as the product changes.
CWorking principles
- P01
Write the decision down
Every significant technical choice is recorded with its reasoning and its alternatives.
- P02
Small, reviewable changes
Work moves in increments that can be read, tested and reverted independently.
- P03
No hidden scope
New work is agreed before it is started, never absorbed silently into an estimate.
- P04
Leave it takeable-over
Anything we build should be maintainable by an engineer who has never met us.
- P05
Prefer boring technology
New tools are adopted when they solve a stated problem, not because they are new.
- P06
Say what is uncertain
Unknowns are named early, with a plan for resolving them, rather than estimated over.
DApproach to technology
Fit before fashion
We choose technology against the constraints in front of us: the team that will maintain it, the data it must hold, the integrations it must survive and the budget it must run inside. Established tools with good documentation and long support horizons are the default.
Newer components are introduced where they clearly reduce complexity or risk, behind an interface that keeps the rest of the system unaffected if the choice needs to be reversed.
EQuality philosophy
Quality is a process, not a phase
Built in
Acceptance criteria are written with the scope, tests are written with the code, and changes are reviewed before they merge. Defects found this way cost a fraction of defects found in production.
Verified
Automated checks cover units, integrations and critical end-to-end paths, and run on every change so regressions surface immediately rather than at the end of a release cycle.
Observable
Structured logs, health checks and error reporting are part of the build, so behaviour in production can be examined without guesswork.
Reviewed
Architecture and dependencies are revisited on a schedule, because the right decision for a system changes as the system does.
FMethodology
Six movements
- 01
Frame
Understand the business outcome and the system as it exists today.
- 02
Specify
Turn the outcome into scope, sequencing and acceptance criteria.
- 03
Model
Decide data ownership, interfaces and failure behaviour.
- 04
Construct
Implement in reviewed increments with automated checks.
- 05
Prove
Test against the criteria agreed in the specification stage.
- 06
Transfer
Hand over code, environments and documentation.
GCollaboration model
How work runs
- Single counterpart
- One accountable contact for scope, progress and technical questions.
- Written cadence
- Regular written updates covering what changed, what is next and what is blocked.
- Shared repository
- Code, specifications and decisions live where your team can read them throughout, not only at handover.
- Change control
- New requests are estimated and sequenced explicitly before they enter the plan.
HCompany values
- Clarity
- Plain language in documents, estimates and status. Technical detail available on request, never used to obscure.
- Accountability
- One counterpart who is answerable for the state of the work at any point in the engagement.
- Durability
- Choices judged by how they hold up in year three, not only by how quickly they ship in week one.
- Restraint
- The smallest system that satisfies the requirement, because every extra part must be maintained.