Software engineering for enterprise teams
Software quality you can inspect
Acceptance criteria define the work. Tests check the behaviour. Separate verification examines the change and its evidence. Our engineers review the result before it reaches your acceptance process.
What happens to a change
A change arrives with its test outputs and is examined by a separate verifier. Findings go back for rework. A verified change goes to your review, not to production.
- A change arrives as a pull request.
- Tests produce outputs that travel with the change as evidence.
- A separate verifier examines the change and its evidence.
- If a check fails or a finding is raised, the change goes back for rework and returns with new evidence.
- A change that passes goes to our engineers, then to your review. It waits there for your decision.
- Merge and release are separate steps, planned with you. Passing verification does not trigger them.
Six practices, in plain language
We show how quality is established for each engagement, rather than describing the result with a label.
- 01
Agreed acceptance criteria
Expected behaviour and the important failure cases are defined before acceptance. They are the yardstick for the tests, the verification and your review.
- 02
Reviewable implementation
Work is delivered as scoped changes through branches and pull requests, compatible with your agreed review process.
- 03
Appropriate testing
Unit, integration, API or contract, or browser checks are selected for the work. We choose what fits each change; not every type runs for every change.
- 04
Separate verification
A verifier examines the delivered change and its supporting evidence, separately from the implementation. Human engineers remain accountable. This is not an external audit or certification.
- 05
Traceable evidence
Check results, test outputs, review findings and relevant artefacts identify the revision they assessed. Failed checks and unresolved findings stay visible.
- 06
Acceptance and release
You can inspect the result and its evidence. A passing test or verifier result does not alone establish production readiness. Merge, deployment and operational checks are distinct, and depend on the configured engagement.
See it for real
A real change, with its record
One bug fix from a project run on Drover: the brief, the acceptance criteria, the code change, the tests, the verifier's eight checks and the screenshots they produced.
What a delivery package contains
Each piece of work arrives as a package you can review. This example is illustrative: it shows the shape of a package, not a customer record.
Export orders as CSV
- 01 · acceptance-criteria
Scope and acceptance criteria
What was agreed, including the failure cases.
- A signed-in user with the Reports permission can export orders for a date range as a CSV file.
- An empty date range produces an empty file with a header row, not an error.
- A user without the permission is refused and nothing is exported.
- 02 · pull-request
Code changes and pull request
The change, on a separate working branch, in your review process.
- Pull request against the agreed base branch.
- Description links each change to the criteria it addresses.
- 03 · checks-and-findings
Test results and verification findings
Each result names the revision it assessed. Failures remain visible.
- Unit and API checks, with outputs attached.
- Returned for rework Empty range returned an error message. Resolved in a later revision, which was checked again.
- Open finding Very large exports are not yet streamed. Recorded for your decision.
- 04 · technical-notes
Supporting technical documentation
For the people who will run and change it.
- How the export works and where it lives in the codebase.
- Configuration the export depends on.
- 05 · handover
Known limitations and handover notes
What we know, stated plainly.
- Open finding and its trade-offs.
- What was not tested, and why.
- Merge, deployment and operational checks to plan with you.
Four different things
Passing one is not the same as passing the next. We keep them separate on purpose.
-
Tests
- What it is
- Automated checks of behaviour, chosen for the work.
- Who
- Run against the delivered code.
- What it does not mean
- A test passing does not show the change is complete.
-
Verification
- What it is
- A separate examination of the change and its evidence against the acceptance criteria.
- Who
- A verifier, separate from implementation, with our engineers accountable.
- What it does not mean
- Not an external audit or certification, and not release approval.
-
Customer acceptance
- What it is
- Your decision, using your review process, that the result meets what you asked for.
- Who
- You.
- What it does not mean
- Acceptance of the change is not by itself a release.
-
Production release
- What it is
- Merge, deployment and operational checks, as configured for the engagement.
- Who
- Planned and carried out together.
- What it does not mean
- Never implied by a passing verification.
Evidence in our tooling
Verification evidence attached to a ticket: the check, its result and a downloadable log. This screenshot shows our internal tooling with demonstration data.
- 1 The check and its result, named plainly.
- 2 A one-line summary of what was confirmed.
- 3 An artefact from the check, here a screenshot.
- 4 The full log, downloadable for your own review.
Internal tooling · demonstration data
What this covers, and what it doesn't
- This is engineering practice. It is not an external audit, certification or compliance attestation.
- Good process lowers risk. It cannot rule out defects or vulnerabilities.
- Security, performance and other specialist reviews are included when we agree them for an engagement.
- Every piece of evidence names the revision and configuration it covers.
Your code. Your control.
Before work begins, we agree with you where your code is processed, which AI models and tools may be used, what data they may use and who has access.
Discuss your project
Tell us what you need built, improved or connected. We start with the outcome you want and who signs off on it.