Our approach
A senior engineer accountable for every change.
Blair, our founder, leads your project from the first conversation. AI agents handle the routine build work through Voyager, our in-house delivery system, and nothing goes live until it has been tested, reviewed and signed off. That's why your budget goes further.
ACME-142 · Linear · priority high
Add CSV export to the invoices list
- 09:12Claimednext eligible ticket, no blockers
- 09:13shipimplemented in an isolated worktree
- 09:17Verifiedtests, lint, type check and build pass
- 09:18Merge request !218 openedafter an independent review
- 09:21review:autofix2 review threads addressed, CI green
- 09:26Approvedby a senior WheelHouse engineer
- 09:26Mergedticket moved to Done
- faster development
- up to
- 10x
- lower cost for the same work
- up to
- 5x
- per client, in our Edinburgh office
- one
- machine
- validated by a senior engineer
- every
- change
Figures are upper bounds, not averages. Gains depend on how well specified the work is and the state of the codebase.
In plain English
What working with us looks like
How the work runs
We agree priorities with you, then build in small steps. Each change is tested, reviewed and released on its own, so you see progress early and often, not all at once at the end.
What a release looks like
A small request can go from asked for to live in minutes. Bigger pieces of work are broken into steps you can try as they land.
How questions get answered
When something is unclear, the work pauses and the question goes to a person: Blair, or you if it's a decision about your service. Nothing is guessed, and other work carries on.
Who is accountable
A senior engineer reviews and signs off every change before it goes live. You deal with the same person from the first conversation through launch and the years after.
What we build
Web, mobile and the systems behind them
We choose tools for your situation, not our favourites, and tell you when an existing one would do the job.
Mobile apps
iOS and Android apps, cross-platform or native, including apps that connect to hardware over Bluetooth.
Seen in Button and Thistle Assistance
Custom software
Systems built around how you work, replacing spreadsheets, manual steps and tools that don't fit.
Seen in Thistle Assistance and RemapPack
UK hosting and support
Hosting on Azure or AWS that keeps personal data in the UK: secure by default, monitored and sized to real use, with support after launch.
Seen in Thistle Assistance
Legacy modernisation
An ageing system replaced piece by piece while it keeps running, from old apps to hardcoded WordPress themes.
Seen in ARC Scotland websites
The rest of this page explains Voyager, the system behind how we work, in technical detail. It's written for CTOs and developers, and you don't need any of it to work with us. Book a call instead.
What Voyager is · for technical readers
Agents do the typing. Engineers do the engineering.
Voyager takes well-defined tickets from your backlog and delivers them as tested, reviewed merge requests. It is built on the principles we already work to: small changes, verified before review, merged only when everything is green.
It does not replace engineering judgement. A senior WheelHouse engineer shapes the work, answers the questions agents raise, and validates every change before it reaches your main branch. You get the pace of an agent fleet with the accountability of a senior engineer.
How it works
From ticket to merged change
Your team keeps working in Linear and your code host. Voyager fits around them, asks when something is unclear rather than guessing, and every step is visible as it happens.
- 01 · voyager
Select
Picks the next eligible ticket from Linear, by priority.
- 02 · agent · ship
Build
Implements it in an isolated worktree, with focused tests.
if anything is unclear
operator or clientAsk, don't guess
Unclear requirements become a question. Other work carries on.
- 03 · agent · ship
Review
Your checks and an independent review, then a merge request.
- 04 · voyager
Checks
Watches CI and reviewer feedback on every new commit.
until everything is green
review:autofixFix until green
Fixes what is justified, explains what is not, pushes again.
- 05 · engineer
Approve
Senior sign-off, then Voyager merges and closes the ticket.
Coming soon
Next: release management
Once changes merge, Voyager will take care of the release too: tagging it in git, publishing it on GitHub or GitLab, and keeping Linear's release pipeline up to date.
- coming soon
Tag release
Tags the merged work as a new version in git.
- coming soon
Publish release
Creates the release on GitHub or GitLab, with notes.
- coming soon
Track release
Keeps the Linear release pipeline in step.
Engineering principles
Built the way we build software
Speed only matters if the work holds up. These rules are part of Voyager itself, not guidelines an agent can choose to ignore.
Every change is a merge request
No direct pushes and no force-pushing. Each ticket gets its own branch, its own merge request and a clean history.
Verified before review
Agents run your repository's own tests, linters, type checks and builds before anyone is asked to look.
Green means green
A change merges only when required checks pass, required reviews finish and discussions are resolved, on the latest commit.
Bounded by design
Every run has limits on attempts, time and spend. Reaching one pauses the work with a clear reason, never an endless retry.
Questions, not guesses
Conflicting requirements or a genuine product decision pause the ticket for a person. Routine choices stay with the agent.
Measured, not assumed
Every run, intervention, cost and regression is recorded, so we can show you what was delivered and what it took.
Human oversight
Who is responsible for what
Agents are fast. Judgement comes from a senior engineer who has built and run production software for years, and decisions about your service stay with you.
You set the priorities. What gets built, and in what order, is agreed with you.
The engineer shapes the backlog. Tickets with testable acceptance criteria, sized and prioritised with you.
People answer the agents' questions. Decisions are made by the engineer, or by you, not inferred by a model.
The engineer validates every change. A senior engineer's approval is a required step before anything merges.
The engineer owns the architecture. Design, security and anything bigger than a ticket stay with the engineer. Large tickets need an explicit go-ahead.
ACME-157 · paused in ship
Round per line, or once on the invoice total?
Acceptance criteria 1 and 2 disagree. AC1 rounds each line; AC2 expects the total to match the payment provider, which rounds once.
Your answer
- Round each line (AC1)
- Round once on the total (AC2)
- Something else
Meanwhile: ACME-158 in progress · ACME-159 in review
Security scans
Sensitive code gets a specialist security review
When a ticket touches a sensitive area, such as authentication, payments or personal data, Voyager has every version of its merge request scanned by security models that are not generally available.
Claude Mythos
Anthropic · trust programme
OpenAI Daybreak Blue
OpenAI · trust programme
WheelHouse has access to both through Anthropic's and OpenAI's trust programmes.
Two models, in parallel, read-only. They report what they find. They never change your code.
Every new commit is scanned again. A change merges only once the scan of its latest version passes.
Findings become review threads. The agent fixes them. A high or critical finding that is not fixed goes to a senior engineer.
Tested against known flaws. We evaluate the scan on code with planted vulnerabilities and clean controls, so we know what it catches and how often it raises a false alarm.
ACME-163 · voyager:security-scan
Save card details for repeat payments
scanners · read-only, in parallel
- highCard token written to the request logfound by both · fixed in 4e1c2a9
- mediumNo rate limit on adding a cardMythos · fixed in 4e1c2a9
- lowDecline reason shown in full to the userDaybreak Blue · explained, follow-up ACME-171
Security and isolation
How your code and data are kept separate
Your code and data sit on a machine that is yours alone, in our Edinburgh office. Voyager runs on a fleet of Mac minis there, one per client, so agents can work without sharing hardware, credentials or repositories with anyone else.
mini-01
another client
mini-02
another client
your-company
running ACME-142
mini-04
another client
mini-05
another client
mini-06
another client
your code host
GitHub or GitLab
your tracker
Linear
fleet portal
progress, questions, spend
Dedicated hardware
One Mac mini per client. Your repositories, credentials and data never share a machine with another client's.
Isolated work
Each ticket runs in its own worktree, scoped to the repositories and projects you approve.
Scoped access
Your machine holds only the access it needs for your code host and tracker, and nothing belonging to anyone else.
Central oversight
Our fleet portal shows every run's progress, questions and spend, so we see everything without pooling your code.
Fits your workflow
No new tools for your team
Developers and reviewers keep using Linear and your code host. Leave a comment on a merge request and Voyager picks it up. Agents run on leading coding models, chosen per step for the job.
- Linear
- GitHub
- GitLab
- CodeRabbit
- Claude Code
- Codex
Scheduled maintenance
Dependency upgrades on a cadence you choose, from weekly to annually. Voyager plans each cycle, raises the tickets and delivers them like any other work.
cadence: monthly · tickets: review first
Cost
What this means for your budget
Routine build work is done by agents and checked by automated tests before anyone reviews it. Senior time goes on the decisions that matter: what to build, how it fits together and whether it's right.
On well-described work, delivery can be up to 10x faster at up to 5x lower cost. Those are upper bounds, not averages: results depend on how clearly the work is described and the state of the codebase.
Software still needs looking after once it's live. We plan support and maintenance with you from the start, so the saving isn't lost later.
Do I need to understand any of this to work with you?
No. This page is for people who want the technical detail. All you need to know is that a senior engineer is accountable for every change, and you'll be told plainly what's happening and why.
Does AI write all of the code?
Agents write most of the code for the tickets Voyager takes on. A senior engineer decides with you what gets built, answers the questions agents raise, and reviews and validates every change before it merges.
Does all this testing mean nothing can break?
No. Tests and reviews catch most problems before they reach you, but software still needs maintenance, updates and the occasional fix. That's why we stay on after launch.
What kind of work suits Voyager?
Well-defined tickets with testable acceptance criteria: features, fixes, integrations and maintenance. Large or open-ended work starts with a senior engineer, who breaks it into tickets Voyager can deliver.
Where does my code live?
In your own repositories, and on the Mac mini dedicated to you at our premises while work is in progress. It is never placed on a machine shared with another client.
Which AI models does Voyager use?
Leading coding agents, currently Claude Code and Codex. We choose the model and effort for each step of the workflow, so you are not tied to a single provider.
Talk through your plans
Tell us what you want to build or improve. We'll explain how we'd approach it, and where a senior engineer stays hands-on.
