Our technology

Our technology. Operated by our engineers.

Drover coordinates coding agents around scoped work, project context and verification. Our engineers use it to manage implementation and rework while keeping decisions, changes and evidence connected.

Context stays connected

The brief, the approved plan, project documentation and relevant earlier findings feed the next piece of work.

Connected project contextProject context stays connected to the work.The briefWhat is neededApproved planApproved by a personProject documentationThe system as it isRelevant earlierfindingsWhat was learnedNext piece of workScoped, with acceptancecriteriaImplementationand separate verificationSupports engineering decisions.Does not replace them.A person decidesWork in progress
Project context stays connected to the work.
  1. The brief states what is needed.
  2. The approved plan, where one is required, records what a person agreed.
  3. Project documentation explains the system as it is.
  4. Relevant earlier findings carry forward what was learned.
  5. Together they inform the next piece of work. They support engineering decisions; they do not replace them.

Developed and operated by our team

You are engaging a software house with its own delivery method and its own agentic delivery technology. We use it every day, so it is shaped by the work we do rather than by a feature list.

You do not install, licence or operate Drover. We work with your repositories, your review process and your delivery environment, subject to the access and integrations we agree.

Why it supports delivery

  1. 01

    Bounded work

    Work is held as scoped items with acceptance criteria, owners and defined states. A person approves the plan before implementation where the engagement calls for it.

  2. 02

    Agent coordination

    Coding agents work on separate branches, each bound to one role and one piece of work. Our engineers direct the work and manage rework.

  3. 03

    Separate verification

    The verifier is distinct from the implementation, and an implementer cannot mark its own work verified. Results are recorded against the revision they assessed.

  4. 04

    Project context

    Project documents are searchable, and lessons recorded from verified work can inform later items. This supports engineering decisions. It does not replace them, and it is not perfect memory.

The tooling, as our team sees it

Screenshots of internal tooling using demonstration data. They show how work, approval and evidence are held, not customer results.

Internal tooling · demonstration data

The delivery board in our internal tooling: four columns named Backlog, In Progress, Waiting Review and Verified, each holding ticket cards, some with pull request references.
The delivery board: scoped work grouped by state, with pull request references.
View full size of this screenshot (opens in a new tab)

Internal tooling · demonstration data

A ticket in our internal tooling with a plan review state and Approve and Reject buttons for a person to decide.
A plan waiting for a person to approve or reject it before implementation.
View full size of this screenshot (opens in a new tab)

Internal tooling · demonstration data

A ticket detail panel in our internal tooling showing a verification result labelled pass, a one-line summary, a thumbnail and a downloadable log.
Verification evidence on a ticket: the check, its result and a downloadable log.
View full size of this screenshot (opens in a new tab)

We work with the tools you already use

Our consultants join your existing development workflow, using tools like GitHub, Jira and Confluence.

From code review to project documentation, we work alongside your team without changing how you operate.

  • GitHub pull requests
  • Jira
  • Confluence

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.