Services
Four lines of delivery work
Hunterborne Consulting is a delivery practice across four lines. It is not a product catalogue, and we do not supply staff to fill gaps in your team.
Each engagement is scoped in writing after a first conversation. The sections below set out what each line covers, who it suits, and what you get.
Software development
Software that was built to a brief that has since moved on. Code that only one contractor understands. Integrations that break whenever a supplier changes an interface. The business needs the change, but the risk of touching the system keeps it waiting.
What we do
- Run discovery to pin down the constraint, the users and the integration points.
- Design the change with the people who will live with it.
- Build in small increments that can be used and checked.
- Connect the system to the other tools it depends on.
- Write the handover so your team can maintain and extend the work.
What you get
- A working increment you can use, not a demonstration.
- Source code in your repositories and under your control.
- A short handover note covering structure, setup and known limits.
What we need from you
A named person who can make decisions, access to the systems involved, and time with the people who use them.
Tools, as examples only: languages and frameworks chosen to fit the stack you already run.
Managed services
Systems go live and then drift. Tickets pile up with nobody accountable for the backlog. Support runs as a helpdesk queue, so small fixes take weeks and improvements never happen. You need someone who owns the system after launch and is measured on it.
What we do
- Agree the service model: what is covered, who owns what, and how work is prioritised.
- Run and monitor the system against agreed response expectations.
- Keep one backlog with a clear definition of done.
- Ship fixes and improvements in regular releases, not as tickets that sit.
- Review performance, cost and risk with you on a fixed cadence.
What you get
- A run model that names owners, escalation paths and working hours.
- Response expectations written into the statement of work.
- A backlog you can see, with changes shipped rather than left open.
What we need from you
A named contact for priorities, access to the system and its documentation, and a decision on what is out of scope.
Tools, as examples only: monitoring and incident tooling chosen to match what you already use.
Data and AI
Reports disagree because nobody has agreed what the metrics mean. Pipelines break quietly. AI pilots work in a demo and then stall before real users arrive, because security, cost and operations were never planned in.
What we do
- Model the data around the decisions it has to support.
- Build pipelines and analytics engineering that can be tested and rerun.
- Agree metric definitions with the people who own the numbers, and write them down.
- Take applied AI from pilot to production, with access, cost and monitoring designed in.
- Set clear limits on what an AI system is allowed to decide or do.
What you get
- A data platform or model your team can operate after we leave.
- Documented metric definitions and data lineage.
- A written statement of what the AI may do, what it may not do, and who reviews it.
What we need from you
Access to the data and the people who own it, a named business owner for each metric, and a real use case with real users.
Tools, as examples only: warehouse, transformation and BI tools chosen to suit your estate.
DevOps
Environments drift away from each other. Releases need a specialist and a prayer. A change that should take an hour takes a week, because nobody can safely rebuild the environment it runs in.
What we do
- Map the path from a change to production and find where it slows or breaks.
- Build CI/CD pipelines that test and deploy the same way every time.
- Define environments as code so they can be rebuilt and compared.
- Add the monitoring and rollback the team needs to release with confidence.
- Train the people who will run the platform, and write down how it works.
What you get
- A pipeline your team can run and change.
- Environments that can be rebuilt from code.
- A short operating note covering how to deploy, roll back and respond.
What we need from you
Access to your current pipelines and environments, and time from the people who release and support them.
Tools, as examples only: infrastructure-as-code and CI/CD tools chosen to fit your cloud and your existing tooling.
Start with a conversation
Tell us which line fits your problem, or describe the problem and we will tell you which line it belongs to.